Re: Status Manager

[Gregory Merchan <merchan phys lsu edu>]

On Sun, Mar 24, 2002 at 11:09:02AM -0500, Havoc Pennington wrote:
> 
> 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.

If you don't care, then stop stonewalling.


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

I already did. I even provided two sample implementations. I'd provide
samples for KDE if I knew C++, Qt, etc.


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

There is no race (on startup, at least) if the window manager does that
or even simply ignores windows with the property on them. But there is
no need to special case the code in window managers and there's plenty
of reason not to.

If it is wise to leave this to the window manager, then the same holds
for all the panels and all the component architectures.


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

The existing protocol is broken in that it maps a window not meant to be
managed by the window manager when it is still a child of the root window.
That much of it is documented and the rest of the protocol doesn't matter.
I recall even seeing a statement that without a running tray the window
will appear on screen and recommending that it be moved to negative
coordinates to avoid the nuisance of that small window. Unfortunately,
I've not been able to find that document again - it was probably over six
months ago when I read it.


There is no reason to continue asking for documentation of the existing
protocol. A better means exists and is documented.

  Existing Protocol   | Proposed Protocol
 ---------------------+-------------------
   Undocumented       |  Documented
                      |
   Works occasionally |  Works always
                      |


What could be simpler?
Gregory Merchan