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

[Philipp A.]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/xdg/attachments/20150908/84f9808e/attachment.html>