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

[martin rudalics]

> The value of x-frame geometry depends on the dock position:
> ; if I set the dock at left:
> (set-frame-position nil 0 0)
> t
> (setq pl-x-frame-geometry-dock-at-left (x-frame-geometry))
> ((outer-position 45 . 19) (outer-size 772 . 766) (external-border-size 10 . 
10) (outer-border-width . 0) (title-bar-size 0 . 28) (menu-bar-external . t) 
(menu-bar-size 752 . 24) (tool-bar-external . t) (tool-bar-position . top) 
(tool-bar-size 752 . 46) (internal-border-width . 0))
>
> ;if I set the dock at bottom:
> (set-frame-position nil 0 0)
> t
> (setq pl-x-frame-geometry-dock-at-bottom (x-frame-geometry))
> ((outer-position -10 . 19) (outer-size 772 . 766) (external-border-size 10 . 
10) (outer-border-width . 0) (title-bar-size 0 . 28) (menu-bar-external . t) 
(menu-bar-size 752 . 24) (tool-bar-external . t) (tool-bar-position . top) 
(tool-bar-size 752 . 46) (internal-border-width . 0))

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.  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)))

(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