Proposed update to the tray icon specification

[Ryan Lortie]

Hello.

On March 10 I sent an email to the original authors of the tray icon
specification (Havoc and Mark) proposing some changes to the spec.  I
received no reply.

Matthias Clasen was also cc:'d on the email and we discussed the
proposed changes.  Matthias is in agreement with my proposal.

These changes are required to deal with shortcomings in the
specification caused by some assumptions that are no longer valid.  

I've attached a diff to the spec that I'd like to be able to upload.

I'm also including the original mail here for an overview of why these
changes are required.

Cheers

---original mail follows---

Hello.

I'm writing about releasing an update (0.3) to the current
freedesktop.org tray icon specification.

The current tray icon specification has two problems that I would like
to see addressed.  I'm willing to make the changes and publish the new
version if someone explains the process to me.

I'm also willing to update GtkStatusIcon to comply to the new
conventions outlined here, assuming the changes are accepted to the
specification.

The two changes that I feel are required:

1) The current "orientation" hint is broken.

It is set on the manager window despite the fact that individual tray
icons can, in theory, be located in different places.  This includes the
possibility that some tray icons are located on panels with horizontal
orientation and others on panels with vertical orientation.

As a solution to this problem I propose that the tray manager sets a
property on the docking child window specifying which orientation it
should have.  The fallback behaviour would be that clients fall back to
looking at the property set on the manager window.

Specifically:
A client decides its orientation by doing the following:
  1) check if someone has set the orientation property on its window
  2) if no such orientation is set, look at the manager window.

A server notifies of orientation by doing:
  1) set the orientation property on the client window
  2) if all icons have the same orientation, set the property on manager
       -- if orientation is different for some icons then (???)

We might also want to consider adding an "undocked" orientation.  I have
no immediate plans for this but it seems like it might be useful....


2) Visual matching is a problem.

Currently, GtkStatusIcon sets a ParentRelative background pixmap on
itself to indicate that it should obtain its background image from its
parent.  This only works if the parent window and the child window have
the same visual.  It's also a giant hack.

In the current case, if you dock a normal GtkStatusIcon (RGB,
ParentRelative) into a RGBA panel then you get a BadMatch error and the
docking fails.  Fortunately, GtkSocket has X error traps in it, so it
doesn't crash outright.

The real problem, of course, is that the tray icon client currently has
no way of determining the visual of the parent that it is requesting
docking into.  My suggestion is that we use the following convention:

a) The server-side sets the visual of the invisible manager window to
the visual that it wants the children to use for creating their windows.

b) The client inspects the visual of the manager window before creating
its X window and creates the window with this visual.

c) If the server receives a dock request and discovers that the child
window (which it has the XID of as part of the dock request) has the
incorrect visual then it mitigates this problem by destroying and
rerealizing its socket to receive the child into using the correct
visual.  This is fallback behaviour to support clients that don't yet
follow the convention outlined here.

d) If the client sees that the visual of the manager is an RGBA visual
then it turns off all hacks regarding ParentRelative backgrounds and
instead uses a real alpha transparent background for itself.


Feedback on these ideas is appreciated -- including how I can get them
into the spec.

Cheers
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tray-icon-spec.patch
Type: text/x-patch
Size: 5424 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20070318/dcc5595a/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 701 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/xdg/attachments/20070318/dcc5595a/attachment.pgp