<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
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.
<br>
<br>
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.<br>
<br>
<div class="moz-cite-prefix">On 09/08/15 04:48, Philipp A. wrote:<br>
</div>
<blockquote
cite="mid:CAN8d9g=8Fq-NGYSNi=CafDDGP-Ci4fJ1L_w1qW8fGJYi4sye2Q@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<div>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.<br>
<br>
</div>
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?<br>
</div>
<div><br>
</div>
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”<br>
</div>
<div><br>
</div>
<div>best, philipp<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">Éric Tremblay <<a moz-do-not-send="true"
href="mailto:xdg@deimos.ca">xdg@deimos.ca</a>> schrieb am
Di., 8. Sep. 2015 um 00:40 Uhr:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hello everyone,<br>
<br>
I'm programming little "zoom" animations in XFCE to show the
user in a<br>
logical way, for example, where to click to get a window back
when it<br>
minimizes, or where a window "comes from" when it appears, if
that<br>
applies. The biggest problem with this is that there's no
standard way<br>
for the different processes (window manager, tray icon
manager(s), etc)<br>
to determine or communicate with each other where the *tray
icons* are.<br>
<br>
Taking example of the _NET_WM_ICON_GEOMETRY window property, i
think<br>
i've come up with a clean, simple, and reliable solution.
Here's a<br>
description of how i implemented this in XFCE, however i
attempted to<br>
make it as portable and non-wm-specific as possible, depending
only on<br>
X11/Xlib internals.<br>
<br>
I'm simply using an X property on the root window of the
display called<br>
_NET_WM_TRAY_ICON_GEOMETRIES which follows a simple format.
It's an<br>
array of strings, with each string representing a tray icon,
and<br>
following a format like:<br>
<br>
"mgr=systray,classname=blueman,pid=4522,x=1332,y=1,w=22,h=22"<br>
<br>
In this example, the "mgr" field indcates that this entry was
added by<br>
the "systray" pluign. This information lets more than one
"tray" process<br>
manage the string array on a given X display (as is the case
with XFCE's<br>
"systray" (aka "notify") and "indicator" panel plugins) and
also avoids<br>
the problem where different processes would add duplicate
information,<br>
whcih would quickly saturate the string array. The "classname"
field is<br>
pretty self-explanatory, it's the class name of whatever
window(s) match<br>
up with this systray icon. The "pid" field can help in
matching windows<br>
that have nonexistent or weird class names. If it's absent or
equal to<br>
-1, then that means the PID of the process owning the icon
couldn't be<br>
determined. Finally we have the x,y,w,h screen coordinates of
this tray<br>
icon. In my implementation the fields may be read in any
order, but it's<br>
better to write them in a more consistent format such as the
above.<br>
<br>
(at least for now) If a string contains any semicolon ";" or
newline<br>
characters, these should be treated as separating the entry
into several<br>
entries.<br>
<br>
Upon creating a new systray icon, modifying an existing one,
or deleting<br>
a systray icon, a tray manager process such as the "indicator"
plugin<br>
would do something like the following:<br>
<br>
- choose a name that preferably describes its process
name, such as<br>
"indicator", "notify", or "systray" - this would be the "mgr"
field. It<br>
should be consistent for the entire lifespan of the tray
manager process.<br>
<br>
- grab the X server to avoid race conditions with other
tray managers<br>
<br>
- fetch the strings from the _NET_WM_TRAY_ICON_GEOMETRIES
property<br>
on the X server's root window<br>
<br>
- *remove* all entries whose "mgr" field matches its own
chosen<br>
process name<br>
<br>
- for each tray icon managed by this process: append a
string to<br>
the array in the above format, omitting the "pid" field or
setting it to<br>
-1 if the PID corresponding to the tray icon can't be
determined, and<br>
omitting the "classname" field or setting it to zero-length if
the class<br>
name can't be determined. If both can't be determined for a
specific<br>
entry, it's pretty useless to add that entry.<br>
<br>
- write the string array to the
_NET_WM_TRAY_ICON_GEOMETRIES<br>
property on the X server's root window<br>
<br>
- ungrab the X server<br>
<br>
<br>
The window manager can then easily determine if it should
perform an<br>
animation to/from a tray icon when a window opens or closes,
and if so,<br>
what the screen coordinates of this icon are. In case both a<br>
_NET_WM_ICON_GEOMETRY is present *and* a match in the root
window's<br>
_NET_WM_TRAY_ICON_GEOMETRIES array is found, it's up to the
window<br>
manager to determine which one should take precedence, based
on factors<br>
such as the window's class/role, whether it is itself the
window's<br>
owner, and so on. In some cases, it's also desirable to not
perform the<br>
animation, for example if there are several open windows
matching the<br>
same tray icon - in this case, we'd normally want to animate
only the<br>
last one to close.<br>
<br>
It's also possible to setup a table of "equivalent names" for
processes,<br>
for example we'd want pavucontrol windows (the PulseAudio
volume<br>
control) to be considered as belonging to the
indicator-sound-service<br>
process if it's running.<br>
<br>
Anyway, i've been running my implementation of this on 2 of my
own<br>
machines for a while now, and it seems to work very well.<br>
<br>
Cheers,<br>
<br>
- Éric "delt" Tremblay.<br>
<br>
<br>
_______________________________________________<br>
xdg mailing list<br>
<a moz-do-not-send="true"
href="mailto:xdg@lists.freedesktop.org" target="_blank">xdg@lists.freedesktop.org</a><br>
<a moz-do-not-send="true"
href="http://lists.freedesktop.org/mailman/listinfo/xdg"
rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/xdg</a><br>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>