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

Tue Sep 8 11:03:29 PDT 2015

As far as I'm aware, Windows does not allow minimizing to tray icon geometry

On Tue, Sep 8, 2015, 10:44 AM Damjan Jovanovic <damjan.jov at gmail.com> 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/xdg/attachments/20150908/cdba0a42/attachment.html>