Open to discussion...

[Derek Simkowiak <dereks kd-dev com>]

	This is bound to be a controversial email, so hang on to your
seats.

	First, a bit of history: A few weeks ago, there was some chat on
the gnome-devel-list about Window Manager Compliance (even before this
list was conceived).  Much of the talk was between myself and Mr. Michael
Rogers (bastard_machine@hotmail.com).  In our discussions, I came up with
a framework for a new, proposed "Gnome Window Manager Compliance Spec".

	Then, I got busy, and only now was I able to review those emails
and try to work on a new spec.

	So, first steps first, I was going to write a White Paper
describing the issues faced when talking about window managers and Gnome.
The attached document was supposed to be that White Paper (some of which
was cut'n'pasted directly from my emails to the gnome-devel-list).

	But the more I thought about the issues, the clearer it became:
trying to support all window managers is counter productive. 

	So, below, is what my "White Paper" eventually turned into: an
argument for having a Gnome specific window manager (or, more accurately,
a special class of "Gnome window managers").  Even if you don't agree with
my conclusion, I think forcing people to address the issues I bring up
will result in a stronger compliance spec, if that's what people still
want to do.

	Here it is:

-----------------------------------------------------------------
An argument for having a Gnome-specific window manager (or class thereof)
Author: Derek Simkowiak (dereks@kd-dev.com)



	Gnome is a complete, integrated desktop enviroment.  An integrated
desktop environment has many features, but there are only a few that
interest us in this document.  Specifically:

	The applications should all share a common widget set, so that the
applications look and behave the same (under Gnome, this is the Gtk+
widget set).  The applications should also be able to share data via a
specified drag'n'drop protocol and a "clipboard" for being able to cut and
paste data between applications. 

        There should also be a standard help system, with the environment
providing the help browser and help-file format. Gnome uses the
SGML/Docbook format for its documentation.


	Also, Gnome manages multiple desktops with its own "pager"
application.  It manages backgrounds and screensaver setup through its
configuration utility.  It has its own application called the "Panel" to
make it easy to launch applications and get various system information
(with "Panel applets"), and the Panel has a button-list of currently open
windows, so you can always select a particular window by clicking on the
Panel.  It also manages icons on the desktop through its file manager,
gmc, thus providing complete drag'n'drop interoperability with other Gnome
applications.

	The one thing that Gnome does not currently specify is what
window manager (WM) should be used.  This allows the user to choose
whatever WM they want.

	Now, the problem:

	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, or some
icons need to be double-clicked and some need to be single-clicked to
"open" them.  This only adds to the confustion when the WM "Wharf" is
partially overlapped by the Gnome Panel, and the pager applications
conflict with one-another.

	If you have sound turned on in Gnome and the WM you might get
"Cannot open device /dev/dsp" errors, and if the WM uses a 3rd-party
program to set the background (such as xv, which is what AfterStep uses)
then you may not be able to figure out why your background does not match
the miniaturized desktop picture in the Gnome configuration utility.  


	Furthermore, some WMs try to emulate other desktop environments
(such as NeXt or Mac or Amiga) and thus have widget sets of their own, and
the configuration utility, menus, or 'helper applets' look like something
completely different from Gnome.  And the documentation for any given WM
could be a text file, HTML, or even a custom help-file format intended
only for use with that WM.  

	Then, there is the issue of handling X events.  If a user clicks
on the root window, should that click be handled by the WM or by gmc?


	So most of the window managers that are currently out there, in
order to provide a consistent, non-conflicting user interface to a Gnome
user, would immediately need the following features to "go away" if it
were being used under Gnome:

1) Background image handling (whether this is being done by running xv or
some other implementation)
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 click handling (i.e., through WM hints)
6) Task-list  (showing what apps are running/what windows are open)
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.)

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)


	...that's about 90% of the code of AfterStep, WindowMaker, and
Enlightenment.  Furthermore, for Gnome to be as consistent as a Macintosh,
a Windows95 machine, or a BeOS box, we would have to require that any
"Gnome-compliant" window manager have a configuration utility that used
the Gtk+ widget set and provided drag'n'drop interoperability with the
Gnome configuration utility.

	Some people have even suggested that WM writers be required to use
Corba to communicate with Gnome.   Requiring a window manager--that will
do nothing but manage windows under the Gnome environment (!)--to use
Corba makes no sense, especially when non-Gnome environments won't be able
to use it.

	I believe the easiest thing to do is to create a new class of
window manager, one that is intended only for use under Gnome.  In fact,
this is already happening (although it hasn't really been identified as
such).  The mosquito, GnoWM, and gtkwm projects are of this "class".

	Creating a standard that enforces the use of Gtk+, use of the
Gnome help system, and no duplication of features (that would confuse the
user) makes much more sense that telling the vast majority of window
managers that they need to de-activate 90% of their code to be "Gnome
compliant".  

	Therefor, I suggest that the Gnome project abandon its ideological
view of "use whatever window manager you want" and instead focus on a
document that defines a new class of "Gnome window manager".  Perhaps we
could use the KDE window manager as a model.

	Feedback is welcome, this document is intended to be a catalyst
for discussion.  If people generally agree with this viewpoint, and Miguel
supports this, I will try to put together a "Gnome window manager class
definition" document as a follow-up.  Otherwise, we will need to seriously
consider how we can deal with the duplication and conflict of features of
existing window managers.


Thank You,
Derek Simkowiak
dereks@kd-dev.com