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 <[email protected]> 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 > [email protected] > http://lists.freedesktop.org/mailman/listinfo/xdg >
_______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
