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

[Philipp A.]

Éric, what I said is also in line with Jasper’s comment:

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.

but this model is a classical server/client thing:

   - your system update notifier checks if there are updates and allows you
   to launch an (independent) updater
   - 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)
   - 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

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
​

Pekka Paalanen <ppaalanen at gmail.com> schrieb am Mi., 9. Sep. 2015 um
08:29 Uhr:

> On Tue, 08 Sep 2015 13:51:48 -0400
> Éric Tremblay <xdg at deimos.ca> 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
> 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/20150909/60c13681/attachment.html>