Re: Open to discussion...

[Dominik Vogt <dominik vogt gmx de>]

On Sun, Jun 20, 1999 at 04:46:44AM -0700, Derek Simkowiak wrote:
> An argument for having a Gnome-specific window manager (or class thereof)
> Author: Derek Simkowiak (dereks@kd-dev.com)

Ah, I don't know how others feel about that. But after the GNOME folks
asked for WM developers to participate in a discussion about DE/WM
compliance I must say that I'm very surprised that you don't even know
if you need window managers at all. You could even consider it rude to
ask people: "Hey, couldn't you help us out here, our spec isn't nice
and we want to improve it. BTW, you won't get anything back for your
effort." To be honest, I'd never expected this attitude from a GNU
project. Isn't one principle of GNU to give users the freedom of
choice, not forcing them to use one particular use model?

> 	Now, the problem:
> 
> 	Many window managers try to provide functionality beyond just
> managing windows.

Yes, the world didn't wait for GNOME to appear before making the
desktop usable ;-)

> They try to become desktop "environments" of their own,
> providing backgrounds, screensaver configurations,

Hm, isn't the root window a window too? Why isn't the window manager allowed
to manage it then?

> 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.

Duh, show me the documents that says it's part of the DE's responsibility to
handle icons. If the WM and the DE are fighting over icons we're doing
something wrong. The classical tasks of window managers are to decorate, move
and resize windows, handle icons, manage events like key and button presses
(okay the ICCCM has a different notion about key and button presses, but
that would take the ability to have hotkeys completely) and provide a virtual
desktop. If WMs would interfere with GNOME because they do what they are
supposed to do, then it's GNOME's fault. My conlusion is that a DE/WM
compliance spec would define interfaces that allow the DE to tell the WM what
it wants. E.g. if it wants a 'shotcut' placed somewhere on the desktop it
should ask the WM to do so by sending an X event to the WM. That's the policy
of X: don't make assumptions how things have to work. I think that's valid
for desktop environmants too. If the GNOME folks don't want to write twenty
different ways of icon handling, then don't force us to use the way you
implement it. The right way is: don't implement it at all, leave its
implementation to the WM.

> 	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.

I can't follow you. Are you saying that users will usually have screwed
up configurations? Of cource this can happen. But how do you think you
usually set backgrounds on a UNIX box? By calling xv/xloadimage/...
manually (i.e. by putting them in some script). Why is this a WM problem.
Your logic implies that a machine that has xv installed is not GNOME
compliant because the user might use it to set the background while GNOME
is running - which could be confusing for the user. If the WM does things
that are not within its responsibility, then don't use them. What you
suggest is the Windoze approach: "Users are idiots. So don't allow them
to do something that is potentially harmful or confusing." 

> 	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.

Again, this should be part of the spec. You can define an interface for
online help pages. You can define a format for the help files. You can
specify a unified coniguration interface. I don't see the problem. BTW,
why do you think managing menus is part of the DE? Even twm, the father
of all window managers ;-) has menus. Following the principles of X
the DE shouldn't try to enforce a look-and-feel upon the WM. Traditionally
the choice of the WM determines how your windows, menus, etc. look like.
Why should the DE concern itself with matters of style. Look at CDE. It's
dtwm that draws them menus, not CDE itself.

> 	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?

Clearly by the WM. In the end the WM holds total control over which
application may receive input events. The DE must not interfere with that.
No application may fiddle with root events on its own. If the DE needs
such events, then we must define a protocol that allows passing such
events from the WM to the DE.

>...
> 	...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.

Sorry, GNOME and KDE have one fundamental flaw if they want to be generic
interfaces like X: they take away the user's choice of a particular
look-and-feel. A good DE shouldn't make assumptions of what things should
look like or how they should work but provide and interface for applications.
E.g. it could provide a help system and a generic configuration system, but
it *should not* tell WMs how menus have to look like. Take fvwm for example
it's designed to be small and fast. How can it be either if it has to use Gtk?

> 	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".

Perhaps the easiest way, but not the right one. I'm participating in
this discussion to find the right way to do things, not to make your
life easy.

> 	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".

Oh, if users want a standard that is enforced upon them they can always
use Windoze. I get the impression that GNOME doesn't fit well into the
world of X applications (and it's nothing more than an application, you
should never forget this). This sounds awfully like the 'easiest approach'.
It's not that WMs have hijacked DE functionality, it's the other way
round. GNOME tries to do more things than it should (I don't know how
KDE does it, but I assume they do it in a mor WM friendly fashion since
they do have their own WM).

BTW, you say 'the Gnome help system'. If each DE has its own help system
we'll get the usual UNIX chaos in the future. What type of help system
should applications use? There has to be a standard for all such interfaces,
not only between WM and DE, but between DE and application too (I was
hoping that this list will discuss both).

> 	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.

Why are you always saying WMs have to adopt the style of GNOME. I see a very
dangerous development here that may harm large parts of the open source
community. A good desktop environmant on UNIX was long overdue and many
people would be willing to convert. Why? Because they hate that Micro$oft
forces them to use their machine in a way that is forced upon them. There
are so many things that don't work well or you would like in another way.
Now we have the chance to make the world a bit better. A large project as
GNOME has a certain responsibility for the whole open source community.
Billy-Boy was the first one to recognize that the OS/GUI is the key to
hold the power over the software business. KDE and GNOME may wield that
power in the future (at least un UNIX) and that brings the responsibility
to not force users to do things in a way that is convenient for the KDE/GNOME
project. Of course it will be much easier for desktop environments if they
can tell WM developers what to do for them. But scanning through the list
of things to turn off (you forgot menus and the stacking order) I wonder
what you'd expect a WM to do then. There's not much left. I can't think of
much more than decorating, moving and resizing windows. Have you ever looked
at the myriad of nice and usable features you will find troughout the WM
world? I can't share your confidence that one big project do everything
better (for the user) than the developers of dozens of WMs.

Bye

Dominik ^_^

--
Dominik Vogt, dominik.vogt@gmx.de
Reply-To: dominik.vogt@gmx.de