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