Re: Status Manager

[Havoc Pennington <hp redhat com>]

Hi,

I forgot you were looking at this. Your original post for reference:
 https://listman.redhat.com/pipermail/xdg-list/2002-February/000243.html

Gregory Merchan <merchan baton phys lsu edu> writes:

>   The documentation I have found on the existing protocol is at:
>     http://developer.kde.org/documentation/kde2arch/protocols-docking.html
>   Other than that, I've had to look at sources to see who is doing
>   what.

The KDE docs are missing some key stuff, like what the WM and actual
dock thingy are supposed to do. I've also heard that a client message
is involved somehow, but I don't see that in the docs.

I'd suggest using the XEMBED for this problem, except that it doesn't
seem to be a short-term solution, since it's quite complex and Owen
and Matthias haven't written it down for the public yet AFAIK, and
Qt/GTK interoperability are AFAIK untested.

The advantage of XEMBED is that a tray applet thing would be a full
widget, that could get focus etc. This may be a requirement for
accessibility and such. Given the trivial tray approaches, it may be
tricky to handle keyboard navigation for example. Possibly the tray
container playing window manager and doing appropriate
XSetInputFocus() works but I'm not sure it does. You would at least
need conventions, for example whether the tray applet or the tray
itself draws the focus rectangle. Maybe you wouldn't need many and
it's not an issue.

To me the obvious way to implement the tray - other than XEMBED - is
that the tray is just a specialized window manager that manages the
tray area instead of the root window. So tray applets would simply try
to map themselves inside the tray, and the usual WM stuff would go on,
when it makes sense. This makes it really easy to implement on the
applet side, because you can just use a regular toplevel toolkit
window, for the most part, possibly with some cheesy toolkit
modifications due to root window assumptions. If we can easily handle
input focus and such, I really like this simple approach.

I guess KDE already works this way, except that they have the root
window manager reparent the applet? This means the WM can use its
existing SubstructureRedirect and the tray doesn't need to fool with
it, and each applet doesn't need to find the tray, only the WM needs to
know the ID of the tray window.
 
> P.S. - This email has bounced back to me a few times. Since then I've
>   learned that, in addition to racing, the existing status dock protocol
>   is a violation of the ICCCM. See section 4.1.4 and the sections referenced
>   therein. The reparenting of the docklet from a mapped state requires
>   an unmapping of the docklet toplevel, but this would be a transition
>   to the Withdrawn state and as such can only be initiated by the docklet
>   client. 

Or it could be initiated without problems by the window manager, just
as the window manager reparents windows into their frames. I don't
know if that's how the KDE protocol works but it could certainly be
done that way. The WM can definitely change client map states and
reparent clients without races.

If it is done that way I don't see any inherent problem with it.

>   I urge that the existing method be dropped as it relies on window manager
>   compliance for what KParts, Bonobo, and other component systems do.
>   The solution I've proposed is independent of the window manager and the
>   various component systems.

I don't consider it important to require or not require window manager
support, as long as the protocol works.

So what I think we need to do is fully understand and document the
current KDE mechanism, use as much of it as possible while addressing
important concerns such as race conditions or keynav issues, move
properties into the _NET namespace, and post the final docs online.

There are a lot of details to hash out, I think - the focus stuff, 
how to avoid destroying the applet window (save sets probably), this
kind of stuff.

Havoc