You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Window decorations missing completely on certain WMs #82
On WindowMaker all is fine.
On special X11 MS-Windows native windowmanager exported GNUstep windows lack any control, windows are impossible to close, move,ecc.
@rmottola, which X server and mode is this (Cygwin/X XWin -multiwindow, VcXsrv -multiwindow, X410, …), and its version? That decides whether the server reads _MOTIF_WM_HINTS at all.
On non-WindowMaker WMs the X11 backend stops using _GNUSTEP_WM_ATTR and asks the WM to decorate via _MOTIF_WM_HINTS (XGServerWindow.m:908). A couple of things would pin down where that breaks:
Run an affected app with --GNU-Debug=WM and paste the WM Protocols: WindowMaker=(..) GNOME=(..) EWMH=(..) line, so we know how _checkWindowManager classifies this WM.
xprop _MOTIF_WM_HINTS on an undecorated GNUstep window and on a working GTK window, for comparison.
Is GSBackHandlesWindowDecorations (or GSX11HandlesWindowDecorations) set in your defaults? As a test, defaults write NSGlobalDomain GSBackHandlesWindowDecorations NO and relaunch — if GNUstep then draws its own title bar and controls, that isolates it to the WM-side decoration path.
Unfortunately I don't have this configuration available so I can't help much debug this.
@DTW-Thalion I am using (a slightly old version of) MobaXTerm . it should be based on Cygwin. I will see if I can get the details.
This bug could be a little related to #84 which is also an issues on rootless. There however styles come from window levels.
I also use X11.app on Mac which is rootless but more up-to-date. Will re-check.
Measured this against a window manager written to map windows and decorate
nothing, which is how a rootless X server driving a native window manager can
behave.
The hints GNUstep sets are correct. On a titled, closable, miniaturizable and
resizable window _MOTIF_WM_HINTS holds 0x3, 0x3e, 0x6e: flags for functions
and decorations, functions for resize, move, minimize, maximize and close, and
decorations for border, resize handle, title, minimize and maximize.
_GNUSTEP_WM_ATTR is set as well. So the request is not what is missing.
What is missing is that nothing checks the result. Whether the backend or the
gui library draws the title bar and the buttons is decided by the method
named -handlesWindowDecorations, which answered YES whatever the window
manager did, changing only for the GSBackHandlesWindowDecorations default. PR #228
answers it from the offsets probe instead: a window manager that puts a border
on no style at all draws no title bar either. Under that window manager a
titled window was 200x120, the content rect asked for, and becomes 202x144,
with a title bar and buttons drawn by the gui library.
One more thing came out of it. With no decoration on any style the offsets
probe fails for every style, so the offsets are never stored on the root
window and every application start repeats the probe, about a second per
style.
The xprop and --GNU-Debug=WM output asked for above would still confirm this is
the same case, rather than a window manager that decorates in some other way.
Activity
DTW-Thalion commentedon Jul 15, 2026
@rmottola, which X server and mode is this (Cygwin/X XWin
-multiwindow, VcXsrv-multiwindow, X410, …), and its version? That decides whether the server reads_MOTIF_WM_HINTSat all.On non-WindowMaker WMs the X11 backend stops using
_GNUSTEP_WM_ATTRand asks the WM to decorate via_MOTIF_WM_HINTS(XGServerWindow.m:908). A couple of things would pin down where that breaks:--GNU-Debug=WMand paste theWM Protocols: WindowMaker=(..) GNOME=(..) EWMH=(..)line, so we know how_checkWindowManagerclassifies this WM.xprop _MOTIF_WM_HINTSon an undecorated GNUstep window and on a working GTK window, for comparison.GSBackHandlesWindowDecorations(orGSX11HandlesWindowDecorations) set in your defaults? As a test,defaults write NSGlobalDomain GSBackHandlesWindowDecorations NOand relaunch — if GNUstep then draws its own title bar and controls, that isolates it to the WM-side decoration path.Unfortunately I don't have this configuration available so I can't help much debug this.
rmottola commentedon Jul 15, 2026
@DTW-Thalion I am using (a slightly old version of) MobaXTerm . it should be based on Cygwin. I will see if I can get the details.
This bug could be a little related to #84 which is also an issues on rootless. There however styles come from window levels.
I also use X11.app on Mac which is rootless but more up-to-date. Will re-check.
DTW-Thalion commentedon Aug 5, 2026
@rmottola any luck here?
DTW-Thalion commentedon Aug 6, 2026
Measured this against a window manager written to map windows and decorate
nothing, which is how a rootless X server driving a native window manager can
behave.
The hints GNUstep sets are correct. On a titled, closable, miniaturizable and
resizable window _MOTIF_WM_HINTS holds 0x3, 0x3e, 0x6e: flags for functions
and decorations, functions for resize, move, minimize, maximize and close, and
decorations for border, resize handle, title, minimize and maximize.
_GNUSTEP_WM_ATTR is set as well. So the request is not what is missing.
What is missing is that nothing checks the result. Whether the backend or the
gui library draws the title bar and the buttons is decided by the method
named -handlesWindowDecorations, which answered YES whatever the window
manager did, changing only for the GSBackHandlesWindowDecorations default. PR #228
answers it from the offsets probe instead: a window manager that puts a border
on no style at all draws no title bar either. Under that window manager a
titled window was 200x120, the content rect asked for, and becomes 202x144,
with a title bar and buttons drawn by the gui library.
One more thing came out of it. With no decoration on any style the offsets
probe fails for every style, so the offsets are never stored on the root
window and every application start repeats the probe, about a second per
style.
The xprop and --GNU-Debug=WM output asked for above would still confirm this is
the same case, rather than a window manager that decorates in some other way.
rmottola commentedon Aug 7, 2026
Debug output. Apparently plain window manager with no protocols
Here emacs.
Left in the encoded icon because it is cool and we should do it too 😄
Maybe the significant difference is: _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL