Re: Window Manager configuration utilities

[Greg Badros <gjb cs washington edu>]

Michael ROGERS <M.Rogers@cs.ucl.ac.uk> writes:

> >The spec must make it POSSIBLE for the WM to do the minimal possible
> >thing: managing window borders. 
> 
> I agree, the window manager should restrict itself to managing windows. The 
> desktop environment should restrict itself to "everything but" managing 
> windows.

If we were to take that as a given, it doesn't make sense to have the
desktop manager doing things like iconifying windows, moving them
between desktops, etc.  These are clearly wm jobs;  what the desktop
environment and specifications need are ways to provide hints to the
window manager as to the intent and raison d'etre of the various
windows.

> If we were designing a desktop GUI from the ground up, we probably wouldn't 
> introduce the split between the WM and other desktop components, but since X 
> has a split between the WM and all other clients, we should tailor our design 
> to X. This might mean (shock horror!) that a Win95 taskbar and desktop are
> not the best solution for an X desktop environment.

Their is certainly a desire to provide other applications (desktop
manager, taskbar, pager, panel, whatever) the ability to manipulate
windows.  This can be done in lots of different ways, including any of
numerous IPC mechanisms permitting the applets to issue commands of some 
sort to the window manager.  An alternate possibility is allowing the
desktop environment the ability to swallow windows actaully running
inside the wm process so they only look like they're running inside the
panel, or whatever. 

> >We must include basic interface so that external pagers/taskbars/... can be 
> >implemented in generic way that will work with any WM that supports these 
> >concepts.
> 
> Why do we need external pagers? If the Gnome pager didn't exist, would we be
> making allowances for generic pagers? If I invent the external root menu,
> will we have to add support for that too? (Sorry, rant suppressor is back on.)

There is most definitely something to be said for modular decomposition
of software components.  If we did have a standard interface for pagers
to talk to wms, we turn a cross-product of possibilities into a simple
single interface to support.  Standard software engineering says this is
a Good Thing, and I think we all believe this is true.  I'm skeptical
that the medium for that interface should be ad-hoc IPC mechanisms.
Instead it should either be a Corba interface or some more principled
specification using standardized IPC mechanisms like libICE.

> >Also, applications must be able to set things like 
> >default/workspace/layer/...
> 
> This gives us two design goals: defining WM/DE interaction and extending 
> WM/client interaction. Maybe these should go in separate parts of the spec?
> Both are of interest to WM authors, but one is also of interest to
> application authors.

Yes, they are separate as my longer early message pointed out.  Is is
very important to provide applications with standardized ways to
communicate the intents of its windows to the WM in sufficient semantic
detail that a wm can choose to do the right thing.  This can be viewed
as meta-information about the application; we could this in Scwm just by
having a sequence of window-style rules packaged up with the
application, exploiting the existing distinguishing characteristics of
the top level windows that an application will create.  E.g., a package
might come with an APP.scwmrc-styles file that might look like:

(window-style "Netscape" #:use-style standard-desktop-application)
(window-style "Netscape: Find" #:use-style transient-stays-on-top
                   #:transient-placement-proc move-next-to-netscape-win)

This would be able to manage all the static information about the
desired window semantics.  There is still a need for linking windows
together via window groups, the _WM_TRANSIENT_FOR (and my suggested
analagous _NET_RIPOFF_FOR) property.  The same sort of textual
meta-information could exist for other wms, and that could be the point
of standardization (note with Scwm this makes a helluva lot of sense,
since an application could also provide helper procedures, etc., to
basically inject its own window management code into the window manager
for extendings its possible behaviours).  However, using properties
makes a lot of sense to encode this semantic information (at the expense 
of having to modify legacy X11 applications to provide the appropriate
hints).  Properties are inseparable from the code, and are needed anyway 
for the more dynamic attributes that I just mentioned.

But most applications need not talk to the wm about managing arbitrary
windows!  That is a completely separate area about enabling other
processes to take over part of the WM's duties (or extend them in some
useful way).  We need to clearly dilineate what an ordinary
application's interaction with the WM should be, vs. what a wm-extender
application can do.  There are some gray areas, such as, e.g., should
Emacs be able to iconify itself; my standard answer (which echos ICCCM I
believe) is it should be able to ask, but must deal appropriately if the
wm doesn't agree.  But certainly GNU Emacs has no business modifying
the iconified state of other windows on screen (unless of course there
is a wm-extender library written for a GNU Emacs interface, then Emacs
becomes an extension of the WM and it's fine because it's no longer an
ordinary application).

Greg