On Wed, Sep 28, 2016 at 1:19 PM 0x90 <0...@phocean.net> wrote: > Le 28/09/2016 à 08:03, Sriram Ramkrishna a écrit : > > > > Jean-Christophe Baptiste : to answer your question in regards to the > tray design, last time I heard about it, the design is not complete. I > don't think anybody is quite happy with what we have right now. Allan or > Lapo can probably expand on that. It is my assumption that we aren't done > yet.
Sorry, but that isn't really correct - it's true that nobody is truly happy with what we have, but that doesn't mean that the design is incomplete or somehow in flux. There are two constraints - one of design and one technical - that severely limit the available options: (1) The top right is intended to interact with your system, so we don't want applications to mix-in there. Apart from separating system- and application space, the top bar also behaves like a menubar, that is when a menu is open, you can browse through neighboring menus via keyboard or pointer hover - embedding mini applications inside the top bar would break that pattern. (2) Tray "icons" are really tiny, undecorated application windows. Those applications commonly want to grab keyboard and pointer in reaction to events, which they can only successfully do when there isn't an existing grab by another process. This means: If we want tray icons to be able to show a popup menu, the icon cannot be in a place where gnome-shell itself has grabbed the pointer or keyboard (inside any of the top bar menus, anywhere in the overview, ...). So yes, there are places that make much more sense (at the bottom of the overview, or similar to notifications in a section of the date+time drop down), but those don't work due to (2). And yes, they would work a tad bit better mixed-in with the system UI in the top bar at the cost of the top bar working a tad bit worse, but that's not the right trade-off in our opinion (1). There is an extension to move the icons there, but there is no intention to make this the default, sorry. It may be possible to slightly improve the current tray icon support within those constraints, but I don't expect anything radically better. Frankly, in my opinion time is better spend on fleshing out the design pattern for background apps[0] and advocate it - it's not like 16x16 mini apps that are very limited on where they can appear is a perfect (or even great) solution for the use case of getting long-running applications out of the way. There are cross-desktop ways for adding additional actions to application launchers[1] and notifying the user about noteworthy events without the need of an open window[2], so it's mostly a question of how we expect those pieces to be used together to provide background functionality. From a developer perspective, "open a window when launched while already running in the background" and "open a window when a status icon is clicked while running in the background" aren't very different, at least with GTK+[3]. TL;DR: Running applications in the background is a valid use, and we'd like to improve on what we have. We don't think legacy status icons are a good pattern and discourage their use. Cheers, Florian [0] https://wiki.gnome.org/Design/Whiteboards/BackgroundApps [1] https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s10.html [2] https://developer.gnome.org/gio/stable/GNotification.html [3] https://developer.gnome.org/gio/stable/GApplication.html
_______________________________________________ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
