Proposal: clean way of animating windows to/from system tray icons

Tue Sep 8 10:49:47 PDT 2015

Maybe i expressed myself poorly. When i talk about the "tray icons", i 
mean all derivatives of the "tray" such as notification area, indicator, 
etc... in short, icons that let the user interact with long-running 
processes without constantly having the window open or taking space in a 
task bar. These aren't only used on windows, but also on pretty much 
everly other desktop enviornment.

On 09/08/15 13:43, Damjan Jovanovic wrote:
> You imagine the "Windows world" to exist apart from free desktop DEs.
> That's clearly not the case, as both Wine allows Windows apps to run
> on free desktops, and other multi-platform frameworks that support
> Windows want the same features on other desktops.
>
> On Tue, Sep 8, 2015 at 7:38 PM, Jasper St. Pierre <jstpierre at mecheye.net> wrote:
>> In the Windows world, system tray icons were used for long running
>> applications where putting them in the taskbar was considered "too heavy",
>> like IM clients and music players. This was ultimately seen as a poor design
>> for the taskbar which has been since fixed in Windows.
>>
>> I see no reason to carry this over into free desktop DEs.
>>
>>
>> On Tue, Sep 8, 2015, 1:48 AM Philipp A. <flying-sheep at web.de> wrote:
>>> i don’t think that X11-only solutions make sense in 2015, with wayland
>>> implemented in the big DEs and just waiting for a bit more polish and
>>> testing.
>>>
>>> and the notification area isn’t where stuff gets minimized to – that’s the
>>> task bar. what are the advantages of deviating from this thing that *all*
>>> applications can do, and do something else instead? are a launcher/taskbar
>>> entry with quicklist, counter, progressbar, and dynamic interaction via
>>> MPRIS and a independent notification icon not enough for your application?
>>>
>>> the only similar thing i can think of is that task icons are often able to
>>> launch programs (e.g. the printer notification icon can launch a printer
>>> config dialog, and the update notification a system updater), so maybe it
>>> would make sense to tell WMs where some application launched from, maybe
>>> also generalized: clicked it in a panel menu? launched from the window menu
>>> of another application? notification area? task bar? “WM, please create this
>>> window with a launch animation coming from this rectangle”
>>>
>>> best, philipp
>>>
>>> Éric Tremblay <xdg at deimos.ca> schrieb am Di., 8. Sep. 2015 um 00:40 Uhr:
>>>>
>>>> Hello everyone,
>>>>
>>>> I'm programming little "zoom" animations in XFCE to show the user in a
>>>> logical way, for example, where to click to get a window back when it
>>>> minimizes, or where a window "comes from" when it appears, if that
>>>> applies. The biggest problem with this is that there's no standard way
>>>> for the different processes (window manager, tray icon manager(s), etc)
>>>> to determine or communicate with each other where the *tray icons* are.
>>>>
>>>> Taking example of the _NET_WM_ICON_GEOMETRY window property, i think
>>>> i've come up with a clean, simple, and reliable solution. Here's a
>>>> description of how i implemented this in XFCE, however i attempted to
>>>> make it as portable and non-wm-specific as possible, depending only on
>>>> X11/Xlib internals.
>>>>
>>>> I'm simply using an X property on the root window of the display called
>>>> _NET_WM_TRAY_ICON_GEOMETRIES which follows a simple format. It's an
>>>> array of strings, with each string representing a tray icon, and
>>>> following a format like:
>>>>
>>>> "mgr=systray,classname=blueman,pid=4522,x=1332,y=1,w=22,h=22"
>>>>
>>>> In this example, the "mgr" field indcates that this entry was added by
>>>> the "systray" pluign. This information lets more than one "tray" process
>>>> manage the string array on a given X display (as is the case with XFCE's
>>>> "systray" (aka "notify") and "indicator" panel plugins) and also avoids
>>>> the problem where different processes would add duplicate information,
>>>> whcih would quickly saturate the string array. The "classname" field is
>>>> pretty self-explanatory, it's the class name of whatever window(s) match
>>>> up with this systray icon. The "pid" field can help in matching windows
>>>> that have nonexistent or weird class names. If it's absent or equal to
>>>> -1, then that means the PID of the process owning the icon couldn't be
>>>> determined. Finally we have the x,y,w,h screen coordinates of this tray
>>>> icon. In my implementation the fields may be read in any order, but it's
>>>> better to write them in a more consistent format such as the above.
>>>>
>>>> (at least for now) If a string contains any semicolon ";" or newline
>>>> characters, these should be treated as separating the entry into several
>>>> entries.
>>>>
>>>> Upon creating a new systray icon, modifying an existing one, or deleting
>>>> a systray icon, a tray manager process such as the "indicator" plugin
>>>> would do something like the following:
>>>>
>>>>       - choose a name that preferably describes its process name, such as
>>>> "indicator", "notify", or "systray" - this would be the "mgr" field. It
>>>> should be consistent for the entire lifespan of the tray manager process.
>>>>
>>>>       - grab the X server to avoid race conditions with other tray
>>>> managers
>>>>
>>>>       - fetch the strings from the _NET_WM_TRAY_ICON_GEOMETRIES property
>>>> on the X server's root window
>>>>
>>>>       - *remove* all entries whose "mgr" field matches its own chosen
>>>> process name
>>>>
>>>>       - for each tray icon managed by this process: append a string to
>>>> the array in the above format, omitting the "pid" field or setting it to
>>>> -1 if the PID corresponding to the tray icon can't be determined, and
>>>> omitting the "classname" field or setting it to zero-length if the class
>>>> name can't be determined. If both can't be determined for a specific
>>>> entry, it's pretty useless to add that entry.
>>>>
>>>>       - write the string array to the _NET_WM_TRAY_ICON_GEOMETRIES
>>>> property on the X server's root window
>>>>
>>>>       - ungrab the X server
>>>>
>>>>
>>>> The window manager can then easily determine if it should perform an
>>>> animation to/from a tray icon when a window opens or closes, and if so,
>>>> what the screen coordinates of this icon are. In case both a
>>>> _NET_WM_ICON_GEOMETRY is present *and* a match in the root window's
>>>> _NET_WM_TRAY_ICON_GEOMETRIES array is found, it's up to the window
>>>> manager to determine which one should take precedence, based on factors
>>>> such as the window's class/role, whether it is itself the window's
>>>> owner, and so on. In some cases, it's also desirable to not perform the
>>>> animation, for example if there are several open windows matching the
>>>> same tray icon - in this case, we'd normally want to animate only the
>>>> last one to close.
>>>>
>>>> It's also possible to setup a table of "equivalent names" for processes,
>>>> for example we'd want pavucontrol windows (the PulseAudio volume
>>>> control) to be considered as belonging to the indicator-sound-service
>>>> process if it's running.
>>>>
>>>> Anyway, i've been running my implementation of this on 2 of my own
>>>> machines for a while now, and it seems to work very well.
>>>>
>>>> Cheers,
>>>>
>>>>     - Éric "delt" Tremblay.
>>>>
>>>>
>>>> _______________________________________________
>>>> xdg mailing list
>>>> xdg at lists.freedesktop.org
>>>> http://lists.freedesktop.org/mailman/listinfo/xdg
>>> _______________________________________________
>>> xdg mailing list
>>> xdg at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/xdg
>>
>> _______________________________________________
>> xdg mailing list
>> xdg at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/xdg
>>