Comments on Tray Icon spec improvements

[Owen Taylor]

Andreas Cimitan asked me to review the changes in:

 http://lists.freedesktop.org/archives/xdg/2007-March/007866.html

To help move forward getting them actually implemented. The specific
interest was in section two about visuals, but I'll review both parts.

With the proposed improvement in section 1), care would have to be taken
and specified to avoid visual artifacts where the icon first appears
with wrong size and then with the right. Specifically you'd have to
specify the following:

 If a client uses the tray-specific orientation hint:

 - Before sending the SYSTEM_TRAY_REQUEST_DOCK, the status icon must
   set the XEMBED_MAPPED flag in the _XEMBED_INFO structure to 0 so 
   that it will not be mapped immediately on embedding.

 - On receipt of the XEMBED_EMBEDDED_NOTIFY, the tray icon should
   examine the _NET_SYSTEM_TRAY_ORIENTATION property of the embedder
   window, adjust its WMNormalHints accordingly. and then set the
   XEMBED_MAPPED flag.

To me, docking icons in multiple different panels of different
orientations is moving away from handling tray icons to more general
"applets". I don't think this creep is a good idea, so, considering the
complexity of maintaining backwards compatibility (as documented in
Ryan's proposal), and the complexity above, my instinct is that this
change should not be added.

The basic idea of the visual change is sound. I would recommend that
instead of setting the visual of the manager window to match that of the
dock, that a simpler approach of simply setting the visual ID in a
property on the manager window should be taken.

Question: 
  Should this a Colormap ID rather than a visual ID?

Proposed answer: Colormaps are an unnecessary complexity these day:
  everybody uses TrueColor. Maybe specify that the visual must be
  TrueColor, or must be the visual of the default colormap of the
  screen, in which case the default colormap will be used.

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

This is basically correct, except that "socket" isn't even a term used
in the XEMBED spec, and the tray icon spec doesn't say anything about
when the "socket" is created and destroyed. I think this, when formalized
into spec language is something like:
 
 "Before reparenting the tray icon window into a XEMBED embedder window, 
  the tray icon application must query the visual of the tray icon window
  and use an embeder window with that visual, even if that visual differs 
  from that specified in the manager window property."

- Owen