Window managers are components

[Michael Fulbright <msf redhat com>]

M.Rogers@cs.ucl.ac.uk said:
> To answer both points: if you want a pager, use a window manager that
> has a  pager. If you don't want a pager, use a window manager that
> doesn't have a pager. I don't see why the pager should be an external
> application (any more than the root menu, the window borders or the
> close button). Shifting between desktops and tasks is a fundamental
> part of window manager functionality. Instead of writing the Gnome
> pager and then changing existing WMs to work with it, perhaps the
> authors should have written a Gnome-specific  WM with its own pager
> that appeared on the panel.

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

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

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

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.

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

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

Dr Mike