Re: GNOME CVS: gnome-core jirka

[Nathan Clemons <nathan windsofstorm net>]

I can agree more with this. GNOME is very powerful, very flexible, but
currently lacks a strong amount of support from the different window
managers. One could wish that everyone used enlightenment, but some of us
think that it has too many features that we wouldn't use.

A WM should not have to be a GNOME-based application to support GNOME, and
insisting that they all use CORBA would be a strong downfall. Several
people are balking at the existing WM spec as it stands now; asking them
to implement CORBA would permanently cement their minds against it.

I'd like to add to this thought, but it will have to be at a later time.

-------------------------------------------------------------------------
Nathan P. Clemons                       "Peace favor your code."
nathan@windsofstorm.net                 ICQ: 2810688
-------------------------------------------------------------------------

On Wed, 2 Jun 1999, Michael ROGERS wrote:

> >> (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
> 
> 
> -- 
>         FAQ: Frequently-Asked Questions at http://www.gnome.org/gnomefaq
>          To unsubscribe: mail gnome-list-request@gnome.org with 
>                        "unsubscribe" as the Subject.
>