Re: Window managers

[Yen-Ju Chen]

On 3/18/07, Günther Noack <guenther@unix-ag.uni-kl.de> wrote:
> Hi!
>
> Am 18.03.2007 um 03:42 schrieb TMC:
> > I hate to see developers' time wasted on duplicating efforts of
> > others. Can
> > we please have a standard for a "GNUstep-compliant" window manager?
> > I'm
> > thinking something along the lines of "A compliant window manager must
> > implement X, Y, and Z."
>
> I think this is a *very* good point. I don't think the lack of
> GNUstep compliant window managers is caused by the people not wanting
> to support GNUstep, but by the GNUstep project's failure to
> communicate what has to be done to actually *make* a window manager
> GNUstep compliant.
>
> It's probably not a very big list of changes that have to be made on
> a window manager, so I wouldn't be surprised if Freedesktop.org
> accepted the GNUstep extensions to the window manager standard as an
> optional appendix. (Please don't say GNUstep is not a Desktop; No
> matter what it is, it's a very good base for building a desktop and
> the window manager additions are caused by GNUstep itself, not a
> GNUstep-based desktop environment.)
>
> I strongly believe that if we can get the GNUstep additions into the
> Freedesktop.org WM specification, we'll see a much more GNUstep
> compliant window managers popping up.
>
> Just my 2 cents.
>
> Regards,
> Günther

Here is what I observed so far.
It is long and I am not an expert.

In backend, Headers/x11/XGServerWindow.h defines:

typedef struct {
   unsigned long flags;
   unsigned long window_style;
   unsigned long window_level;
   unsigned long reserved;
   Pixmap miniaturize_pixmap;           // pixmap for miniaturize button
   Pixmap close_pixmap;         // pixmap for close button
   Pixmap miniaturize_mask;             // miniaturize pixmap mask
   Pixmap close_mask;                   // close pixmap mask
   unsigned long extra_flags;
} GNUstepWMAttributes;

#define GSWindowStyleAttr       (1<<0)
#define GSWindowLevelAttr       (1<<1)
#define GSMiniaturizePixmapAttr (1<<3)
#define GSClosePixmapAttr       (1<<4)
#define GSMiniaturizeMaskAttr   (1<<5)
#define GSCloseMaskAttr         (1<<6)
#define GSExtraFlagsAttr        (1<<7)

#define GSDocumentEditedFlag                    (1<<0)
#define GSWindowWillResizeNotificationsFlag     (1<<1)
#define GSWindowWillMoveNotificationsFlag       (1<<2)
#define GSNoApplicationIconFlag                 (1<<5)
#define WMFHideOtherApplications                10
#define WMFHideApplication                      12

[Window Level]

GNUstep need arbitrary window level.
EWMH define these two:

_NET_WM_STATE_ABOVE, ATOM
_NET_WM_STATE_BELOW, ATOM

The rest depends on the functions of window:

"Stacking order

To obtain good interoperability between different Desktop
Environments, the following layered stacking order is recommended,
from the bottom:
*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 a
active window to the top and return it back when the window looses
focus. "

[Window Style]

Window style is more or less right,
except GNUstep want to display edited  document:
GSDocumentEditedFlag

[Window Type]

EWMH define:

_NET_WM_WINDOW_TYPE_DESKTOP, ATOM
_NET_WM_WINDOW_TYPE_DOCK, ATOM
_NET_WM_WINDOW_TYPE_TOOLBAR, ATOM
_NET_WM_WINDOW_TYPE_MENU, ATOM
_NET_WM_WINDOW_TYPE_UTILITY, ATOM
_NET_WM_WINDOW_TYPE_SPLASH, ATOM
_NET_WM_WINDOW_TYPE_DIALOG, ATOM
_NET_WM_WINDOW_TYPE_DROPDOWN_MENU, ATOM
_NET_WM_WINDOW_TYPE_POPUP_MENU, ATOM
_NET_WM_WINDOW_TYPE_TOOLTIP, ATOM
_NET_WM_WINDOW_TYPE_NOTIFICATION, ATOM
_NET_WM_WINDOW_TYPE_COMBO, ATOM
_NET_WM_WINDOW_TYPE_DND, ATOM
_NET_WM_WINDOW_TYPE_NORMAL, ATOM

GNUstep has no such definition and use window level
for this purpose. Personally, I wish GNUstep has
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 reason.s

[App Icon]
GNUstep used to have NSDockWindowLevel, but it is deprecated.
So to know which window is 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 define _NET_WM_ICON for app icon image.
GNUstep supports it, but I am not sure whenever it got updated
when app icon image is changed.
And if people use app icon as NSWindow and draw directly on it,
there is no way window manager will know it.
The solution is that if there is a notification of icon is redraw,
window manager or GNUstep can copy (or take a screenshot)
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 what is the chain of focus should go
when window and menu are up and down.
But again, if there is a hint for main window, key window, main menu, etc,
it will be easy for window manager to know where the focus should go.
A documentation of how the focus should shift from which to which may help.

[Menu]
Again, because there is no real hints about which one is main menu and submenu
besides window level, it is hard to find a right one.
So menus are treated as regular window in most case.
Besides focus issue, there is also boundary issue.
Say user put the mouse on the right edge of screen and click right button,
the main menu will be out of right boundary.
GNUstep try to move it back, and in some window manager, it also try
to move it back.
When a window get moved, the mouse tracking may be offset.
After main menu is open, a user click on a submenu,
which will also out of right boundary.
Then should window manager move both 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 horizontal menu instead of vertical menu.
It behaves differently for submenu.
For horizontal menu, submenu will close when an action fire.
For vertical menu, submenu stay after an action fire.
So I guess only GNUstep can handle it.

[Window resizing and moving]

GNUstep defines:
#define GSWindowWillResizeNotificationsFlag     (1<<1)
#define GSWindowWillMoveNotificationsFlag       (1<<2)

I didn't see it in WindowMaker, therefore, I don't know whether it is
really supported.
But it may be a key for some window turning black when resizing.

Yen-Ju

> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnustep