After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 721596 - Legacy tray icons of some applications either too small or appear blank/missing
Legacy tray icons of some applications either too small or appear blank/missing
Status: RESOLVED WONTFIX
Product: gnome-shell
Classification: Core
Component: message-tray
3.16.x
Other Linux
: High normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
: 729016 730288 731857 733992 741518 743337 744160 744231 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2014-01-05 19:54 UTC by Mantas Mikulėnas (grawity)
Modified: 2017-08-19 22:21 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
window-actor: Remove unobscured region optimization in get_paint_volume (1.30 KB, patch)
2014-01-06 20:15 UTC, drago01
none Details | Review
window-group: Don't set unobscured region when we have mapped clones (2.66 KB, patch)
2014-01-07 17:07 UTC, drago01
rejected Details | Review
window-actor: Fix unobscured_region handling when computing paint volume (1.33 KB, patch)
2014-01-31 11:28 UTC, drago01
committed Details | Review
Invisible or improperly rendered tray icons (26.25 KB, image/png)
2014-05-01 08:34 UTC, Tobias Getzner
  Details
invisible gajim icon in new legacy tray (560.62 KB, image/png)
2015-03-11 12:40 UTC, Kamil Páral
  Details
broken_tray_gnome_3_16.png (5.34 KB, image/png)
2015-04-27 10:24 UTC, Vasily Khoruzhick
  Details
screenshot of right-click on dropbox opens firefox menu (52.87 KB, image/png)
2016-08-26 11:04 UTC, Anass Ahmed
  Details

Description Mantas Mikulėnas (grawity) 2014-01-05 19:54:58 UTC
Recently, the legacy "tray icons" – Dropbox, Skype, Google Music Manager – have started showing up completely blank in my message tray. Sometimes they show up for a short time after logging in, but later become blank again.

It seems this was broken by mutter commit 3.11.2-46-g8e74880 ("window-actor: Fix optimization in get_paint_volume").

gnome-shell 3.11.3-23-gc2d6859
mutter 3.11.2-45-g6891ce9 (good)
mutter 3.11.2-46-g8e74880 (bad)
Comment 1 drago01 2014-01-06 20:15:13 UTC
Created attachment 265475 [details] [review]
window-actor: Remove unobscured region optimization in get_paint_volume

This has been done because it looked like an obvious thing to do but never got
tested in 3.10 due to a thinko and now that it got fixed it causes problems
for off screen windows like the legacy tray icons.

So just remove it as it does not seem to gain much but cause problems.
Comment 2 Mantas Mikulėnas (grawity) 2014-01-06 20:45:35 UTC
Tested, seems to work.
Comment 3 drago01 2014-01-07 17:07:29 UTC
Created attachment 265547 [details] [review]
window-group: Don't set unobscured region when we have mapped clones

This is results into a wrong paint volume and thus drawing artifacts for
untransformed clones (like the legacy tray icons).

---

Does this one work as well?
Comment 4 Mantas Mikulėnas (grawity) 2014-01-07 17:15:13 UTC
(In reply to comment #3)
> Created an attachment (id=265547) [details] [review]
> window-group: Don't set unobscured region when we have mapped clones
> 
> This is results into a wrong paint volume and thus drawing artifacts for
> untransformed clones (like the legacy tray icons).
> 
> ---
> 
> Does this one work as well?

No, the bug remains (tried on top of latest mutter-git).
Comment 5 drago01 2014-01-07 18:24:25 UTC
Review of attachment 265547 [details] [review]:

Doesn't help / work.
Comment 6 drago01 2014-01-31 11:28:11 UTC
Created attachment 267718 [details] [review]
window-actor: Fix unobscured_region handling when computing paint volume

We currently ignore the unobscured region when we have mapped clones in
meta_window_actor_process_damage and meta_window_actor_damage_all but
use it unconditionally when computing the paint volume.
This is wrong. We should ignore it there as well or we will end up with
empty clones if the cloned window is completly obscured
(like the tray icons in gnome-shell).

---

OK finally got time to really look it. This should fix it and leave the 
optimization in place.
Comment 7 Rui Matos 2014-01-31 12:17:13 UTC
Review of attachment 267718 [details] [review]:

This looks correct.

Jasper's surface-content branch moves this code around: https://git.gnome.org/browse/mutter/commit/?h=wip/surface-content&id=14d921f6850426ae8212d07f01e56739c3d7b1fe.

Perhaps we should factor out an effective_unobscured_region() function like that patch does and use it here already?
Comment 8 drago01 2014-01-31 12:20:40 UTC
(In reply to comment #7)
> Review of attachment 267718 [details] [review]:
> 
> This looks correct.
> 
> Jasper's surface-content branch moves this code around:
> https://git.gnome.org/browse/mutter/commit/?h=wip/surface-content&id=14d921f6850426ae8212d07f01e56739c3d7b1fe.
> 
> Perhaps we should factor out an effective_unobscured_region() function like
> that patch does and use it here already?

We could do that or just get the fix in and use effective_unobscured_region once that branch lands. 

I am fine either way ... Jasper?
Comment 9 Jasper St. Pierre (not reading bugmail) 2014-01-31 14:07:59 UTC
The patch can land for now, and I'll fix up my code when I rebase.
Comment 10 Tobias Getzner 2014-04-21 11:29:24 UTC
I’m still experiencing this bug in 3.12.1. In fact it’s become a bit more severe in that the icons now consistently come up empty, while in 3.10 they sometimes worked and only became blank when something changed on the client side.

Another change has been that as of 3.12, when the icons are not invisible, they sometimes show as what appears to be a colored block of ~5x5 pixels. In 3.10, the icons were sometimes impropertly sized, but always appeared to be valid icon-sizes.

I can reproduce this in all of my tray-enabled applications, which are Gajim, Owncloud, Steam, Tomboy and Guake. But I suppose these are all legacy-based?
Comment 11 Tobias Getzner 2014-04-24 07:48:55 UTC
Could someone reopen this for 3.12 please? Thank you!
Comment 12 drago01 2014-04-24 08:38:36 UTC
(In reply to comment #11)
> Could someone reopen this for 3.12 please? Thank you!

Sure but fwiw I just tried to reproduce but couldn't.
Comment 13 Tobias Getzner 2014-05-01 08:25:30 UTC
Any info that would be helpful diagnosing? Is there some way for me to inspect this with the looking glass? I see the issue on all of my Gnome machines.

The bug seems to be racy; during the last week the 3.12 behavior was again the same as in 3.10, i.e. some of the tray icons come up okay occasionally, but become invisible as soon as the client does something with them.
Comment 14 Tobias Getzner 2014-05-01 08:34:02 UTC
Created attachment 275524 [details]
Invisible or improperly rendered tray icons

Icons partly invisible, partly rendered infitesimally small, partly wrongly sized (owncloud). The yellow pixel is the tomboy icon.
Comment 15 Tobias Getzner 2014-05-01 08:43:18 UTC
On that screenshot, none of the icons is currently invisible. On invisible icons, I just see the blank space and the mouse-over overlay.

Actually, those pixel-sized icons seem to be new with 3.12, in 3.10, they were only completey invisible or improperly-sized like the owncloud one.
Comment 16 Andreas Kloeckner 2014-07-07 18:15:16 UTC
I'm seeing this as well, on Debian's 3.12.2-2. Most of the misrendering survives after a shell restart, as well.
Comment 17 Andreas Kloeckner 2014-10-19 19:17:54 UTC
Still present in 3.14.1.
Comment 18 André Klapper 2015-01-24 00:39:41 UTC
*** Bug 731857 has been marked as a duplicate of this bug. ***
Comment 19 André Klapper 2015-01-24 00:40:21 UTC
*** Bug 741518 has been marked as a duplicate of this bug. ***
Comment 20 André Klapper 2015-01-24 00:40:57 UTC
*** Bug 743337 has been marked as a duplicate of this bug. ***
Comment 21 Kamil Páral 2015-01-26 11:02:20 UTC
As mentioned in bug 741518, this is the list of programs I see either too small of invisible icons of:

VLC              very small
Transmission     very small
Skype            medium size
Pidgin           very small
Dropbox          invisible
Gajim            invisible
Redshift         very small
GoldenDict       very small

Please see attachment 292700 [details]. GNOME 3.14.
Comment 22 André Klapper 2015-02-04 21:42:51 UTC
*** Bug 729016 has been marked as a duplicate of this bug. ***
Comment 23 André Klapper 2015-02-04 21:42:58 UTC
*** Bug 730288 has been marked as a duplicate of this bug. ***
Comment 24 André Klapper 2015-02-04 21:43:07 UTC
*** Bug 733992 has been marked as a duplicate of this bug. ***
Comment 25 Vasily Khoruzhick 2015-02-12 14:50:42 UTC
*** Bug 744160 has been marked as a duplicate of this bug. ***
Comment 26 Vasily Khoruzhick 2015-02-12 18:26:33 UTC
drago, could you try to reproduce it once again? At least dropbox client is affected, but if you prefer something opensource, there's a Qt5 systray example.
Comment 27 drago01 2015-02-13 20:21:26 UTC
*** Bug 744231 has been marked as a duplicate of this bug. ***
Comment 28 André Klapper 2015-02-22 21:11:45 UTC
drago, could you try to reproduce it once again?
Comment 29 Vasily Khoruzhick 2015-02-23 08:00:57 UTC
Tray icons quite often disappear after a lock screen, after suspend and after connecting or disconnecting an external monitor.
Comment 30 Christoph Reiter (lazka) 2015-02-27 16:43:13 UTC
Probably related: bug 721596 (includes code example)
Comment 31 Florian Müllner 2015-02-27 19:19:03 UTC
(In reply to Christoph Reiter (lazka) from comment #30)
> Probably related: bug 721596 (includes code example)

That's this bug ...
Comment 32 Andrej Antonov 2015-02-27 19:27:08 UTC
> Probably related: bug 721596 (includes code example)

code example -- exists in dublicate of this bug (bug-id of dublicate: 731857 )
Comment 33 Vasily Khoruzhick 2015-02-27 20:25:07 UTC
Well, this bug was here for years, at least since 3.8, see #699306
Comment 34 Christoph Reiter (lazka) 2015-02-27 20:51:08 UTC
(In reply to Florian Müllner from comment #31)
> (In reply to Christoph Reiter (lazka) from comment #30)
> > Probably related: bug 721596 (includes code example)
> 
> That's this bug ...

Copy paste bug, I mean bug 733647

Sorry for the noise.
Comment 35 Florian Müllner 2015-03-03 18:29:38 UTC
I haven't seen this with the new legacy tray from bug 745162, so I may have accidentally fixed this. Could someone check whether the issue is still present on current master?
Comment 36 Vasily Khoruzhick 2015-03-03 18:32:55 UTC
(In reply to Florian Müllner from comment #35)
> I haven't seen this with the new legacy tray from bug 745162, so I may have
> accidentally fixed this. Could someone check whether the issue is still
> present on current master?

Any chance to get backport for 3.14?
Comment 37 Florian Müllner 2015-03-03 18:34:31 UTC
No. This is a major UI change as part of the notification redesign.
Comment 38 Vasily Khoruzhick 2015-03-03 18:37:49 UTC
Ok, then I'll wait for 3.16
Comment 39 Kamil Páral 2015-03-04 08:47:55 UTC
(In reply to Florian Müllner from comment #35)
> I haven't seen this with the new legacy tray from bug 745162, so I may have
> accidentally fixed this. Could someone check whether the issue is still
> present on current master?

Is there an easy way to try it? I tried Fedora Rawhide and I don't see anything new (but I don't know where to look for it, there is no link to the actual mockups in bug 745162). I also tried today's GNOME Continuous, and I don't see any message tray. But it might be caused by the limited number of applications available in there, maybe none of them actually use that tray anymore (Clocks used to in GNOME 3.14).
Comment 40 Florian Müllner 2015-03-04 09:20:52 UTC
(In reply to Kamil Páral from comment #39)
> Is there an easy way to try it? I tried Fedora Rawhide and I don't see
> anything new

It's not in a tarball yet. There's one due, but we are still waiting for a couple of mutter fixes to make it in - still, with a release out later today, it should appear in rawhide tomorrow at the latest.


> I don't see any message tray. But it might be caused by the limited number of
> applications available in there, maybe none of them actually use that tray
> anymore (Clocks used to in GNOME 3.14).

The old message tray does not exist anymore. It used to contain two kinds of items, notifications (which are now located in the calendar drop-down) and legacy status icons (which were dropped temporarily in 3.15.90 and brought back in a small bottom tray in bug 745162).
GNOME applications generally no longer use legacy tray icons but notifications (including Clocks, which never used a legacy icon). Prominent examples of apps that still do are dropbox, sparkleshare and pidgin, and some like xchat and transmission can be configured to use one as well.
Comment 41 Christoph Reiter (lazka) 2015-03-04 16:40:20 UTC
Tested with trunk now: It kinda works, but the size switches 7 times between 24 and 25 px and the bar changes its height with it.. It settles a second after the tray icon is shown.
Comment 42 Matthias Clasen 2015-03-05 01:50:40 UTC
tried with transmission and pidgin, both show up with the expected size now.
Comment 43 Vladimir Didenko 2015-03-06 12:12:00 UTC
(In reply to Matthias Clasen from comment #42)
> tried with transmission and pidgin, both show up with the expected size now.

Issue is still here though now it is better masked. Can you try test case from 

https://bugzilla.gnome.org/show_bug.cgi?id=731857 ?

Open tray (it should stay visible) and run test - there is no icon until tray will be redrawn - e.g. new tray icon added or another tray icon deleted. Icon also appears when you hide and open tray again. May be it is not big deal for gnome users but unfortunately this issue also affects Cinnamon users where you can't hide/open tray so only way to redraw tray is Cinnamon or application restart.
Comment 44 Christoph Reiter (lazka) 2015-03-06 12:20:44 UTC
(In reply to Vladimir Didenko from comment #43)
> (In reply to Matthias Clasen from comment #42)
> > tried with transmission and pidgin, both show up with the expected size now.
> 
> Issue is still here though now it is better masked. Can you try test case
> from 
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=731857 ?

I can reproduce this issue with trunk.
Comment 45 Matthias Clasen 2015-03-06 13:23:14 UTC
lets untangle the issues here. Is this bug about status icon sizes ? if yes, please file a new one about appearing/disappearing status icons. Thats a separate issue.
Comment 46 Vasily Khoruzhick 2015-03-06 13:28:16 UTC
@Matthias, wasn't it closed as a duplicate of this bug?
Comment 47 Vasily Khoruzhick 2015-03-06 13:29:59 UTC
Btw, I don't think that NEEDINFO reflects current status of this bug, since it was already reported that issue is still here.
Comment 48 Florian Müllner 2015-03-06 13:36:25 UTC
(In reply to Vasily Khoruzhick from comment #47)
> Btw, I don't think that NEEDINFO reflects current status of this bug, since
> it was already reported that issue is still here.

Sure, though "happens with real applications in the wild" and "fails with a contrived test case that does stupid things" makes a huge difference on whether this bug should be continue as 3.16 blocker bug.
Comment 49 Matthias Clasen 2015-03-06 14:41:45 UTC
dropping from target, I couldn't find any obvious or severe brokenness here.
Comment 50 Vasily Khoruzhick 2015-03-06 20:55:23 UTC
(In reply to Florian Müllner from comment #48)
> Sure, though "happens with real applications in the wild" and "fails with a
> contrived test case that does stupid things" makes a huge difference on
> whether this bug should be continue as 3.16 blocker bug.

It happens for me with real applications in the wild with 3.14 (dropbox, skype, viber, almost every app with tray icon). And I usually follow this debugging rule: "if you didn't fix it, then it's not fixed". There were not an explicit fix for this bug, so I suppose that 3.16 is still affected.
Comment 51 Florian Müllner 2015-03-06 21:14:17 UTC
Except that a fair part of the implementation has been replaced completely, and testing so far suggests that applications that were affected in 3.14 work much better in 3.16 (most importantly: they are not completely invisible).
If the problem has indeed been reduced to some jitter as suggested in comment #41, then there are simply more important issues to resolve than investing time in perfecting temporary support for a legacy feature.
Comment 52 Kamil Páral 2015-03-10 16:29:49 UTC
Can somebody please share a screenshot that would show me where to find the new systray? I'm probably completely dumb, but I can't find it no matter which app I run - pidgin, transmission, goldendict, etc. I'm using gnome-shell-3.15.91-1.fc22.x86_64.
Comment 53 drago01 2015-03-10 16:32:47 UTC
(In reply to Kamil Páral from comment #52)
> Can somebody please share a screenshot that would show me where to find the
> new systray? I'm probably completely dumb, but I can't find it no matter
> which app I run - pidgin, transmission, goldendict, etc. I'm using
> gnome-shell-3.15.91-1.fc22.x86_64.

Move your cursor into the lower left corner of your primary monitor.
Comment 54 Kamil Páral 2015-03-11 07:51:25 UTC
For anyone with the same problem - the new systray appears only if you have an app with a "legacy" icon running. It is available on your main desktop, *not* in the overview mode. It appears as a few pixels wide gray bar in the lower left corner of your primary screen, you have to click on it with your mouse to expand it. There appears to be no keyboard shortcut to focus it, expand it, nor collapse it.
Comment 55 Allan Day 2015-03-11 10:09:11 UTC
(In reply to Kamil Páral from comment #54)
> For anyone with the same problem - the new systray appears only if you have
> an app with a "legacy" icon running. It is available on your main desktop,
> *not* in the overview mode. It appears as a few pixels wide gray bar in the
> lower left corner of your primary screen, you have to click on it with your
> mouse to expand it. There appears to be no keyboard shortcut to focus it,
> expand it, nor collapse it.

If you want to file a bug about the discoverability of the new system tray implementation, please do so.
Comment 56 Kamil Páral 2015-03-11 12:40:52 UTC
Created attachment 299094 [details]
invisible gajim icon in new legacy tray

(In reply to Allan Day from comment #55)
> If you want to file a bug about the discoverability of the new system tray
> implementation, please do so.

Thanks, I filed bug 746022, bug 746025 and bug 746026.

Regarding this bug, I tested the following applications:
transmission
pidgin
goldendict
gtk-redshift
skype
dropbox
gajim

Except for gajim, I saw no issues.

With gajim, I experienced an invisible tray icon a few times (3 times out of 40-50 runs), see the attached screenshot. I assume it tries to fit the icon size to the tray size, because sometimes it's visible that originally the gajim size was very small and then expanded to the tray size. It seems this approach fails from time to time, a race condition.

I also saw legacy tray size jumping up and down a bit a few times when starting gajim. The tray seemed to increase in height by a few pixels for a split of a second, and then shrank back to the default size again.

I don't know whether it is a problem in the new legacy tray, or in gajim.

gnome-shell-3.15.91-1.fc22.x86_64
Comment 57 Vasily Khoruzhick 2015-03-14 08:31:52 UTC
Viber still has a blank icon in new tray.

gnome-shell-3.15.91
Comment 58 Vasily Khoruzhick 2015-04-23 15:14:00 UTC
Skype and dropbox icon become blank after opening "power off" menu and clicking cancel. kvirc survives somehow.
Comment 59 Vasily Khoruzhick 2015-04-27 10:24:24 UTC
Created attachment 302432 [details]
broken_tray_gnome_3_16.png

Could anyone from devs take a look at this issue? It's too annoying to restart gnome-shell to make tray icons visible again.
Comment 60 Kamil Páral 2015-04-27 11:16:51 UTC
Somebody with the powers, please bump the Version to 3.16. Thanks.
Comment 61 Óscar García Amor 2015-04-27 11:42:46 UTC
If you need an app that fails always you can test with Cutegram [1].

[1] https://github.com/Aseman-Land/Cutegram
Comment 62 Vasily Khoruzhick 2015-04-28 12:11:27 UTC
Could anyone from gnome-shell devs point me to a place in _native_ code where tray icons are handled? I'd like to debug this issue.
Comment 63 drago01 2015-04-28 12:15:48 UTC
(In reply to Vasily Khoruzhick from comment #62)
> Could anyone from gnome-shell devs point me to a place in _native_ code
> where tray icons are handled? I'd like to debug this issue.

https://git.gnome.org/browse/gnome-shell/tree/src/shell-tray-icon.c
https://git.gnome.org/browse/gnome-shell/tree/src/shell-embedded-window.c
https://git.gnome.org/browse/gnome-shell/tree/src/shell-tray-icon.c

and well the damage and paint volume handling in mutter.
Comment 64 Vasily Khoruzhick 2015-04-29 20:30:59 UTC
Looks like it's some mutter bug. After EndSessionDialog is opened, icons disappear even in 3rd party standalone tray (I tried with stalonetray). Any ideas from gnome-shell devs where to dig?
Comment 65 Christian Stadelmann 2015-05-14 20:08:40 UTC
Gnome-shell crashes when clicking on (at least some of these) icons. See this downstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=1221782
Comment 66 Géza Búza 2016-04-13 09:36:48 UTC
I'm experiencing similar issues on Gnome 3.20, but only under Wayland session. 

For example the icon of Skype appears correctly, but the icon of KeePass is just a black rectangle.

There is a problem with clicking the icons. When the cursor pointer is above the icon the click event is not triggered, however if I click on the icon edge (where the image is transparent), then it works as expected.
Comment 67 gnome.vrb 2016-08-10 01:09:05 UTC
Same here on latest debian stable ( Jessie 8.2 ). Refer http://i.imgur.com/fDyrtzf.png
Comment 68 Anass Ahmed 2016-08-26 11:00:35 UTC
(In reply to Géza Búza from comment #66)
> I'm experiencing similar issues on Gnome 3.20, but only under Wayland
> session. 
> 
> For example the icon of Skype appears correctly, but the icon of KeePass is
> just a black rectangle.
> 
> There is a problem with clicking the icons. When the cursor pointer is above
> the icon the click event is not triggered, however if I click on the icon
> edge (where the image is transparent), then it works as expected.

I have the 2nd issue under Wayland with GNOME 3.20 (Fedora 24), I don't know if we need to open another bug for it or not.

When I right click on the icon, I get the menu of the underlying app (Say Firefox), but when I click on the edge of the icon space, I get the correct menu. I can see the hover (mouse-over) effect by moving the cursor upon the icon area until it changes its color so I can click or right click on the icon. It's daunting but I don't have a choice here.
Comment 69 Anass Ahmed 2016-08-26 11:04:16 UTC
Created attachment 334216 [details]
screenshot of right-click on dropbox opens firefox menu

This is an image to clarify the issue of system tray under Wayland with GNOME 3.20 based on my previous comment.
Comment 70 André Klapper 2017-08-12 22:08:10 UTC
Closing this ticket as WONTFIX as the legacy tray (introduced three years ago in 3.16) was meant as a temporary solution to encourage maintainers to move away from the concept of status icons and will not be included anymore in 3.26.

Users can install one of the existing extensions, either based on the still available XEmbed support or implementing the DBus-based StatusNotifier spec.
Comment 71 Christian Stadelmann 2017-08-13 16:47:43 UTC
(In reply to André Klapper from comment #70)
> Closing this ticket as WONTFIX as the legacy tray (introduced three years
> ago in 3.16) was meant as a temporary solution to encourage maintainers to
> move away from the concept of status icons and will not be included anymore
> in 3.26.

Does this mean that no application can show a GtkStatusIcon (or similar from Qt) in gnome-shell 3.26, i.e. the legacy tray goes away without replacement? If yes, is there a public statement? In case those tray icons finally go away, I'll be filing bugs and patching a few applications which still use those tray icons.
Comment 72 Florian Müllner 2017-08-15 13:25:32 UTC
(In reply to Christian Stadelmann from comment #71)
> Does this mean that no application can show a GtkStatusIcon (or similar from
> Qt) in gnome-shell 3.26, i.e. the legacy tray goes away without replacement?

Jein. The support for status icons is still in the underlying code, so extensions (like TopIcons and friends) can easily add them back. But there is indeed no replacement in gnome-shell itself, so status icons won't show up anywhere by default.


> If yes, is there a public statement?

Not yet. Allan is working on a statement, but unfortunately there was very little time between GUADEC (where the decision was made) and the .90 release (that marks the UI freeze), so we had to push out the change before communicating it properly.


> In case those tray icons finally go away, I'll be filing bugs and patching 
> a few applications which still use those tray icons.

Oh, that would be very welcome!
Comment 73 Andreas Kloeckner 2017-08-15 15:33:23 UTC
> But there is indeed no replacement in gnome-shell itself, so status icons won't show up anywhere by default.

Beyond the disruption caused by the abrupt and under-communicated deprecation, what is the suggested UI for long-running, "passive" apps like the owncloud client or redshift?
Comment 74 André Klapper 2017-08-15 17:19:08 UTC
(In reply to Andreas Kloeckner from comment #73)
> Beyond the disruption caused by the abrupt and under-communicated
> deprecation, 

Nah, the *deprecation* of (ab)using the notification area for random application status icons already happened more than two years ago in GNOME 3.16...

Furthermore, we talk about a change in an unstable development version. If you're keen on following changes in unstable versions, see the line in the NEWS file at
ftp://ftp.gnome.org/pub/gnome/sources/gnome-shell/3.25/gnome-shell-3.25.90.news
Regarding upcoming stable releases to include this change, I expect the 3.26 release notes to cover this. Hence I cannot see "under-communication".

> what is the suggested UI for long-running, "passive" apps like
> the owncloud client or redshift?

Move the window to another workspace if you don't like to see windows of running UI applications, or install a 3rd party extension to get a legacy system tray.
Comment 75 Óscar García Amor 2017-08-17 06:39:35 UTC
(In reply to André Klapper from comment #74)

> Move the window to another workspace if you don't like to see windows of
> running UI applications, or install a 3rd party extension to get a legacy
> system tray.

And do you think that this is a good solution?

Why not add an option to HIDE a window and keep it running in dash/dock?
Comment 76 Vasily Khoruzhick 2017-08-17 06:50:35 UTC
I'm actually quite surprised how opinionated (I was going to use the other word here) Gnome devs are. Topicons extension is so popular that it should have become part of Gnome. Your users *want* tray icons. No matter how deep you hide it. So find a way and give it to them.
Comment 77 Anass Ahmed 2017-08-17 07:47:07 UTC
(In reply to Óscar García Amor from comment #75)
> (In reply to André Klapper from comment #74)
> 
> > Move the window to another workspace if you don't like to see windows of
> > running UI applications, or install a 3rd party extension to get a legacy
> > system tray.
> 
> And do you think that this is a good solution?
> 
> Why not add an option to HIDE a window and keep it running in dash/dock?

You can hide the window by using "Super + H" or enabling the minimize button from GNOME Tweak tool. It'll be hidden, and pushed to the end of the App/Window Switcher stack.

The right thing for apps is to use background mode, which is the normal way in Android, iOS, and other OSes. They should send you notifications to pay attention to important things, and you open them only when you need them.
Comment 78 Óscar García Amor 2017-08-17 08:17:22 UTC
(In reply to Anass Ahmed from comment #77)

> You can hide the window by using "Super + H" or enabling the minimize button
> from GNOME Tweak tool. It'll be hidden, and pushed to the end of the
> App/Window Switcher stack.

Yes and No. "Super + H" not hides the app, only minimizes it. If I enter on Activities (top left corner or super key), I can see the application window, and it appears if I use "Alt + Tab".

A hidden app must be hidden, not minimized.
 
> The right thing for apps is to use background mode, which is the normal way
> in Android, iOS, and other OSes. They should send you notifications to pay
> attention to important things, and you open them only when you need them.

How? Keeping an icon on the tray to indicate they are working? ¯\_(ツ)_/¯

Anyway, has no sense that GNOME dev team simply hides the system tray. This remember me to the kids that break a vase and hide their pieces under the carpet hoping that the problem will solve itself.
Comment 79 Anass Ahmed 2017-08-17 11:58:36 UTC
(In reply to Óscar García Amor from comment #78)
> (In reply to Anass Ahmed from comment #77)
> 
> How? Keeping an icon on the tray to indicate they are working? ¯\_(ツ)_/¯
> 
> Anyway, has no sense that GNOME dev team simply hides the system tray. This
> remember me to the kids that break a vase and hide their pieces under the
> carpet hoping that the problem will solve itself.

Does Android/iOS provide a system tray? Is it a needed feature there?
Comment 80 Alexander Nestorov 2017-08-17 12:15:35 UTC
Actually, it does. Both Android and iOS (and Windows and Mac OS) have systrays.
See that little clock icon in the upper right corner of your phone when you turn on the alarm? That is systray. See those little 2 triangles when you turn on bluetooth? That is systray. Same goes for GPS/screen rotation/etc... 

Those are icons sitting at the right top corner of your screen. Those are not notifications. Let me rephrase it. You get visual icons and not notifications for some events that happen in your phone. There are no "minimized" alarm windows nor notifications. Just an icon.

You're missing a huge point here. There are quite some apps that don't have actual UIs, but mere status icons. Let's say for example Dropbox.

Dropbox doesn't have an UI. It doesn't need one. The only thing Dropbox must do is sync files. And it shouldn't have to spam me with notifications each time it manages to sync a file. As long as I see Dropbox's icon in my systray I know it's syncing properly. Why would I want to dismiss tens of Dropbox messages notifying me about every file synced in my shared folders?

What about docker? Or Evernote's helper? Lastpass?

You're clearly ignoring real-world applications. What's even worse, you're trying to convince yourselfs that systray is not necessary when it clearly is.

But, hey, just my 2 cents. I really don't care about Gnome. Or Linux on the desktop. I moved on long time ago, mainly because this sort of stuff. I'm just posting this so you can get some real reasons/feedback.
Comment 81 Carlos Soriano 2017-08-18 16:27:30 UTC
Please wait for the full public statement to understand the background, the decision and the steps to take for the future.

You will have a good opportunity to provide feedback then with a better medium and context, rather than this unrelated bug.
Comment 82 Christian Stadelmann 2017-08-19 12:22:47 UTC
(In reply to Florian Müllner from comment #72)
> (In reply to Christian Stadelmann from comment #71)
> > Does this mean that no application can show a GtkStatusIcon (or similar from
> > Qt) in gnome-shell 3.26, i.e. the legacy tray goes away without replacement?
> 
> Jein. The support for status icons is still in the underlying code, so
> extensions (like TopIcons and friends) can easily add them back. But there
> is indeed no replacement in gnome-shell itself, so status icons won't show
> up anywhere by default.

Will there be some code (e.g. in Gtk+) to detect whether the GtkStatusIcon can be displayed? Maybe one of
gboolean	gtk_status_icon_get_visible ()
gboolean	gtk_status_icon_is_embedded ()
would be suitable, or making gtk_status_icon_new() return NULL, I don't know. Applications need a way to detect the missing tray icon support instead of failing silently.

PS: I guess this is the wrong place to discuss. Where should that discussion go instead?
Comment 83 Jeremy Bicha 2017-08-19 14:17:30 UTC
(In reply to Christian Stadelmann from comment #82)
> Will there be some code (e.g. in Gtk+) to detect whether the GtkStatusIcon
> can be displayed? Maybe one of
> gboolean	gtk_status_icon_get_visible ()
> gboolean	gtk_status_icon_is_embedded ()
> would be suitable, or making gtk_status_icon_new() return NULL, I don't
> know. Applications need a way to detect the missing tray icon support
> instead of failing silently.
> 
> PS: I guess this is the wrong place to discuss. Where should that discussion
> go instead?

https://bugzilla.gnome.org/enter_bug.cgi?product=gtk%2B
Comment 84 Christian Stadelmann 2017-08-19 15:09:33 UTC
(In reply to Jeremy Bicha from comment #83)
> (In reply to Christian Stadelmann from comment #82)
> > Will there be some code (e.g. in Gtk+) to detect whether the GtkStatusIcon
> > can be displayed?
> 
> https://bugzilla.gnome.org/enter_bug.cgi?product=gtk%2B

Thanks, see https://bugzilla.gnome.org/show_bug.cgi?id=786517
Comment 85 Florian Müllner 2017-08-19 22:21:59 UTC
For what it's worth, I've filed a fix for the topIcon extension to adjust to the legacy tray removal. After applying an additional gnome-shell fix in bug 786526, this should allow users to use the extension again without any changes in behavior or functionality.

[0] https://gist.github.com/fmuellner/e1aaec3169990fa7b7bd95da4e0a915a
[1] https://bugzilla.gnome.org/show_bug.cgi?id=786526