Re: modify-frame-parameters with floating point offsets

[Robert Pluim]

Robert Pluim <address@hidden> writes:

> Robert Pluim <address@hidden> writes:
>
>>> Probably a problem with calculating the decorations.  Does
>>> (frame-geometry) return "reasonable" values for your frame?
>
> OK, is this normal?
>
> emacs -Q
> (modify-frame-parameters nil '((left .   0.0)))
> (frame-geometry)
>
> => ((outer-position -20 . 188) (outer-size 1208 . 1226)
>    (external-border-size 20 . 20) (outer-border-width . 0)
>    (title-bar-size 0 . 70) (menu-bar-external . t) (menu-bar-size 1168
>    . 24) (tool-bar-external . t) (tool-bar-position . top) (tool-bar-size
>    1168 . 42) (internal-border-width . 0))
>
> The frame is visually flush with the left edge of the screen, but
> frame-geometry claims itʼs at -20 ?
>
> For comparison, after toggle-frame-fullscreen
>
> ((outer-position 0 . 0) (outer-size 3840 . 2160) (external-border-size
> 0 . 0) (outer-border-width . 0) (title-bar-size 0 . 0)
> (menu-bar-external . t) (menu-bar-size 3840 . 24) (tool-bar-external
> . t) (tool-bar-position . top) (tool-bar-size 3840 . 42)
> (internal-border-width . 0))
>
> So is this the window manager lying to us? This is with XWayland, Iʼll
> see if I can test under vanilla X.

So this seems to be very window-manager specific. With two different
implementations of Gnome-on-X-on-Wayland, I get the -20 offset, also
with one implementation of Gnome-on-X. However GTK running under KDE
does not have the issue. Also running Compiz-on-Gnome gets me the
correct answer, but Metacity gets it wrong.

That suggests to me itʼs a window manager issue, but Iʼm not sure how
we could work around the differences.

Robert