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

[Éric Tremblay]

Of course windows get *minimized* to either a task bar, or the desktop, 
and not to the tray. But this is for when you *close* a window and the 
program still stays running with a tray icon, such as skype, or 
qjackctl, and so on, or when a window *opens* itself initially, from a 
program that owns a tray icon.

As for wayland, i don't know enough about it, but i would imagine it 
would be trivial to adapt this simple mechanism to wayland.

On 09/08/15 04:48, Philipp A. 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 <mailto: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 <mailto:xdg at lists.freedesktop.org>
>     http://lists.freedesktop.org/mailman/listinfo/xdg
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/xdg/attachments/20150908/332eced3/attachment-0001.html>