GNU bug report logs - #31031
27.0; (elisp) `Position Parameters', floating-point values

Previous Next

Full log

Message #32 received at 31031 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 31031 <at> debbugs.gnu.org
Subject: Re: bug#31031: 27.0; (elisp) `Position Parameters', floating-point
 values
Date: Thu, 05 Apr 2018 09:00:17 +0200

>> Why did you ask for 2400 and not for 2360?  If the position value is
>> too large the window manager might try to fit the frame onto the
>> screen.  OTOH "correcting" this to 2380 means there are 20 pixels (the
>> full right external border) missing on the right if not I am missing
>> something.
>
> I asked for 2400 because if I ask for 2360 the frame is not flush
> right.

Funny.  There must be some strange calculations going on behind the
scenes.  Is there some consistency in the sense that your window
manager never shows the full external border when you want to place it
at some position on the left or top of the screen?

> I think weʼre getting a -20 offset back from X somewhere when querying
> the frame size/position.

And the -20 doesn't correspond to what you see on screen because the
external border is not fully visible.  Right?

> If I look at this hunk in
> x_real_pos_and_offsets:
>
> #ifdef USE_XCB
>        geom = xcb_get_geometry_reply (xcb_conn, geom_cookie, NULL);
>        if (geom)
> 	{
> 	  real_x = geom->x;
>
> then real_x there is -20 when the frame is flush left. Should we be
> using gdk/gtk calls to get the window geometry?

By all means try to check whether these get you better results.  But
before that you might want to try disabling USE_XCB.  I recall an
earlier discussion where I strongly doubted the correctness of values
returned by x_real_pos_and_offsets.

martin

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.