Re: Greets (fwd)

[Derek Simkowiak <dereks kd-dev com>]

    All,
	This is Mr. Ettrich's response to the "Argument for having a
Gnome-specific window manager (or class thereof)".  I thought people might
like to know his opinion, given his experience with the KDE window
manager (and the fact that he agrees with me :)...

Thanks,
Derek Simkowiak
dereks@kd-dev.com


---------- Forwarded message ----------
From: Matthias Ettrich <ettrich@troll.no>
To: Derek Simkowiak <dereks@kd-dev.com>
Subject: Re: Greets

On Sun, 20 Jun 1999, you wrote:
> > I just subscribed, so I didn't receive any mails yet. I have, however, browsed
> > the archive, so here are a few comments:
> 
> 	I am sending you this email because I'd like your feedback on it.
> I sent this to the list just before you subscribed.  Please post your
> thoughts back to the wm list.

I'd rather send it back directly to you.

I completely agree, that is exactly my thinking, and what we did with KDE :-)
(Well, not exactly, kwm supports session management directly, but I'm dropping
this for the next version.)


Matthias



> 
> Thanks,
> Derek
> -----------------------------------------------------------
> 
> 	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.
> 
> -----------------------------------------------------------------
> 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, 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.
> 
> 
> Thank You,
> Derek Simkowiak
> dereks@kd-dev.com