Re: Status Manager

[Gregory Merchan <merchan phys lsu edu>]

On Tue, Feb 12, 2002 at 08:23:30PM -0500, Havoc Pennington wrote:
> 
> Hi,
> 
> We need a summary of existing solutions, how they work, intended
> goals, requirements for a solution, etc.

The existing method is ... hard to find documentation for.
There are three methods of which I'm aware. The first entirely window
manager dependent; setting a property on the window before mapping.
GNOME supports two methods: the KDE method and a CORBA method.
The CORBA method is not suitable for all X desktops. The KDE method
seems to be to create a window, send a client message, and map.
If no status dock is available, this results in a window which will
be managed by the window manager and introduces unnecessary overhead
for both the docklet-running client and the window manager. As there
seems to be no restriction on the number of clients which reparent
status windows, there is no way to determine which client will actually
do so; they'll race. This is apparently already a problem on GNOME
because sawfish usually beats the others to managing mapped windows -
the source of many gabber bug reports, I hear (often).


> The actual mechanism can be any number of trivial things, once you
> have that.
> 
> This mechanism is missing any number of details (how do you close a
> status docklet? what happens if the panel crashes, or you log out and
> log back in?) - because it needs the high-level before worrying about
> mechanism.

The docklet is closed by quiting the application which provided it, by
an explicit command to do so within the application, or from a control
which the status docklet may provide, such as a menu.

If the panel crashes, then the clients should receive a DestroyNotify
event because they have selected for SubstructureNotify on the manager
window. The clients then resume watching for a new status manager to
appear which will be indicated by the appropriate client message to the
root window. The same is the case for any other removal of the status dock.

Handling logging in and out - i.e., maintainance of session - is the
responsibility of the client providing the status docklet as usual.

Basically the status dock continues to be what it already is: a special
window manager. The details of size and colormap allocation are the same
and both the dock and the docklets should act accordingly. As far as I
can tell, current practice is that the swallowed window is typically
24x24, contains an image, and responds to some button events and maybe DnD.


> If the requirements allow I think it's better to avoid selection stuff
> whenever possible, because it's complex to implement.
>
> Havoc

The bulk of the complexity should already be part of the existing
toolkits and the remainder of the complexity need only be provided by
the status dock and libraries of the particular platform. The
application programmer need not be aware of the mechanism being used.

The complexity of implementing a selection manager is not much greater
than that of any selection owner and is already a requirement for any
window manager which will comply with ICCCM 2.0, as is already required
by the Extended Window Manager Hints specification of 10 March 2001.

Applets could also be made to work for any desktop environment by using
a similar mechanism.


Cheers,
Gregory Merchan