Main menu misplaced on Debian 13

[rfm]

Using the default (Gnome) desktop on Debian all GNUstep apps have their main menu positioned under the top-bar so that the title of the menu is hidden (preventing the menu from being dragged to anywhere else) and part of the top menu item is hidden.
This doesn't make GUI apps unusable, but it is ugly and awkward.

I solved that for one app by examining the source code to find the name/format in which menu positions are saved, then setting a user default to position the menu on screen, so that when I restarted the app I could drag the menu to the correct (top-left just under the top-bar) position. There has to be a better way.

Where should I look to fix this (or implement an easier workaround)?

[fredkiefer]

I am not really sure what is the best way to resolve this issue. But one way to address it could be the method -boundsForScreen: in XGServerWindow this gets used to determine the frame of all screens. Another perhaps simpler approach would be to add some code to NSScreen -visibleFrame. There we already try to take our own top level menu bar into account. But how to get the dimensions of the menu bar? Maybe the Freedesktop property _NET_WORKAREA could help here.

[rfm]

I added code for that in a new topbar-fixes branch. It seems to sort-of fix things for me. The main menu is now fully visible on screen. However it seem there are two layers to the top-bar:
an upper one in which top-bar widgets are dispolayed
a lower one, into which the title-bar of a window may be dragged.
Because our main menu has no window decoration (and no title bar) it cannot be dragged up into that lower part of the top-bar.

[rfm]

While that doesn't seem quite right, it's definitely an improvement. We could convert that branch (with some comments/cleanup) into a pull request

[rfm]

While doing this, I get the impression that there's a whole lot of stuff we are missing in this area. It seems to me that there can be multiple logical desktops that can be displayed on the screen and there are multiple displays/monitors on a host, and display is possible on multiple hosts. I think gnustep-back supports a single display on a single host, which is not great, but has long been tolerable (when initially written, few people had multiple displays and/or multiple machines).
Nowadays multiple screens are much more common, and multiple desktops (one active on a screen at a time) may be more common than single desktops.
Are there any plans (or even just thoughts) about how we might go about addressing this? Perhaps we could work on it for Wayland (something I haven't experiments with yet).

[tedge]

GNOME's window manager, Mutter, should reposition normal-level titled windows so their title-bars don't get mapped behind the desktop menus/dock, but it appears to allow overlaps by menu-level borderless windows, such as the GS main menu.

(Perhaps there's other desktops/window-managers with this issue, but it's hidden because their default theme doesn't have the desktop menu at the top of the screen.)

Maybe before mapping the GS main-menu to the screen, try mapping a titled normal-level temporary window using the main-menu's initial coordinates. (-[XGServer _checkStyle:] does something similar - mapping a temporary window to get generic window-style offset values). The WM should move it clear of the menu-level windows, then you can grab the temp window's mapped coordinates (& close it), and position the main-menu at those coordinates.

(Alternatively, you could try mapping the main menu itself at normal-level, then raise it to menu-level once it's mapped. This is probably an uncommon behavior, though, and might not've received much testing by the various window managers).

[rfm]

I don't really like the idea of extending the type of thing_checkStyle: does (even though I was involved in its creation many years ago). It generates some complaints about the visual glitches on app startup, and it has always seemed hacky and fragile (we don't really know what a WM is going to do in more realistic situations than such simple tests). But maybe we have to do something like that to tweak things for some WMs.

So, I'd like to separate the issue of _NET_WORKAREA support from that of further tweaking positioning. Accordingly I renamed the branch to _NET_WORKAREA and will create a pull request from it. We can then try to decide if we want to leave it at that or introduce further tweaks.