GNOME Bugzilla – Bug 787079
Set an env var with GNOME Shell version
Last modified: 2017-11-14 20:04:25 UTC
Currently we have some env vars like $XDG_CURRENT_DESKTOP that applications can use for deciding how to behave depending on the desktop. However, we don't expose the version of the desktop. Unity and KDE do, for instance. This is increasinly useful for Flatpaked applications that use tray icons, since GNOME Shell 3.26 won't have support for tray indicators and they need to check how to behave based on that. Current solutions are: - Use DBUS to check GNOME Shell version. However this is overly complex and putting a hole in the sandbox for org.gnome.Shell just for version checking is probably not the best idea - Use gtk_status_icon_is_embedded. However libappindicator doesn't expose this, due to fallbacking to xmebed if possible. libappindicator could fix this, but I don't see this happening and not sure it worth the effort given that what we want is move from that entirely. - Use an env var that passes through the sandbox, similar to $XDG_CURRENT_DESKTOP. Given that adding an env var is a quite simple solution to this problem and that we don't want to pursue more fixes in the concept and technology of tray icons, I would go for this solution to make life easier to those migrating away from all the status icon mess.
(In reply to Carlos Soriano from comment #0) > Currently we have some env vars like $XDG_CURRENT_DESKTOP that applications > can use for deciding how to behave depending on the desktop. However, we > don't expose the version of the desktop. Unity and KDE do, for instance. > > > Current solutions are: > [...] > - Use gtk_status_icon_is_embedded. This is the correct solution to the problem. If libappindicator doesn't expose that information, then that's a shortcoming of the "superior" API. All the desktop version tells applications is whether status icons are *probably* supported. Basing behavior on that information means misbehaving for all users that don't go with the default - that is, remove the panel applet (GNOME 2), install an extension to remove status icon support (pre-3.26) or top-icons and friend to re-add it (post-3.26). So yes, an environment variable is easy to add, but I wouldn't want to endorse it as part of the status icons transition because it is bad practice. Canonical were pushing hard for apps to use libappindicator (and to some extent still are), so I don't think it's too much to ask them to fix that shortcoming(*) with a minimal API addition. (*) and ideally also the reentrancy issue that forces the status-notifier-extension to jump through hoops to keep itself partially enabled on the lock screen - which is a clear violation of the rules and would be a reason for a ban if we took them to the letter.
Appindicator have a dbus API StatusNotifierWatcher, where client need to be register, the client can check if the service exist on his session and with base on this, the client can take a decision (without afect gnome-shell). So, i think gnome-shell will not be affected by libindicator because in gnome shell this service is not available. So, client have a way to detect and take specific decisions for the 3 possible states. - appindicator (checking if the service StatusNotifierWatcher exists) - status tray (using gtk_status_icon_is_embedded) - notifications (in other case). Thats not mean that appindicator is nice and general or that clients will take safe decisions if they are using the appindicator api, just means client can differentiate and take individual decision without need to check the the shell and less the version. https://github.com/ubuntu/gnome-shell-extension-appindicator/blob/master/interfaces-xml/StatusNotifierWatcher.xml
The workaround of keep the extension partially enabled it's because some clients are not watching anything (a client bug). If they are watching for the status of StatusNotifierWatcher to take a decision, when gnome shell will disabled the extension, the extension call to unown_name https://github.com/ubuntu/gnome-shell-extension-appindicator/blob/b8e5545289e4737f6df27a38ad91042ec3ae3450/statusNotifierWatcher.js#L164 to unregistered the StatusNotifierWatcher. This need to cause an alert to the client to take a decision, but just if the client is watching.
(In reply to Lester Carballo from comment #2) > Thats not mean that appindicator is nice and general or that clients will > take safe decisions if they are using the appindicator api, just means > client can differentiate and take individual decision without need to check > the the shell and less the version. Well, sure - if they reimplement the libappindicator bits that listen for a DBus name and the fallback to Xembed status icons, then they can use libappindicator and still do the right thing. But really, that's like saying that the appindicator-extension is pointless, because applications can "just" use the org.gnome.Shell.Eval() method to add a remote menu to the status area ...
What you are saying to me, is like say that a run-time environment for java is poinless, because you can do all that directly without all complication. So, i don't think the app-indicator was create to satisfy something specific of gnome shell or focus on gnome shell. Write specific code in my short vision is not make something general and then make wrong things. I really think the ubuntu people are listen for a DBus name and they fallback to Xembed status icons, but this is what the Qt implementation is not doing and also some applications that are not using properly the API, but most of gtk applications are working ok. The bug is open in Qt, i hope they can resolve that shortly. https://bugreports.qt.io/browse/QTBUG-63065 Anyway, i don't think is wrong involve the ubuntu people in this. Make collaborations and improve all, is really always good.
(In reply to Lester Carballo from comment #5) > What you are saying to me, is like say that a run-time environment for java > is poinless, because you can do all that directly without all complication. No, what I am saying is that libappindicator should expose to applications whether the icon shows up in the environment, and not require apps to reimplement half the library to do the right thing. libappindicator already listens for the bus names and falls back to GtkStatusIcon, so implementing that property should be trivial: - if StatusNotifiers are used (that is, the bus names in question are present), assume TRUE (like it already does without exposing it) - if the fallback GtkStatusIcon is used, mirror its :embedded property > I really think the ubuntu people are listen for a DBus name and they > fallback to Xembed status icons They do, but that's not the point: > gtk applications are working ok. No, and that's the problem - those apps are ok *if* the user installed either the top-icons or the appindicator extension, but not in the default GNOME session. I'm am explicitly *not* asking for GNOME-specific code, but for libappindicator to expose that one bit of information about the system so apps can make sure to not break where there's no status icon/notifier support.
I get your idea now, you will need to report it to qt also, they have a worse implementations, they also need to add support for the change and will be more slowly to implement in Qt. If i can help in something, just tell me. Thanks for your patience and explanations.
Big -1 here. These hard-coded behaviours depending on the desktop environment or (worse) the version of it need to stop. I even think that we should get rid of XDG_CURRENT_DESKTOP completely. I've made a PR for Telegram so that it checks the DBus interface: https://github.com/telegramdesktop/tdesktop/pull/3930 As Florian said this should be moved into libappindicator though, because reimplemented this in every application is stupid. As it isn't really maintained maybe we should point people to https://github.com/jjk-jacky/statusnotifier instead? See https://github.com/pithos/pithos/issues/517 for a discussion about this topic. As for fixing this in Qt: In my experience the following types of people work on Qt: * Qt Company: Doesn't really care about Linux at all * KDE devs: Don't really care about GNOME * Red Hat devs: Don't really care about tray icons So I really doubt this will ever be fixed there (I would love to be proven wrong though).
(In reply to Jan Niklas Hasse from comment #8) > Big -1 here. These hard-coded behaviours depending on the desktop > environment or (worse) the version of it need to stop. I even think that we > should get rid of XDG_CURRENT_DESKTOP completely. > I don't see the problem if this is implemented as nobody will use that of course. It absurd thinking in a shell version for a very specific feature. More if we take on account we are talking about a shell that can be extended very easy like gnome shell. Not just in this specific case this type of cuts will absurd, i think in general. So, will be invisible for most of developers.
(In reply to Lester Carballo from comment #9) > I don't see the problem if this is implemented as nobody will use that of > course. Developers *are* using XDG_CURRENT_DESKTOP, see https://github.com/ubuntu/gnome-shell-extension-appindicator/issues/74 for an example how this can go wrong. Or what do you mean?
Ugh, that github link really shows all the issues the tray icons had :/ Anyway, it's clear this was not the way to go looking at the conversation and Florian's points, so I'll close my request as won't fix.
Jan, yes, of course always there are some developers that just not want to think a little in the repercussion of his decision or don't care what happens in linux or in the particular desktop session that is currently not used by him. But see, you can get the gnome version over Dbus if you want right now. So, my point is that: This will not make any difference for indicators. Who want to support the indicators propertly will find the way and who don't want or not care about it, also will find the way to not support it. This is then in my opinion a not transcendental issue for indicators. But it's transcendental for the Gnome Vanilla as actually they need a good way to fallbacking as Gnome is in the end of the chain of all fallbackings. So, what it's proposed here, it's not the solution of Gnome and also is not an imposition to who want to support the indicators. I don't see the problem then as this is a decision of a developer if he/she wants or not to support indicators. You can not force him's really or also you can not hide all ways that developers have to decide not use indicators. Finally if is indicators what matter, this is a torment in a glass of watter in my opinion. And Gnome also need a better fix for that anyway...