Re: Window managers are components

[Michael ROGERS <M Rogers cs ucl ac uk>]

>This issue seems to hit at the core of a long going conflict.
>
>I personally think window manager do a wonderful job and we of course need
>them. But to the new user who just wants to get job done (50% of the world,
>more?) they probably will never fiddle with a tenth of all the cool
>stuff you guys come up with.

I agree - mosquito is designed not to have any cool stuff at all.  :)

>I think the least common denominator of
>window managers which incorporate what these people need is what should
>be abstracted away from the window manager and into a generic interface.

Unfortunately, the "least common denominator of window managers" means the 
core functionality - allocating focus, handling common window operations, 
icons, and workspaces, and providing window decorations. I really don't see 
how these core elements can be "abstracted away". If there was only one way 
of handling these tasks, there would only be one window manager.

>The original goal for the GNOME pager/panel interface is that someone could
>REPLACE it with a completely new one, without having to touch a line of
>window manager or GNOME library code. Maybe I don't like being stuck with the
>window managers pager - I think its important the window manager is as
>much a component as anything else.

Breaking large applications into components is a great idea, but you have to
divide the application along functional lines. The pager's job and the window 
manager's job are so closely intertwined that I don't think it makes sense
to separate them, because you essentially end up with two applications doing
the same job, with different UI.

>The window manager knows about all
>sorts of specs and standards and UI behavior I never wish to program. I
>as a developer want it to be a blackbox (no pun intended) that does its
>part.

As a developer of what? Exporting the window manager's functionality only 
benefits the authors of pagers. How many pager authors are there in the world?

>I would also argue that having a generic description of these common attributes
>of ALL window managers will leads to a consistent set of configuration tools.
>I still don't understand why we can't have a single config tool to control
>the basics of all window managers, stuff like:
>
> - focus
> - backgrounds
> - desktops
> - keybindings
> - etc

This makes sense, but trying to apply a standard to a diverse set of
existing applications will be difficult.

>I think a LARGE class of users will perceive (or their MIS dept will) a
>huge benefit if they only have to learn (teach) a single set of config
>tools. If they later decide the XYZ window manager really does suck (the
>author got a job at Microsoft and quit maintaining it), they can move
>to the ABC window manager and have the minimum of downtime or learning
>curve. So having a generic pager aids this task.

What if they decide that the generic pager really does suck? I'm not just 
being facetious - why is the pager likely to do a better job than the window 
manager?

>In summary - I don't see how it hurts the creativities of a window manager
>author to export the necessary API for external tools to manager appropriate
>internal state information of the window manager.  There is a small, but
>technically savy, class of users who will never see it and will use the
>window manager in standalone. I would argue the huge majority will be
>using the window manager as a component in a more comprehensive desktop.

I agree, and I expect that the most suitable window managers for desktop 
environments will be those designed *not* to work as standalones. I guess I
just disagree with your definition of "appropriate internal state
information".

>These users user the desktop because it provides a consistent and easy to
>use interface to their applications and configuration of their system.
>They want to learn it ONCE and never need to learn it again.
>This will require the desktop to be able to fiddle with the window manager
>in ways not traditionally supported.

Absolutely, but that's a separate argument. If users want to learn
everything once and never learn it again (which I agree that most do), they
won't switch window managers every two weeks and then wonder why their pager
looks different.

>I see no reason why a window manager cannot support both the old and new
>and lose any freedom or creative expression.

I'm not arguing against compliance, I'm arguing against splitting window
managers into two separate applications.


Michael Rogers