<div dir="ltr"><div style="" class="markdown-here-wrapper">Éric, what I said is also in line with Jasper’s comment: <blockquote style="margin:1.2em 0px;border-left:4px solid rgb(221,221,221);padding:0px 1em;color:rgb(119,119,119);quotes:none"> 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. </blockquote> but this model is a classical server/client thing: <ul style="margin:1.2em 0px;padding-left:2em"> <li style="margin:0.5em 0px">your system update notifier checks if there are updates and allows you to launch an (independent) updater</li> <li style="margin:0.5em 0px">your torrent downloader downloads torrents in the background and allows you to lauch a GUI to interact with the queue (maybe it allows multiple different clients)</li> <li style="margin:0.5em 0px">the CUPS server interacts with your printers. a notification icon allows you to see the status of running jobs and to launch a print queue application and printer config dialog</li> </ul> and your music player doesn’t need anything in the notification area because that’s what MPRIS is for. all of those aren’t cases where the client you open “goes to” the notification area once you close the window. you simply close some GUI interacting with the server/daemon running in the background which is represented by the notification area icon. best, philipp <div title="MDH:PGRpdj48ZGl2PjxkaXY+PGRpdj48ZGl2PjxkaXY+w4lyaWMsIHdoYXQgSSBzYWlkIGlzIGFsc28g aW4gbGluZSB3aXRoIEphc3BlcuKAmXMgY29tbWVudDo8YnI+PGJyPiZndDsgSW4gdGhlIFdpbmRv d3Mgd29ybGQsIHN5c3RlbSB0cmF5IGljb25zIHdlcmUgdXNlZCBmb3IgbG9uZyBydW5uaW5nIAph cHBsaWNhdGlvbnMgd2hlcmUgcHV0dGluZyB0aGVtIGluIHRoZSB0YXNrYmFyIHdhcyBjb25zaWRl cmVkICJ0b28gCmhlYXZ5IiwgbGlrZSBJTSBjbGllbnRzIGFuZCBtdXNpYyBwbGF5ZXJzLiBUaGlz IHdhcyB1bHRpbWF0ZWx5IHNlZW4gYXMgYQogcG9vciBkZXNpZ24gZm9yIHRoZSB0YXNrYmFyIHdo aWNoIGhhcyBiZWVuIHNpbmNlIGZpeGVkIGluIFdpbmRvd3MuPGJyPjxicj48L2Rpdj5idXQgdGhp cyBtb2RlbCBpcyBhIGNsYXNzaWNhbCBzZXJ2ZXIvY2xpZW50IHRoaW5nOjxicj48YnI+KiB5b3Vy IHN5c3RlbSB1cGRhdGUgbm90aWZpZXIgY2hlY2tzIGlmIHRoZXJlIGFyZSB1cGRhdGVzIGFuZCBh bGxvd3MgeW91IHRvIGxhdW5jaCBhbiAoaW5kZXBlbmRlbnQpIHVwZGF0ZXI8YnI+PC9kaXY+KiB5 b3VyIHRvcnJlbnQgZG93bmxvYWRlciBkb3dubG9hZHMgdG9ycmVudHMgaW4gdGhlIGJhY2tncm91 bmQgYW5kIGFsbG93cyB5b3UgdG8gbGF1Y2ggYSBHVUkgdG8gaW50ZXJhY3Qgd2l0aCB0aGUgcXVl dWUgKG1heWJlIGl0IGFsbG93cyBtdWx0aXBsZSBkaWZmZXJlbnQgY2xpZW50cyk8YnI+PC9kaXY+ KiB0aGUgQ1VQUyBzZXJ2ZXIgaW50ZXJhY3RzIHdpdGggeW91ciBwcmludGVycy4gYSBub3RpZmlj YXRpb24gaWNvbiBhbGxvd3MgeW91IHRvIHNlZSB0aGUgc3RhdHVzIG9mIHJ1bm5pbmcgam9icyBh bmQgdG8gbGF1bmNoIGEgcHJpbnQgcXVldWUgYXBwbGljYXRpb24gYW5kIHByaW50ZXIgY29uZmln IGRpYWxvZzxicj48YnI+PC9kaXY+YW5kIHlvdXIgbXVzaWMgcGxheWVyIGRvZXNu4oCZdCBuZWVk IGFueXRoaW5nIGluIHRoZSBub3RpZmljYXRpb24gYXJlYSBiZWNhdXNlIHRoYXTigJlzIHdoYXQg TVBSSVMgaXMgZm9yLjxicj48YnI+PC9kaXY+YWxsIG9mIHRob3NlIGFyZW7igJl0IGNhc2VzIHdo ZXJlIHRoZSBjbGllbnQgeW91IG9wZW4g4oCcZ29lcyB0b+KAnSB0aGUgbm90aWZpY2F0aW9uIGFy ZWEgb25jZSB5b3UgY2xvc2UgdGhlIHdpbmRvdy4geW91IHNpbXBseSBjbG9zZSBzb21lIEdVSSBp bnRlcmFjdGluZyB3aXRoIHRoZSBzZXJ2ZXIvZGFlbW9uIHJ1bm5pbmcgaW4gdGhlIGJhY2tncm91 bmQgd2hpY2ggaXMgcmVwcmVzZW50ZWQgYnkgdGhlIG5vdGlmaWNhdGlvbiBhcmVhIGljb24uPGJy Pjxicj48L2Rpdj5iZXN0LCBwaGlsaXBwPGJyPg==" style="height:0;width:0;max-height:0;max-width:0;overflow:hidden;font-size:0em;padding:0;margin:0"></div></div></div> <div class="gmail_quote"><div dir="ltr">Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>> schrieb am Mi., 9. Sep. 2015 um 08:29 Uhr: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, 08 Sep 2015 13:51:48 -0400 Éric Tremblay <<a href="mailto:xdg@deimos.ca" target="_blank">xdg@deimos.ca</a>> wrote: > 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. Hi, well, there are a few of fundamental issues: 1. Wayland/desktop does not have a global coordinate system visible to apps. 2. Wayland does not have global identifiers for any client resources. 3. Wayland does not have a generic client-to-client communication mechanism, that is, there are no generic properties or anything you could abuse as IPC. The first issue is a feature designed on purpose which we've fought hard to keep. The second issue is also a deliberate design, though there are cases where it will be useful to explicitly create a handle for a wl_surface or such, pass it to another process, and let that new process use it as a reference to e.g. tell the compositor who spawned it. This protocol extension is still to be designed. The third issue is on purpose too. Client-to-client communications that do not *absolutely require* specifically the display server to enforce anything should not go through the display server. Besides, due issue #2, there is no way a client could reference another client or its resource at will to begin with. (Client actually means a connection, that is, a wl_display instance; similar Xlib's Display created by XOpenDisplay.) There is also no such concept as "grab the server". You have to design protocol extensions to be race-free from the start. Regardless of whether your idea is a good one or not, in Wayland you would somehow let the compositor know of the relationship between the objects you want to associate, and then the compositor will just do the right thing. Passing coordinates will not work on Wayland/desktop, because clients cannot know where things are. Thanks, pq PS. display server = compositor = window manager, all in one. _______________________________________________ xdg mailing list <a href="mailto:xdg@lists.freedesktop.org" target="_blank">xdg@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/xdg" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/xdg</a> </blockquote></div>