Window manager

From GNUstepWiki

In Windows and Mac OS X the window manager is tied into the OS. That's not the case for Linux or BSD. Window Maker is the recommended window manager for GNUstep, but a standard feature-set is needed. GNUstep-based applications have additional needs beyond traditional window managers, like handling the dock icon or the menus. Collecting the requirements here will lead to a specification, so any window manager can clearly state whether or not it is GNUstep-compliant.

Window Level

The rest depends on the function of a window. To obtain good interoperability between different Desktop Environments, the following layered stacking order is recommended, from the bottom to the top:

windows of type _NET_WM_TYPE_DESKTOP

windows having state _NET_WM_STATE_BELOW

windows not belonging in any other layer

windows of type _NET_WM_TYPE_DOCK (unless they have state _NET_WM_TYPE_BELOW) and windows having state _NET_WM_STATE_ABOVE

focused windows having state _NET_WM_STATE_FULLSCREEN

Windows that are transient for another window should be kept above this window.

The window manager may choose to put some windows in different stacking positions, for example to allow the user to bring currently active window to the top and return it back when the window loses focus.

Comments from Yen-Ju Chen: "GNUstep has no such definition and use window level for this purpose. Personally, I wish GNUstep had a better way to tell which window is for which functions, like app icon, floating panel, menu, key window, main window. The window level is not that reliable when people want to do some tricks. It may not match EWMH one-to-one, but it will be useful for various reasons."

App Icon

GNUstep used to have NSDockWindowLevel, but it is deprecated. So to know which window is the app icon, you have to first find a GNUstep window, check its group_leader, (See XWMHints in X protocols), then check its icon_window which points to app icon. Again, it will be easier if there is hint (see above).

EWMH defines _NET_WM_ICON for app icon image. GNUstep supports it, but I am not sure if it is updated when the app icon image is changed. And if people use app icon as a NSWindow and draw directly on it, there is no way the window manager will know. The solution is that if there is a notification that the icon is redrawn, the window manager or GNUstep can copy (or take a screenshot of) the image from that NSWindow and put it into _NET_WM_ICON. It requires something like XCopyArea().

Focus

X has focused and unfocused window, GNUstep has key window and main window, plus menu and app icon. I don't know how the chain of focus should go when the window and menu are up and down. But again, if there is a hint for the main window, key window, main menu, etc, it will be easy for the window manager to know where the focus should go. A documentation of how the focus should shift from which to which may help.

Menus

Again, because there are no real hints about which one is the main menu and submenu besides window level, it is hard to find the correct one. So menus are treated as regular windows in most cases.

Besides the focus issue, there is also a boundary issue. Say the user puts the mouse on the right edge of the screen and clicks the right button (bringing up a menu): the main menu will be off of the right boundary. GNUstep tries to move it back, and some window managers also try to move it back. When a window is moved, the mouse tracking may be offset. After the main menu is open, a user clicks on a submenu, which will also be off of the right boundary. Then should the window manager move both the main menu and submenu to the left? Does GNUstep do that? It is not clear which one should do what.

And now, some people like to have a horizontal menu (like Mac OS X) instead of a vertical menu (like NEXTSTEP). They behave differently for submenus. For a horizontal menu, the submenu will close on an action fire. For a vertical menu, the submenu will stay open after an action fire. So I guess only GNUstep can handle it.