Hey all. Thought this would be quite relevant for us to chime in on, regarding the systray. Its happening now on the xdg mailing lists, so if you feel like jumping into the discussion, sign up and copy the subject. Toma
---------- Forwarded message ---------- From: Owen Taylor <[EMAIL PROTECTED]> Date: 2008/9/12 Subject: Comments on Tray Icon spec improvements To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] 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 _______________________________________________ xdg mailing list [EMAIL PROTECTED] http://lists.freedesktop.org/mailman/listinfo/xdg ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
