Re: Status Manager

[Gregory Merchan <merchan phys lsu edu>]

On Wed, Mar 20, 2002 at 10:01:16PM -0500, Havoc Pennington wrote:
> 
> 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.

It is irrelevant. The error in the protocol is that the docklet maps
itself before it is in the dock. Thus the dock and the window manager
are attempting to control the same resource and the races ensue.


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

XEMBED, insofar as it is revealed in Gtk+ and in what I found in KDE,
is primarily for dealing with focus between known windows of different
clients, and some other state information between those known windows.
As such it may be part of a docking protocol, but it is insufficient
for the crucial step of discovery. 

Unless the window manager is to be reponsible for the creation of the dock
window, leaving the reparenting to the window manager is also inadequate
for the same reason.


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

The dock (or tray), as well as panels and even other embedding clients are
little different from window managers. They all control shared resources
and deal with mapping for one or more other clients. A window manager is
privledged above these only because it enjoys sole control of redirection 
on a privledged window, the root.


>                                 . . . So tray applets would simply try
> to map themselves inside the tray, and the usual WM stuff would go on,
> when it makes sense. . . . 

Again, the clients still need to find the dock. Even if the the window
manager is involved, it needs to find the dock. By using the selection
manager, all the clients have to do is request conversion and everything
else is normal post-MapNotify behavior. Because the selection manager is
used, clients can also discover the existence, instantiation, and
destruction of the dock.


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

Have you read any of the relevant code or even just mine?
The GNOME docklet library, and probably KDE's also, can be changed to
the selection manager-based protocol without API change. (I don't know
KDE or even C++, or I would confirm it.) For GNOME, the change to this
reliable protocol would be also be a simplification of internal structures
and procedures; just look at the code.


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

There is no reason to leave any part of this to the window manager. The
selection manager is already the best way to guarantee the existence and
uniqueness of the dock and the conversion request which is hidden behind
the API encapsulates this.


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

That doesn't work the same way. A reparenting window manager should reparent
on the MapRequest event, not after the MapNotify. Because the window has
not been mapped when the window manager reparents it, it has not left
the Withdrawn state. The ICCCM is quite clear on this:

 | Only the client can effect a transition into or out of the
 | Withdrawn state.  Once a client's window has left the With­
 | drawn state, the window will be mapped if it is in the Nor­
 | mal state and the window will be unmapped if it is in the
 | Iconic state.  Reparenting window managers must unmap the
 | client's window when it is in the Iconic state, even if an
 | ancestor window being unmapped renders the client's window
 | unviewable.  Conversely, if a reparenting window manager
 | renders the client's window unviewable by unmapping an
 | ancestor, the client's window is by definition in the Iconic
 | state and must also be unmapped.


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

The race occurs because there are two clients attempting to manage the same
resources. There is no reason to burden the window manager with the details
of the status dock such as the number of docklets present, their geometry
and other states. If that were prudent, then toolkits and component systems
would also leave non-toplevel window management to the window manager.


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

My protocol works. The existing one does not. 


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

Once you have fully understood it you will not want to document it.
It is ill-designed for its purpose.


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

Save sets are inadequate because they map the saved windows after reparenting.
They are only needed for abnormal shutdown and recreating docklets in that
case is trivial.


The existing protocol is broken and needs to be replaced.

The proposed protocol is not broken, works regardless of window manager
and desktop environment, and can easily be extened to provide new methods
without breaking any clients or using resource consuming hacks. Perhaps
most importantly, it serves as an example of how the X desktops can
interoperate in other areas such as panels - the same method with a 
different managed selection can be used for that purpose.


Let's get this done,
Gregory Merchan