Thanks for the clearly written bug report, Clément.

Since we introduced a major redesign for status icons in 3.16, I don't think that another major design change is desirable. It's really not a good idea to make major design changes to the same area so frequently.

Furthermore, since we're looking to retire status icons altogether, particularly with full Wayland adoption planned, I would much sooner that we devote our time to migrating away from status icons [1].

That said, we certainly considered adding status icons to the top bar during the design of the status icon tray that landed for 3.16, and there are a number of reasons why we didn't choose that approach at the time. Some of these concerned the poor way that status icons integrate into the top bar:

 * Existing menus in the top bar have disclosure triangles - status icons wouldn't.
 * Existing menu items can all be consistently opened with either the right or left mouse button - this consistency would be broken by status icons.
 * We try to ensure that the top bar is monochrome, so that it fades into the background. Status icons would undermine this.
 * The top right is focused on system status and system controls. Status icons would muddle this, by mixing in application UI.

Since status icons look and operate quite differently from the shell menus: placing them in a different location made sense in terms of preserving consistency and logical grouping.

The other major reason we didn't want to integrate status icons into the top bar for 3.18 is that it would make them much more visible, and turn them into a first class part of the OS. We felt that this would really confuse in the long-run - it would be rather surprising if we made status icons a prominent integration point in one release, only to pull them altogether shortly afterwards.

Regarding your specific criticisms of the new status icon design, I'm confident that we can address the worst issues within the confines of the current design (by addressing bug 746025 and bug 746787). My personal view is that that will give us something good enough, until such a time when we have to stop supporting status icons altogether.

[1] https://wiki.gnome.org/Design/Whiteboards/StatusIcons

> Since we introduced a major redesign for status icons in 3.16, I don't think
> that another major design change is desirable. It's really not a good idea
> to make major design changes to the same area so frequently.

GNOME 3.16 hasn't even landed in Arch Linux, and will not until the 3.16.1 or 3.16.2 release which gives us a few weeks. And we're talking months for other distros. I think we still have time for that. Power users won't be bothered.

> Furthermore, since we're looking to retire status icons altogether,
> particularly with full Wayland adoption planned, I would much sooner that we
> devote our time to migrating away from status icons [1].

As much as you want it to be retired, it will only be realistically the case for recent GTK apps or Wayland-era apps. I'm pretty sure we will see critical apps using that feature in the next few years, with xwayland around. Otherwise some users will have to stop using GNOME altogether.

> That said, we certainly considered adding status icons to the top bar during
> the design of the status icon tray that landed for 3.16, and there are a
> number of reasons why we didn't choose that approach at the time. Some of
> these concerned the poor way that status icons integrate into the top bar:
> 
>  * Existing menus in the top bar have disclosure triangles - status icons
> wouldn't.

Except the time and date button. That's inconsistency, if you ask me -- maybe remove the triangles?

>  * Existing menu items can all be consistently opened with either the right
> or left mouse button - this consistency would be broken by status icons.

Okay.

>  * We try to ensure that the top bar is monochrome, so that it fades into
> the background. Status icons would undermine this.

That's not the case with the current app indicator. Although you're trying to use symbolic icons now, but most apps don't provide it, so I think it introduces more inconsistency than it helps. Also blueish lines aren't monochrome.

>  * The top right is focused on system status and system controls. Status
> icons would muddle this, by mixing in application UI.

I don't agree. There's *one* menu that focuses on it, but extensions can already muddle it. Not a problem.

> Since status icons look and operate quite differently from the shell menus:
> placing them in a different location made sense in terms of preserving
> consistency and logical grouping.

What about an expendable shell menu between Activities and the current app indicator, if that's technically possible? As long as they have their place in the top bar. But I still think they need to be always visible.

> The other major reason we didn't want to integrate status icons into the top
> bar for 3.18 is that it would make them much more visible, and turn them
> into a first class part of the OS. We felt that this would really confuse in
> the long-run - it would be rather surprising if we made status icons a
> prominent integration point in one release, only to pull them altogether
> shortly afterwards.

Breaking a critical feature isn't a good idea either. Furthermore, only a few apps use it, so in most cases it won't change anything. But I'm pretty sure it won't be pulled "shortly".

> Regarding your specific criticisms of the new status icon design, I'm
> confident that we can address the worst issues within the confines of the
> current design (by addressing bug 746025 and bug 746787). My personal view
> is that that will give us something good enough, until such a time when we
> have to stop supporting status icons altogether.

My point is that these two particular issues are not only details of the design, but major issues in the design. It should be started fresh.

My frustration is that for application developers currently using status icons properly (the Dropbox case), there's no great replacement API for them that gives the experience that users want. So I'm not exactly sure how we'll phase out status icons without a replacement API.

It would be remarkably easy for me to code up a proper-working replacement for status icons that's already supported by KDE and Unity (and used by Dropbox and other applications), but I've been told "no".

So now I have my Dropbox icon in the lower left in sort of an awkward corner and I have to hover over it and block my application to tell when my upload is done, rather than glance from a distance.

That's why I use topicons.

(In reply to Jasper St. Pierre from comment #3)
> My frustration is that for application developers currently using status
> icons properly (the Dropbox case), there's no great replacement API for them
> that gives the experience that users want. So I'm not exactly sure how we'll
> phase out status icons without a replacement API.
> 
> It would be remarkably easy for me to code up a proper-working replacement
> for status icons that's already supported by KDE and Unity (and used by
> Dropbox and other applications), but I've been told "no".
> 
> So now I have my Dropbox icon in the lower left in sort of an awkward corner
> and I have to hover over it and block my application to tell when my upload
> is done, rather than glance from a distance.
> 
> That's why I use topicons.

I think status icons can be replaced as persistent notifications, as ones Rhythmbox application use.

By default they will be in short form, defined by application. Which describe current status application have (Either Dropbox is syncing something right now, or it's done. If it is IM application, current status or last received unread message... And so on).

But there be also "expanded" form, which will be shown then you click on persistent notification. Where are can be some additional buttons, and additional information. (Dropbox can show where last synced files, button for showing context menu, "Open Dropbox" button...). 

But for support of over DE of this, this feature must be added to libnotify, rather than to gnome-shell. And gnome-shell will just provide support of this libnotify feature.

And also, is it possible what status icons can be wrapped by gnome shell as notifications?

So icon of this status icon will be a icon of notification, tooltip will be as text of notification...

Persistent notifications are going away. They were an ill-defined feature with lots of tricky edge cases.

libnotify is effectively API frozen. GNotification is the new notifications API.

(In reply to Jasper St. Pierre from comment #6)
> Persistent notifications are going away. They were an ill-defined feature
> with lots of tricky edge cases.
What does that mean? Will be removed in future?

> libnotify is effectively API frozen. GNotification is the new notifications
> API.
Okay, but i wounder how support for GNotifications will be look in Qt Projects...

(In reply to Jasper St. Pierre from comment #3)
> My frustration is that for application developers currently using status
> icons properly (the Dropbox case), there's no great replacement API for them
> that gives the experience that users want. So I'm not exactly sure how we'll
> phase out status icons without a replacement API.

This exactly is on my mind every time I see people talking about retiring status icons. Nobody mentions what is going to replace them and how.

The main use cases I see are:
1. Long running apps, that you want to use from time to time.
- instant messengers
- Skype

2. Long running services, for which you want to see their status from time to time, or be able to exit them.
- Dropbox. I share certain apps config files using Dropbox across several computers. When I switch computers, first I want to be sure that Dropbox is fully synced, and only then I'll run one of those apps. For that, I need to see Dropbox icon.
- Goldendict clipboard/text selection monitoring. I don't want to dictionary window to be open all the time. But I want its clipboard or text selection monitoring feature, so that I can easily translate text from different apps just by selecting the text. For that, I need a status icon to see that it's running, and be able to quit it if needed.
- Redshift. I want to see whether my screen color has already started turning red during the night, and enable/disable it if needed.

3. Hybrids.
- Steam. This includes game downloading/updating in the background, chat with friends, some other community features (e.g. discussion forums, the market) and also a hub for running games. I want this to be running in background most of the time, but I also want to switch to its window from time to time, and exit it if desired.


I have no idea how GNOME is going to accommodate these use cases without status icons, or without some replacement. I'd love to hear/read about some plans/proposals.

Allan, care to comment on this, please?

(In reply to Clément Guérin from comment #2)

I'm only replying to key issues. Otherwise the thread will spiral.

> > Since we introduced a major redesign for status icons in 3.16, I don't think
> > that another major design change is desirable. It's really not a good idea
> > to make major design changes to the same area so frequently.
> 
> GNOME 3.16 hasn't even landed in Arch Linux, and will not until the 3.16.1
> or 3.16.2 release which gives us a few weeks. And we're talking months for
> other distros. I think we still have time for that. Power users won't be
> bothered.

We don't change UI in stable versions. The 3.15.x/3.16.x series has been in UI freeze since the middle February.

> > Since status icons look and operate quite differently from the shell menus:
> > placing them in a different location made sense in terms of preserving
> > consistency and logical grouping.
> 
> What about an expendable shell menu between Activities and the current app
> indicator, if that's technically possible?

No, it's not technically possible.

> > The other major reason we didn't want to integrate status icons into the top
> > bar for 3.18 is that it would make them much more visible, and turn them
> > into a first class part of the OS. We felt that this would really confuse in
> > the long-run - it would be rather surprising if we made status icons a
> > prominent integration point in one release, only to pull them altogether
> > shortly afterwards.
> 
> Breaking a critical feature isn't a good idea either. Furthermore, only a
> few apps use it, so in most cases it won't change anything. But I'm pretty
> sure it won't be pulled "shortly".

Status icons won't be supported under a full Wayland session. We are aiming to make that possible for 3.18.

> > Regarding your specific criticisms of the new status icon design, I'm
> > confident that we can address the worst issues within the confines of the
> > current design (by addressing bug 746025 and bug 746787). My personal view
> > is that that will give us something good enough, until such a time when we
> > have to stop supporting status icons altogether.
> 
> My point is that these two particular issues are not only details of the
> design, but major issues in the design. ...

The fact that they are major issues doesn't negate the fact that they can be addressed within the current design.

(In reply to Kamil Páral from comment #8)
...
> Allan, care to comment on this, please?

This is a bug tracker - it isn't the place to discuss designs for every conceivable status icon use case. I've already pointed to the planning page for status icons [1], and would be happy to answer questions elsewhere.

[1] https://wiki.gnome.org/Design/Whiteboards/StatusIcons

(In reply to Allan Day from comment #10)
...
> [1] https://wiki.gnome.org/Design/Whiteboards/StatusIcons

My fault, I completely missed this link in your first reply. It provides a lot of information I was looking for. Thanks.

Allan, what about merging TopIcons in gnome-shell-extensions, in addition to improving upon the current design?

Status icons will continue to work fine in a Wayland-based world, through Xwayland. I wrote the code for this.

Jasper, you did not answered me.

(In reply to Jasper St. Pierre from comment #6)
> Persistent notifications are going away. They were an ill-defined feature
> with lots of tricky edge cases.
What does that mean? Will be removed in future?

When I was working on the notification designs, yes, persistent notifications were gone. I don't know what plans Florian or Allan have in the works for that, though. I'm relatively out of touch with GNOME Shell these days.

(In reply to Clément Guérin from comment #12)
> Allan, what about merging TopIcons in gnome-shell-extensions

As written before, "The other major reason we didn't want to integrate status icons into the top bar for 3.18 is that it would make them much more visible, and turn them into a first class part of the OS."
If TopIcons provides some functionality that would not make status icons much more visible, please feel free to elaborate.

(In reply to Jasper St. Pierre from comment #15)
> When I was working on the notification designs, yes, persistent
> notifications were gone. I don't know what plans Florian or Allan have in
> the works for that, though. I'm relatively out of touch with GNOME Shell
> these days.

It is sad what they are gone.

Thank you for answer.

(In reply to Jasper St. Pierre from comment #13)
> Status icons will continue to work fine in a Wayland-based world, through
> Xwayland. I wrote the code for this.

Ah, thanks. I didn't know that. It would still be good to retire status icons sooner rather than later, but that could certainly affect the timeline.

(In reply to Allan Day from comment #18)
> (In reply to Jasper St. Pierre from comment #13)
> > Status icons will continue to work fine in a Wayland-based world, through
> > Xwayland. I wrote the code for this.
> 
> Ah, thanks. I didn't know that. It would still be good to retire status
> icons sooner rather than later, but that could certainly affect the timeline.

The point was that there are no such thing as "status icons" for *native* wayland apps [1]. X11 apps aren't going away any time soon and some of them do use status icons.

We have been fighting them since 3.0 with limited to no success. We tell app developers "just use notifications" but that is not what they so they ignore this recommendation. And some apps are simply cross platfrom apps that reuse that pattern (skype, pidgin, steam, dropbox, ...).


1: OK there is the app indicator stuff that should be supportable but we don't support it at all currently.

> We have been fighting them since 3.0 with limited to no success. We tell app
> developers "just use notifications" but that is not what they so they ignore
> this recommendation. And some apps are simply cross platfrom apps that reuse
> that pattern (skype, pidgin, steam, dropbox, ...).

I think the application developers ignore this recommendation because they see no usable replacement. Some applications need to run in background permanently. As far as I know only tray icons provide these two features:
1) provide any feedback to the user. most important fact: "this background service is running" or "status is …"
2) provide an easy way for the user to interact with the application.


When using my RSS reader and I want to update all feeds I do this:
1. right-click on tray icon (in top bar thanks to topicons)
2. press the "refresh" menu entry

If the RSS reader had no tray icon and I didn't have topicons installed, it would be much more complicated:
1. open activities overview
2. type the application name and press enter or select it from favorites
3. wait for the application window to start
4. press some "refresh" button or menu entry
5. close the application

This workflow affects many other tray icons like dropbox (connect/disconnect from the internet). Tray icons often exist for a reason: fast user interaction without having the application started and one (or multiple) windows displaying.


There is another break in this design: gnome-shell provides some tray icons permanently visible, it includes the menu for connections, volume and logout/shutdown. Depending on the user's preferences there is a accessibility tray, a keyboard change tray, etc. visible. So in fact something like a system tray is existing and permanently visible in gnome-shell. The only difference to ordinary application tray icons is that they are provided by gnome-shell itself. If you want to get rid of tray icons consistently you have to get rid of these too – which makes no sense.


Even for some basic user interaction like this the idea of "just get rid of tray icons" is broken. I second the idea that https://wiki.gnome.org/Design/Whiteboards/StatusIcons needs some rework.

If I understand correctly, it's not technically possible to put the icons in the notifications panel without breaking their right-click functionality. Is it different from the current drawer, where it works?

The problems with having the drawer on the bottom left can never be solved adequately. Having another monitor on the left makes it worse.

(In reply to Clément Guérin from comment #0)
> it would be nice to have
> an overflow button in the top bar that reveals (expands) the tray icons when
> clicked.

This would be a nice solution, even if it's only for a transitional period.

The only other possible solution would be to only show the (expanded) drawer on the Activities Overview screen, but that's not much improvement over the previous versions.

(In reply to Pavlos Touboulidis from comment #21)
> If I understand correctly, it's not technically possible to put the icons in
> the notifications panel without breaking their right-click functionality. Is
> it different from the current drawer, where it works?

We grab the pointer when opening a top bar menu, which is necessary for behavior like dismissing the menu on "outside clicks". That means that if an application tries to grab the pointer (for instance because it wants to pop up a menu for a legacy status icon), the grab will fail.
So this is a limitation that applies everywhere where we take a grab, namely the overview as well.

Created attachment 304758 [details]
A design proposal

This is a very quick and ugly mockup about my idea on how to handle this and not confuse users. Icons are where they are expected to be: next to notifications. I don't understand very well the technical limitations, but I think right click should not interfere with anything since there is no right-click action in any element in the date drawer.

I like this idea you did in your mockup.

There is only one limitation related to right click: It does not exist on touch devices, but gnome-shell otherwise supports them.

(In reply to Yajo from comment #23)
> I don't understand very well the technical limitations, but I
> think right click should not interfere with anything since there is no
> right-click action in any element in the date drawer.

The right click is not the issue - status icons would indeed receive it just fine. However virtually all implementations will try to grab the keyboard and pointer when opening a popup menu, which will fail as both are already grabbed by the date drop-down.

And is it not possible to do a sub-grab? Grab it and return it back to the previous grabber when finished?

(In reply to Yajo from comment #26)
> And is it not possible to do a sub-grab? Grab it and return it back to the
> previous grabber when finished?

No; not without changing how X11 grabs work i.e changing X itself which might cause issues for existing applications.

Not perfect but can you close the popup panel and release the grab before forwarding the right-click to the icon?

(In reply to Pavlos Touboulidis from comment #28)
> Not perfect but can you close the popup panel and release the grab before
> forwarding the right-click to the icon?

There is no guarantee that the other application will take a grab and show a menu. Some, like Skype (I think?) pop up their application window instead.

This "ungrab" was the solution done with the message tray in 3.8, and nobody really liked it -- it caused a floating menu in the middle of the screen most of the time.

(In reply to Jasper St. Pierre from comment #29)
> (In reply to Pavlos Touboulidis from comment #28)
> > Not perfect but can you close the popup panel and release the grab before
> > forwarding the right-click to the icon?
> 
> There is no guarantee that the other application will take a grab and show a
> menu. Some, like Skype (I think?) pop up their application window instead.
> 
> This "ungrab" was the solution done with the message tray in 3.8, and nobody
> really liked it -- it caused a floating menu in the middle of the screen
> most of the time.

Is it possible to just implement something like AppIndicator/KStatusNotifierItem in gnome-shell, and use this instead of *legacy status tray*?

Many of applications already support this API.

Just show them where Yajo showed in his mockup.

AppIndicator is internal to Unity / Canonical. It uses a custom service called dbusmenu that relies on downstream GTK+ patches to parse a menu structure, and the menu protocol is not stable and has changed before. We wrote GMenu upstream as a replacement, but as far as I can tell, Canonical has stopped exposing indicators as a supported API to third-parties, so they've stopped development work on the libappindicator library.

KStatusNotifierItem is unrelated (though AppIndicators were at one point loosely based on the KStatusNotifierItem spec) and isn't as useful to us.

If we want to support indicator-style UIs as a application extension point, we would likely make our own version inside GIO or GTK+ itself, but I don't think we currently have any desire to do so.

(In reply to Jasper St. Pierre from comment #31)
> AppIndicator is internal to Unity / Canonical.

I guess this is no longer the case, because the D-Bus protocol wrapped by libappindicator is now the only way to display tray icons in KDE: https://lists.fedoraproject.org/pipermail/devel/2014-March/196343.html

If we decide to support tray icons (which I thought we wanted to remove without replacement?), then we should have a very strong reason for not using the same tech as Unity and KDE.

Nope, that's KStatusNotifierItem, which appindicator can be compatible with, but still has the same "grab" issue that causes us issues in the existing implementation. libdbusmenu which lets us shove menus over DBus for remote display is still Canonical-only.

You can even see that here: http://www.notmart.org/misc/statusnotifieritem/statusnotifieritem.html

"""
VOID org.freedesktop.StatusNotifierItem.ContextMenu (INT x, INT y);

Asks the status notifier item to show a context menu, this is typically a consequence of user input, such as mouse right click over the graphical representation of the item.

the x and y parameters are in screen coordinates and is to be considered an hint to the item about where to show the context menu.
"""

It's a little bit better, but there are still some grab-related issues. There's still guarantee that the ContextMenu method would take a grab, for tray icons that don't support context menus. Perhaps we should ask KDE to modify the spec to return an error if the item doesn't support context menus, which I believe should cover all the cases. But that doesn't fix existing implementations.

Also, note that my employer has an issue with me looking at Canonical-owned source code under the proprietary copyright assignment agreement, so I cannot recommend using libappindicator as part of our platform because I cannot vouch for its code quality.

I mostly read the discussion about this (But not all!)
I know you don't want it visible, you don't like it ... but once again (I asked for this multiple times bugzilla, irc, ...) please integrate topicons into 3.18.x and leave it like that until no application uses old systray. 

By default when you start gnome-shell there is no systray icons, so people who use it (shell) and don't like them (tray icons) won't see any. If they still hate displaying systray icons in the top bar they can always boycott applications/developers who use them in their applications, or if possible disable tray icons for application in its settings. 
This way you won't cover any application like issues with terminal, you will have functional tray (which is really needed!).

Once again, PLEASE fix this. It is old hack, it is ugly, we need a replacement ..., but until then we need it usable in the current hacked ugly state!

Legacy Tray Handle obscures text in fullscreen terminal windows.

Legacy Tray should be in the top bar somewhere.

Stop hiding it. All of your ideas for hiding are not usable.

I think the right approach for this would be to add the tray icons in the dashboard view only. Like the system monitor extension, once on the dash you would be able to see the dropbox or any tray icon in the bottom left for example.
It would make it easy to reach with the keyboard too.

I'm going to close this bug per the reasons in comment #1.

(In reply to jf from comment #37)
> I think the right approach for this would be to add the tray icons in the
> dashboard view only. Like the system monitor extension, once on the dash you
> would be able to see the dropbox or any tray icon in the bottom left for
> example.
> It would make it easy to reach with the keyboard too.

I'd still prefer to remove the tray entirely -- applications that break without it are just broken -- but this actually sounds like a pretty good compromise solution. It would make the current legacy tray much less annoying.

I think it's worth filing a different enhancement-level bug report for this, though.

(In reply to jf from comment #37)
> I think the right approach for this would be to add the tray icons in the
> dashboard view only.

That would only work for status icons that do not pop up a menu, because pointer and keyboard are grabbed by gnome-shell when the overview is shown. So no, this has been suggested a million times, but it's simply not possible.

Well I think the majority of people don't like the tray icons drawer. There would have been so much less problem and annoyance if the tray icons was kept, where they belong, in the top panel. Even Fedora now explain how to put the tray icons back in the top panel.

https://fedoramagazine.org/move-status-icons-to-your-gnome-top-bar/

I don't think there will be changes now but, still, it will be great if the tray icon can be displayed in the top panel by default.

Even if I disagree with some of the decisions made, I want to thank you anyway for your amazing work. So thanks !