Re: Status Manager

[Havoc Pennington <hp redhat com>]

Gregory Merchan <merchan baton phys lsu edu> writes:   
> 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. 

Discovery is really easy, I don't even care how it's done as long as
it works.
 
> >                                 . . . 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.

Again, this is easy. But we need to spec out the rest of the problem.

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

I don't know what KDE does, but it's quite possible for the WM to get
MapRequest on the applet, and then reparent into the system tray in
response to the MapRequest.  There is no race there that I see.
What would the race be? Can you explain the specific sequence of
events that occur when the race happens?
 
> The existing protocol is broken and needs to be replaced.
>

Until we all understand the existing protocol, i.e. you or someone
writes down how it works, no one is going to know this.

Havoc