bug#38452: 26.3; set-frame-position is slightly drifted

[Pascal Lambrechts <pascal.lambrechts@uclouvain.be>]

martin rudalics <rudalics@gmx.at> writes:

> Thanks.  Apparently GNOME draws a virtual 10 pixels wide border around
> each frame which is not visible but affects the value of frame
> position.  Concludingly, we have two problems:
>
> (1) GNOME by no means allows to programmatically position a window
>      within the screen estates used by the "dock" and the "top bar".  I
>      suppose that when you manually drag such a window with the mouse,
>      it may move into these estates but will be hidden by the dock and
>      the top bar.
I can move the frame manually under the left  dock.
But I cannot move it manually under the topbar (or dont know how).

Another weird suprise:
- if I manually move the frame with some part under the dock and then
(set-frame-position nil 0 0)
the frame jump at the leftmost position of the screen (partly covered by the
dock) but still below the topbar.
Then the frame parametres return values:
" LEFT=(+ -10)  TOP=19"

- if I move manually the frame in the middle of the screen, away from
the dock, and then
(set-frame-position nil 0 0)
the frame jumps just right to the dock, so not at the same position as
in the first case.
Then the frame parametres return values:
" LEFT=45  TOP=19"

So it seems possible to move the frame programatically under the dock
when it is alreasy under the dock.

A last point which confirms that the dock may have some role: if I move
manually a frame to try to put it under the dock, it first resists to
pass the dock and when you insist finally it passes under.


>  As a last resort: Does it help when you set the
>      frame's z-group parameter to 'above' like in
>
>      (modify-frame-parameters nil '((z-group . above) (left . 0) (top . 0)))
No, it changes nothing to the horizontal position of the frame.
>
> (2) Frame positions are reported off by 10 and 8 pixels.  While the
>      value of 10 can be explained with the reported border width, the
>      value 8 is yet unexplained.
>
> I think (1) can and should be documented in the Elisp manual.  (2)
> might be a bug in Emacs but I don't know how to fix it.
>
> martin

Pascal

-- 
Pascal Lambrechts  --  UCLouvain (SST/SC/MATH IRMP)
building: Marc De Hemptinne (Louvain-la-Neuve) - Local: B 430
phone: +32 (0)104x73161 
IRMP bte L7.01.02 // Chemin du Cyclotron 2 //  1348 Louvain-la-Neuve // Belgium