GNU bug report logs -
#74496
30.0.91; fullscreen frame set with F11 is shifted when ctwm restarts
Previous Next
Reported by: Van Ly <van.ly <at> SDF.ORG>
Date: Sat, 23 Nov 2024 18:29:02 UTC
Severity: normal
Found in version 30.0.91
Done: martin rudalics <rudalics <at> gmx.at>
Bug is archived. No further changes may be made.
Full log
Message #71 received at 74496 <at> debbugs.gnu.org (full text, mbox):
> From the data below, I see that a `maximized' full screen will leave a
> gap at the bottom border. The outer-size stays at `1914 . 1069'. The
> gap persists across ctwm restart.
>
> In the case of ctwm restart on `F11 fullscreen' the windowframe
> outer-size parameter goes from `1920 . 1080' to `1914 . 1069'.
So we have 6 pixels width and 11 pixels height less. Doesn't make much
sense to me.
> Emacs 29.4 behaves the same.
>
> More information, CTWM's window context menu for zoom, zoom-v, zoom-h
> does the following to an initial frame
>
> outer-size frame parameter changes
> - 674 . 678 <= initial
> - 1914 . 1069 zoom
> - 674 . 1069 zoom-v
> - 1914 . 678 zoom-h
But this implies that zooming does _not_ do what you want (at least not
entirely) and restarting CTWM is probably not the real cause of the
problem.
> // zoom zoom-v zoom-h BEGIN
>
> 1 (frame-geometry)
> 2 ;; initial window frame parameters
> 3 ;; => ((outer-position 629 . 104) (outer-size 674 . 678) (external-border-size -3 . -3) (outer-border-width . 0) (title-bar-size 0 . 6) (menu-bar-external . t) (menu-bar-size 674 . 28) (tab-bar-size 0 . 0) (tool-bar-external) (tool-bar-position . top) (tool-bar-size 672 . 36) (internal-border-width . 1))
These values are fishy - here I get for an initial emacs -Q Lucid frame
((outer-position 0 . 0) (outer-size 764 . 885) (external-border-size 5 . 5) (outer-border-width . 0) (title-bar-size 0 . 14) (menu-bar-external . t) (menu-bar-size 754 . 31) (tab-bar-size 0 . 0) (tool-bar-external) (tool-bar-position . top) (tool-bar-size 752 . 36) (internal-border-width . 1))
An external border size of -3 can only harm. The menu bar width should
be the outer frame width minus twice that of the external borders - 764
minus 10 gives 754 here. Similar for the tool bar where you should also
subtract twice the internal border width. We have to find out the cause
for this but I don't yet know how.
Now two times 3 gives 6 which _could_ explain the 6 pixels width
decrease but it wouldn't explain the 11 pixels height decrease.
When with gdb in frame_geometry in xfns.c you put a breakpoint at the
line staring with an if below (it's line 6747 here)
XGetGeometry (FRAME_X_DISPLAY (f), FRAME_OUTER_WINDOW (f),
&rootw, &x_native, &y_native, &native_width, &native_height,
&x_border_width, &ign);
/** XGetWindowAttributes (FRAME_X_DISPLAY (f), FRAME_OUTER_WINDOW (f), &atts); **/
if (!FRAME_PARENT_FRAME (f))
run -Q and evaluate (frame-geometry) in the emacs you run, the
breakpoint should be hit. If you now type
p x_border_width
in the debugging buffer, what does it print?
> => 8 _NET_WM_STATE(ATOM) = _NET_WM_STATE_FULLSCREEN
...
> => 8 _NET_WM_STATE(ATOM) =
> => 8 _NET_WM_STATE(ATOM) = _NET_WM_STATE_MAXIMIZED_VERT, _NET_WM_STATE_MAXIMIZED_HORZ
...
> => 8 _NET_WM_STATE(ATOM) =
We have to find out who resets them. Can you try doing this for any
other GUI application that can be made fullscreen via F11?
martin
This bug report was last modified 200 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.