Re: System tray windows

[Owen Taylor <otaylor redhat com>]

Gregory Merchan <merchan baton phys lsu edu> writes:

> Last time I checked the XSETTINGS code, there were some things missing.
> (It was a while ago so my memory may be incorrect.) Please check the samples
> I've provided. They'd better be complete and if they aren't I'd like to be
> informed. (I think I've still not added X error checking.)

The xsettings code intentionally only does a subset of a full
ICCCM selections implmentation; it only handles ownership,
not getting and retrieving data. Getting and retrieving data
requires a lot more code, because things like INCR and MULTIPLE
have to be handled; providing a full selections 

> ConvertSelection vs. ClientMessage
> ----------------------------------
> 
> Client here refers to the requestor clients (docklets) and owner
> refers to the selection owner (dock or tray)
> 
> In the simplest possible method, ConvertSelection is simpler; the one
> I've proposed is not the simplest.
> 
> The simplest possible method would be to use a target like INSERT_REQUESTOR
> which will not use the property but will take the requestor window as the
> one to be embedded.

While it could be argued that this is no more of an abuse of
the selection protocol than sending client messages to the
owner window, it's certainly not less of an abuse, and not
amenable to being used with existing selections implementation.

I think basically, you need to either:

 a) Keep the use of the selection mechanism as limited as possible

Or:

 b) Allow people to use the selection mechanism in a completely
    standard way.

I think a) is preferrable, because:

 - implementing the full selections mechanism is a lot
   of code, and we don't want to exclude people that
   don't have this code already.
   
 - virtually *nobody* implements things like providing
   data from the requestor to the selection owner.
   (Which, I believe is needed in your original proposal)
 
> When the standard communication method is used, the window to be docked
> need never inquire about the owner window.
> 
> Sending the ClientMessage in any case fails to provide notice of error.
> If another were used to provide this notice it could lead to an infinite
> wait when the error is that the owner has ceased to be; the X server handles
> error in that case.

It's not a problem; you can reliably detect changes in the owner
window, then send the message once every time the owner changes.

In fact, XConvertSelection() succeeding is no more of a guarantee
of success than XSendMessage succeeding; all you know in
either case is that an event was sent to the other side.

> Sending the ClientMessage to the owner window may introduce racing if the
> owner changes between when the client gets its id and sends the message.

It's not hard to handle this reliably, and in fact, since only
a small part of the selections protocol is handled by the 
X server, the same care needs to be taken by a selections 
implementation.
 
> Sending the ClientMessage to the root window requires processing from every
> other client which is watching root.

Yes, sending it to the root window would be a bad idea.
 
> ConvertSelection allows clients to check that the manager can handle the
> docking request through use of the TARGETS target and allows for other
> information, such as VERSION, should it be needed.

There's nothing that says that we couldn't provide these targets
with the client message approach (except that we would then
require a full selections implementation), but a property on
the owner window would work as well for version information.
 
> The manager has to be able to handle the hell that is MULTIPLE anyway so
> the side effect target is simple by comparison. Testing the samples
> uncovered bugs in Gtk+'s MULTIPLE handling and they were fixed (afaict)
> before 2.0 was released.

Luckily, we can bypass the issue of MULTIPLE if we don't require
target retrieval.If you don't do this, you are basically requiring people
to have an existing implementation of the selections protocol.
 
> The client side complexities can be completely hidden from application
> developers. The CGDocklet object in the sample does this for Gtk+.
> (It's also similar to the existing GNOME API for docklets.)

[...]
 
> XSETTINGS is a one-to-many protocol and as such using the manager selection
> for uniqueness only is prudent. System tray interaction is one-to-one
> and so as with cut/copy/paste and drag-and-drop it is better to use
> the selection mechanism fully.

Actually, system tray interaction, while a little more complex
than XSETTINGS, is also ownership of a unique resource, and
communication (in this case many-to-one, rather than one-to-many)
with this resource. Which is why using a selection for this
is the right thing to do.
 
> The ClientMessage method, while simpler to code, will either create a
> potential for races or lead to more overhead. But most importantly,
> it does not permit error handling. It also requires the additional
> specifcation of a message format.

Message format isn't a huge thing :-). Making the setup
robust just requires a bit of care in how it is specified.

Regards,
                                        Owen