Re: GNOME CVS: gnome-core jirka

[Michael ROGERS <M Rogers cs ucl ac uk>]

>> (Ideally you would want a CORBA interface to the window manager
>> through which you could query it and get notification, but that's
>> another story...)
>
>I could not agree more with this.
>
>It would make sense to make a revision of the GNOME WM spec that used
>CORBA, and provide a default implementation, for say icewm and
>something else.
>
>Not only for hints, but for total control of the WM actions with
>CORBA.
>
>So that way, with the voice stuff, we could control entirely by voice
>any GNOME compliant window manager without having per-window manager
>hooks. 

I think it's important to separate "Gnome pager compliance" from "Gnome
compliance". The existing Gnome window manager spec deals mainly with the
interface between the pager and the window manager, and it's very messy.
CORBA would definitely be a better solution. However, not all WM authors are
going to want to incorporate CORBA, especially if their WM already does a
good job of switching between windows and moving between virtual desktops.
How about a CORBA interface for applications which want to control these 
features (like the pager or a voice control app), and a separate, greatly
simplified, Xlib interface for hints and root-window clicks?

For example:

In addition to MWM hints, applications may set a property on their
top-level windows called _GNOME_WM_HINTS, which will be a pair of CARDINALS:

typedef struct _GWMHints
{
    CARD32 layer;
    CARD32 hints;
} GWMHints;

Where layer may have one of four values:

#define GNOME_HINTS_LAYER_DESKTOP 0  /* Only the virtual root window should 
occupy this layer */
#define GNOME_HINTS_LAYER_BELOW   1  /* Eg, the panel if it is set to "stay
below" */
#define GNOME_HINTS_LAYER_NORMAL  2  /* All normal windows and any windows
which do not specify a layer */
#define GNOME_HINTS_LAYER_ABOVE   3  /* Eg, the panel if it is not set to 
"stay below" */

And where hints is a bitmask:

#define GNOME_HINTS_SKIP_CIRCULATE (1 << 0)  /* "Alt-Tab" skips this window */
#define GNOME_HINTS_SKIP_WIN_LIST  (1 << 1)  /* Don't show on window list */
#define GNOME_HINTS_SKIP_TASKBAR   (1 << 2)  /* Don't show on taskbar */

(Any other hints?)

The WM spec should also clearly define the relationship between the window
manager and the desktop manager. For example:

* Gnome window managers should not duplicate features which are already
provided by Gnome, like desktop icons, the ability to terminate the X
session, file managers, etc. If a window manager provides these features, it
should disable them under Gnome. To help window managers to detect Gnome and
configure themselves accordingly, gnome-session will set a property on the
root window called, I don't know, _GNOME_RUNNING. Of course, if the user
wants to re-enable these features that is her choice.

* The desktop manager will use a "virtual root window" (a window covering the
whole root window) instead of using the root window as the desktop. This will 
allow the desktop manager to receive all mouse clicks, key presses etc. on
the desktop. It will forward middle-mouse-button clicks to the "real" root
window, so that the window manager can use them (eg for bringing up a root
menu). The window manager must not depend on any root window clicks other 
than the middle mouse button.

* Desktop icons won't be top-level windows any more, so the window
manager won't try to manage them. (I don't know if this matters. It might
make life easier for the desktop manager?)

* The desktop manager will define an interface for applications to set the 
desktop wallpaper (for example, a web browser could set the wallpaper to an 
image which was being viewed). Different wallpaper can be used for each 
virtual desktop. Because they're handled by the desktop manager, these 
settings can be stored in the session.

* There's no point in window managers decorating the root window. since it
will be hidden under the desktop. However, they could set the wallpaper
through the desktop manager.

* Desktop functionality (like the recent suggestion of typing on the desktop
to launch applications) will be the same regardless of the window manager.

* Window functionality (like the way you switch between applications, and
the appearance of windows) will vary depending on the window manager. This is 
the point of allowing different window managers to be used.


I hope I'm not out of line in making these suggestions. As you can tell I've
been thinking about this for a while.

The window manager spec definitely needs to be overhauled. However, I don't 
think interaction with the pager is an absolutely necessary part of Gnome 
compliance, so the two interfaces should be separated.


Michael Rogers