Coming proposal (was: Window Manager compliance)

[Derek Simkowiak <dereks kd-dev com>]

> that either Gnome or another program needs to provide [background
> handling], but not both.

	Indeed.  That was the point of my original email.  Some window
managers (i.e., AfterStep) use xv to set the background image.  That means
there is no drag'n'drop functionality, and you can set two background
images where one of them is simply overlapped by yet-another-running
process.

> > > 2) A new user would (reasonably) expect the background to be configured 
> > > the same place that other desktop settings are configured.
> >
> >Which is entirely possible. You can start your WM's configuration
> >program from the control-center.
> 
> Good point.

	I disagree.  Being able to drag an image from EE into
"Control-Center->Backgrounds", which looks like the background setup
dialog to more familiar environments (i.e., MS-Windows and Mac), is much
easier than "Control-Center->Window Manager->highlight whatever has
(Current) next to it->Run Configuration tool for this WM->god know what
from here to set the background".

	If you consider the new user, who may not even know what a Window
Manager *is*, there is no reason she would go looking under "Window
Manager" to change the background.  Furthermore, some Window Managers
don't even have a configuration tool, or don't have a way to set the
background.  

	I believe the background, screensaver, desktop event sounds, etc.
should be handled by Gnome.


> >I thought gnome explicitly wanted to be WM independant.
> 
> That's a nice idea, but in reality Gnome compliance demands deep changes to 
> the way a window manager behaves. To comply, existing window managers have 
> to be patched or rewritten. I'm simply suggesting that one of the many 
> features which Gnome compliance should include is that the window manager 
> should ignore the desktop background.

	I agree.

> Non-compliant window managers can be used, of course, but some duplication 
> of features occurs.

	And this feature duplication can cause problems.  What if I turn
on sounds in my WM *and* in Gnome?  Am I going to get an error dialog
that says "Unable to open device /dev/dsp" every time I close or minimize
a window?  [Probably not, but an answer of "no" should be guaranteed by
the Gnome WM compliance spec]

	Many Window Managers try to provide functionality beyond just
managing windows.  They try to become desktop "environments" of their own,
providing backgrounds, screensaver configurations, Panels (or Wharfs or
Clips or Docks or whatever they call it) of their own, which becomes very
confusing for the user when they minimize a window and the icon appears
behind the Panel.  Also, minimized window icons (which reside on the
desktop) behave very differently from icons on the desktop controlled by
gmc.  So suddenly you have a desktop where icons overlap one-another by
accident, some icons need to be double-clicked and some need to be
single-clicked to "open" them, etc. which isn't really an integrated
desktop at all.

	I believe a Window Manager should have cool features, but if it's
being used under Gnome it should be required to turn them off.

	I will work on a formal proposal (written in SGML) that lists all
features which should "go away" if the WM is being used under Gnome. Does
anyone have any suggestions?  Off the top of my head, I can think of:

1) Background images  (the catalyst to this whole discussion)
2) Screensavers and screensaver configuration (and screen locking)
3) Minimized window icons (or *any* icons appearing on the desktop)
4) Program Launcher applets (Panels, Wharfs, Start Bars, whatever would
duplicate or conflict with the Gnome panel)

5) Root window clicks (this is already there, right?)
6) Task-list  (showing what apps are running)
7) Application "buttons" (by this, I mean the MS Windows95-like
functionality that a running program has a smaller, rectangular box with
the name of the application in which, when clicked, takes you directly to
that application.  In AfterStep this is called the WinList module.  Anyone
have a better name for it?)

8) Desktop-related sounds (sounds relating to window operations)
9) Logging in and logging out (i.e., starting and stopping X.  Gnome needs
the session manager to have a chance to save the desktop layout)

10) File Management  (we should enforce the use of gmc)
11) Multiple Desktops (aka Pagers)

	...does anyone have other requirement suggestions?

	Now, what about implementation.  Should that be in the spec?
There are several ways to turn off features in a WM: at compile time, at
runtime in a config file, at runtime by watching WM hints, etc.

	Personally, I think the implementation should NOT be in the spec.
Of course, the way to have a fast WM is to make the options compile-time,
but people may want a single binary that works under Gnome or not under
Gnome.  I will comment on this in the spec, but not make it part of the
spec.

	Some people may be left thinking that without those features, all
WM will become the same.

	That's not true at all.  I can't think of anything but E offering
translucent moves, or anything but WindowMaker offering NextStep-like
resize handles, or anything but fvwm95 offering me Microsoftish minimize
buttons on the titlebar.  It's just that under Gnome, the window manager
should MANAGE WINDOWS, and nothing more.

	I need more suggestions for my proposal.  Comments?  Anyone
disagree with this idea (and why)?


Derek Simkowiak
dereks@kd-dev.com