Re: Open to discussion...



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

That's a paper-thin argument. Everything on my screen is a window of
some kind, but it's not all produced by the window manager.

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

This is a valid point - maybe Gnome just shouldn't attempt to have a
Windows-like desktop, which is of limited use anyway when the panel does
everything the Win95 desktop does, in less space.

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

And the policy of Gnome is to try to impose some structure, so that
people can stop worrying about 100 different X standards and get some
work done.

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

Why is the WM's way the right way?

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

One of the aims of both projects is to provide a consistent 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.

What does "an interface for applications" mean if it doesn't involve
specifying what things look like or how they work? What else is there?
How they sound? Smell?

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

Shared libraries; the overall memory usage will be *smaller* if the
window manager uses GTK than if it uses its own toolkit.

I'm not even going to bother taking you up on the Microsoft argument.
Suffice to say, consistency of interface is very important. Consistency
and configurability can coexist.


Michael Rogers



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]