Indicator Ayatana doesn't work

[Djaler]

In Juno there no third-party indicators in tray, even after install wingpanel-indicator-ayatana.

[r3k4]

is there any update for this issue ?

[cassidyjames]

This is intentional. Application indicators have been deprecated for years. They have also been removed from GNOME in favor of better APIs. They were deprecated and not officially supported for two years in Loki, and have been fully removed for Juno.

There's some pretty good rationale on the GNOME design blog: https://blogs.gnome.org/aday/2017/08/31/status-icons-and-gnome/

[Djaler]

@cassidyjames what is the new cross-DE API?

[cassidyjames]

@Djaler there isn't one for a concept of "status icons." Instead, there are several more tailored APIs that can be used depending on the needs of the app:

Gtk.Application for background processes. This is how apps in elementary OS continue operating in the background, i.e. Tootle checks for new posts, Mail notifies you of incoming email, Music continues playing in the background, etc.

FreeDesktop.org Desktop Actions for providing static quick actions, i.e. launching a specific part of an app from its icon in the Dock or Applications Menu.

LibUnity for dynamic quick actions, Dock progress bars, and badges in the Dock and Applications Menu. This is supported at least in elementary OS, Ubuntu Unity, Ubuntu 18.04+, and GNOME with Dash to Dock. I'm not sure about other DE support, but I imagine it is supported in KDE either out of the box or with an option. On elementary OS, even backgrounded apps that utilize these APIs will show up alongside other apps in the Dock.

Notifications for alerting people. Supported prety much everywhere.

LibCloudProviders for cloud providers like Dropbox, Google Drive, Nextcloud, etc. This is supported at least in Ubuntu and GNOME, and there's a bountied open issue for support in elementary OS.

MPRIS for audio applications to integrate with the system sound indicator. Supported in elementary OS, Ubuntu, GNOME, and several other DEs.

EDS for integration with the calendar indicator. Supported at least on elementary OS, Ubuntu, GNOME.

KeepBelow and Stick for always-visible desktop applets. Supported on elementary OS, Ubuntu, GNOME, and everywhere else as far as I know.

[WebShapedBiz]

@cassidyjames Thank you for this detailed overview but there is no mention here how the user will interact with apps like Skype (and many different Electron apps) in Juno. These are the apps that literally everyone is using in their daily workflows and it's hard for me to believe that there will be no way of using them in the future. Can you please shed some light on how will an average Elementary user use those apps in Juno?

Cheers.

[cassidyjames]

@WebShapedBiz third-party cross-platform apps have to do a minimal amount of work to actually support the platforms they ship on. If they don't support GNOME and elementary OS (which use many of the same APIs and share this limitation), then I'm not sure they're intended by their developers to be used on elementary OS or GNOME. We can't really solve that as a platform.

Users should reach out the the app developers and ask them to actually support the platform. It's not the platform's responsibility to cater to apps that explicitly don't support the platform.

[WebShapedBiz]

Thank you @cassidyjames for your quick reply. As I understand there is available a GNOME extension Quicklists so they are covered. I'm very saddened having to choose between my apps (Dropbox/Mega/pCloud, Wavebox email client, my screen recorder, internet radio app and many more) and Elementary OS which I'm exclusively using and supporting from Jupiter release. Sending emails to all those companies I see more as a bad joke than a serious suggestion. Cheers.

[kotatsuyaki]

I'm a little confused by this decision. I've long been using Elementary OS Loki for daily tasks, and the indicators is a great deal to me. eOS doesn't have built-in support for inputting east-asian languages such as Chinese and Japanese, so I always use fcitx or ibus packages to do that. Currently it's handy (after messing around with obscure settings, which is what I have to do after every clean install of eOS) to have the input method status displayed as an indicator and have a accessible drop-down menu there when something went wrong with it. I've tried Juno and found that we don't have that anymore. In fcitx, I can, for sure, de-select the Use System Tray Icon but that results in an ugly box floating around the screen blocking other windows. It felt like going back 15 years. Beside that I have chatting programs, dropbox, screen recorders, which all depend on the indicator and suddenly become useless. My question is, how do I solve this, especially the input method menu? I don't want to type fcitx-config-gtk3 every time to access the settings. It used to be handy with the old but working indicators.

EDIT: typo

[cassidyjames]

[elementary OS] doesn't have built-in support for inputting east-asian languages such as Chinese and Japanese, so I always use fcitx or ibus packages to do that… In fcitx, I can, for sure, de-select the Use System Tray Icon but that results in an ugly box floating around the screen blocking other windows. It felt like going back 15 years.

@AkitakiKou Considering that GNOME also does not have a "System Tray," it also sounds like fcitx should be updated to support modern desktops. Ideally there would be an input method WingPanel indicator, using the WingPanel APIs. Then we could intelligently install/enable this when the user is using a CJK language, offer relevant settings in the System Settings, etc. Unfortunately nobody has stepped forward and done that work yet, though.

Beside that I have chatting programs, dropbox, screen recorders, which all depend on the indicator and suddenly become useless.

This has all been covered extensively in this issue and elsewhere, so there's not much more I can say on it without beating a dead horse.

All of this still doesn't change that the system tray concept is deprecated, has been for years, and if we want to see any progress on this front we must remove it in this release. We've been doing this song and dance for several years over multiple releases, and it's obvious that just "ship it for one more release" is not a productive outcome and is the primary thing that has held back the adoption of newer, better APIs.

[matfantinel]

I want to share my opinion on this one.

First of all, I understand your will to encourage the use of newer and better APIs. As a developer myself, I'd love if all users could just use the best platforms/software/hardware too. However, there are situations where I don't think we have the power to really change anything market-wise.

Linux recently has seen a big rise on the amount of available software, mostly because of multi-platform development tools like Electron, or even back-end tech like .Net Core. We all know that Linux is not a very profitable platform for a lot of services, since the user base is relatively small compared to other platforms. The possibility of releasing apps with minimal effort was a big reason a lot of companies started supporting Linux, otherwise they wouldn't release anything at all.

This kind of move makes it harder for all software to work properly on the system. A bunch of people asking the company on Twitter for better support rarely makes a difference. So, in the end, elementaryOS's users - which I believe is who the OS is built for - are caught in this change, and end up being harmed by it.

More technical users like us can understand why and agree/disagree with it, and even fix it ourselves if we really want to. However, users in general SHOULD NOT have to care or even know about the technologies involved and if/why they are deprecated or not. What's gonna happen is that someone who was happy using Loki will upgrade to Juno for new features/whatever, and end up with some things not working properly or not working the way they are expected to. Juno gives us some nice improvements, however, for people who heavily use any applicaton that relies on the indicators, the final experience might actually be WORSE than the previous version. That's not good at all.

An user should not be caught in the middle of a migration. Its experience should not be affected at all.

I personally do not use any app with an indicator besides Telegram, and am not much affected by this change. The thoughts behind this, however, are concerning to me. I can no longer expect a future version of eOS to be a better version of what I currently have, because maybe my apps simply won't work anymore. Then, my options would be to stay with outdated software, find out a tricky way to make them work, or change distros altogether.

Although this may sound a bit harsh, I love you guys' work, and love using eOS too. I mean this a constructive criticism.

Edit: I probably got a bit carried away with the Electron part and it may not be very relevant to indicators directly

[cassidyjames]

@matfantinel "users in general" (and not "more technical users like us" as you put it) are already given a clear path to installing software that is built for the OS: AppCenter. The curated apps there are reviewed to ensure they are built with a modern toolkit, using proper APIs, not doing bad things with user data, etc. Out of the box, downloading and installing some "Electron app for Linux" is already far above and beyond the expectations of elementary OS, and not something we make an effort to encourage in the first place. For example, Electron apps aren't accepted to AppCenter, and installing randomly-downloaded apps isn't supported out of the box.

I think you have to fundamentally understand that elementary OS does not exist as some "general purpose Linux desktop distro." Some concept of "Generic Desktop Linux" doesn't exist—and honestly has never existed. There has always been the Ubuntus and GNOMEs and KDEs of the world. While there may be some cross-compatibility between them, elementary OS is not aiming and has never aimed to be yet-another-generic-desktop. We have a set of strict human interface guidelines. We have a required toolkit. We have a recommended language. We have recommended conventions. We have supported (and explicitly unsupported) APIs.

This is hard for a lot of "Linux users" to hear, and I get it. It goes against the norm. But elementary OS wouldn't be here if we didn't do and continue to do what we feel is best for the platform itself.

Honestly, no new information or arguments have been presented and we seem to be going in circles around a fundamental disagreement about how elementary OS as a platform should operate. If there are specific issues around things such as CJK input, please always feel free to open them on the OS repo and we can triage them as needed.

[kotatsuyaki]

Thanks for the detailed reply on this topic, and I’ve just opened an issue there.

For those who needs 3rd-party indicators on Juno, take a look at this guide.

[beeblebrox3]

"Users in general" (and not "more technical users like us" as you put it) are already given a clear path to installing software that is built for the OS: AppCenter.

For example, Electron apps aren't accepted to AppCenter, and installing randomly-downloaded apps isn't supported out of the box.

Elementary team really expects that users just use apps from AppCenter and nothing more? Today I don't see this working (reminds me of Windows Phone, an OS that I relly like but...). This particular change is really frustrating for me and can't recommend it anymore for user that just want things working. My hope is that we can revert this decision or at least continue on the same state as freya when the final version comes out.

[skewty]

@cassidyjames what cloud storage sync solution are Elementary users expected to use? I don't know any that don't use a tray icon to show synch state and offer quick and easy interaction with the app. https://github.com/elementary/files/issues/172#issuecomment-421766197 https://github.com/owncloud/client/issues/6607

The NextCloud project, to the best of my knowledge, to implement into linux in a "modern" way was never completed. Google doesn't have a client for Linux. That leave DropBox (which uses a tray icon). Does anyone in linux use Sky drive?

Also, you mention that Gnome removed the tray. While true, few users run a vanilla Gnome desktop. The popular Ubuntu spins still have a tray. There's the large majority of the desktop market.

Sadly, I agree with you that distributions need to not include it to force developers to actually write new code and do better. That said, since they now have until April 2020 before Ubuntu ships its next LTS, few care to "fix" what isn't broken. I don't think Elementary has enough "pull" to do it alone. (The Fedora market share isn't big enough to tip the scales as a joint coalition of sorts.)

[SleepingPanda]

I'm sorry but you simply do not have the market share to dictate the whims of large software companies like Spotify and such to make changes at your behest. Sad, I used to be a die-hard elementary user (even donated a few times) but now I'll look elsewhere.

[skewty]

https://github.com/elementary/files/issues/172#issuecomment-422860803 If this is finished, that solves the issue for NextCloud users. But what about all the other apps that only work properly via tray icon?

@cassidyjames can the elementary team perhaps create a pseudo project so we can use the issue tracker to track progress with various popular apps (link to the issue / bug that reports the need for a more modern approach). This will very much be an Elementary issue because all the other big players will have a tray.

[jlnr]

@SleepingPanda Spotify is an odd example. It doesn't have a status bar item on macOS, and it works fine with the built-in audio indicator on elementary OS. Maybe it has a tray icon on Windows, but Windows is aggressively hiding third-party tray icons too.

For some apps with a dock icon, a context menu in the dock could be a good alternative to an indicator icon. Media players, and even instant messengers on macOS (Skype, Adium) use dock menus that work like traditional status bar items. It's not bad.

Electron supports dock menus, but only on macOS: https://electronjs.org/docs/tutorial/macos-dock

Would it be possible to send a patch to Electron to make this API work with elementary OS (maybe with Ubuntu's dock too)? I don't know much about Plank, but that way elementary could piggy-back onto the market share of macOS.

[drequivalent]

Poppycock. @SleepingPanda is right. Elementary is great and all, but it's not big enough yet to successfully make decisions such as this one.

You're not Apple getting rid of headphone jack and getting away with murder.

I'd be happy to use only Elementary apps for my work, I really would. But right now, Elementary's "curated apps" do not nearly meet users' demand in software.

When I surf the web, it's Firefox (sorry, Epiphany don't cut it). When I write documents, it's Libreoffice. Talking is done via Pidgin (now trying to use Dino as it's more modern), Tox, Ring, Riot (was going to switch to Fractal), Telegram (for job stuff). Syncing is done via Nextcloud. Gaming - Steam, of course.

Most of those programs use App Indicators. And in most cases, an indicator is the only damn control you have over an application. Yes, close all its windows, and it's running in the background without any way to bring it up again other than killing it from the console and starting it again - and even then there's no guarantee that it will show its window.

What the hell? For the environment with such minimal controls, having lost one of them is basically a catastrophe. It renders the system nigh unusable. I repeat, the system loses usability - the thing you said you value.

Now, I can see some brave soul writing an XMPP client and a Ring client and a Tox client and even Nextcloud client specifically for Elementary in some far future.

But I don't see Telegram and Steam doing it!

[SleepingPanda]

@jlnr Sure it may be an odd example to you as a developer but to us end-users it's not; It's just an app like any other to me and the thousands of others who use it. You say Windows is aggressively hiding indicators but the truth is they still support them and so does macOS and Ubuntu. If they're annoying to you think of an elegant way to hide them or just use apps that don't use them.

Why force your will on everyone else? I don't see end-users complaining about indicators existing but instead see complaints and questions about it's removal like this one in almost every discussion about the elementary project.

Would a simple button like "Enable Third-Party Status Indicators" in the settings panel be so hard to do?

[skewty]

I know I am a nobody, but as a professional software developer who is interested in getting involved in open source development (and financially) and who really liked many of the design principles of Elementary (I was running Juno), I decided to invest my time elsewhere. It was the no indicators in Juno decision that ultimately lead me to my decision. I formatted and installed Ubuntu 18.04.

If nothing else, they recognised that the linux app ecosystem is not yet ready for the removal of the system tray. Additionally, they recognised that the users were not ready for the removal of icons on the desktop. While I may not agree with all their decisions, at least they put the needs of the masses ahead of their own. Lets be real, a developer who is developing for Elementary OS is not a regular user and will likely have different needs and desires. As a typical user, the tray is essential as most of the top 10% apps still require it or the usability fails.

[drequivalent]

@skewty Icons on the desktop is actually kinda a taste preference more than anything. And there's an app for Elementary that lets you have just that, it's called "Desktop Folder". Still, it's not a REQUIREMENT for an app to have its icon on your desktop or anything. Tray icons, on the other hand, is another story entirely. And no, @jlnr, "aggressively hiding" them is not the same as "not having functionality to support them at all"

[jlnr]

@SleepingPanda The MPRIS indicator in elementary works fine with Spotify. Speaking as a user, having a second indicator with the same contents would be an anti-feature. There are strong reasons to keep/fix indicator support, but I don't think Spotify in particular is a convincing example.

I've brought up the idea of dock context menus because that could be a future migration path. This will not happen overnight, so please don't understand my comment as me taking a side against indicator support in Juno. (I agree that it seems too early for that.)

[donadigo]

If we aren't going to ship Ayatana indicator support then we should have a replacement solution to it now, not as a migration path. Otherwise, we should keep it, because some apps are unusable without them and at that point it doesn't matter if they're native or not. Speaking as a user, it's better to have a working support that sometimes can get buggy than not having it at all without any good replacement. We have to realise that we're not a "major" OS and we just can't dictate what API's make sense.

[drequivalent]

What @donadigo said. Also, for a new platform, losing touch with popular third-party apps in the ecosystem you in fact depend on and claiming "it's our platform, we'll do it all ourselves" is almost a surefire way into the dumpster. As Ubuntu Touch and Mir will attest.

[cassidyjames]

If we aren't going to ship Ayatana indicator support then we should have a replacement solution to it now, not as a migration path. Otherwise, we should keep it, because some apps are unusable without them and at that point it doesn't matter if they're native or not.

We have several APIs that are available as a replacement. See https://github.com/elementary/wingpanel/issues/96#issuecomment-401412541. The only one that isn't implemented yet (but has work in progress and a bounty attached) is the CloudProviders API. But cloud syncing apps like MEGA can and do work without a system tray, as their developers can detect the presence of a system tray and/or open their preferences dialog when the .desktop is opened. And syncing in the background does not require a tray icon. Crappy cross-platform apps that don't do feature detection or adapt to their platform are not something we should be catering to or going out of our way (and directly against the platform design) to cater to and fix for those developers.

We have to realise that we're not a "major" OS and we just can't dictate what API's make sense.

First, these apps will be equally broken on Fedora, openSUSE, Pop!_OS, and any stock GNOME distribution. Second, dictating what APIs make sense is exactly what we do. That's why we have AppCenter. That's how we can actually enforce some amount of protection of peoples' privacy. That's how we can ensure apps are working well and users have a good experience. And we're not in any way alone in this dictation, as the entire concept and related APIs have been deprecated for years.

I am locking this issue as it has gone in circles for months without any new information being shared.

[donadigo]

AppCenter was and is a completely new API that we introduced and it's absolutely great. It provides apps that actually make use of the "right" API's and are designed to work with the OS. I'm all for apps using those API's, but it's just not possible right now.

The reality is that apps that use Ayatana still exist and people use them, either we design for API's or for users. As I've said, "broken" is generalizing because not all indicators are broken. It's not about what's right and what's wrong, it's more about the reality that we are in. Dropping support for API is viable when nobody or small percentage of users make use of it, not when it's "deprecated" or "replaced".

[jeremypw]

Maybe a elementary indicator using the new Cloud Providers API will be possible? A plugin for this API is currently being worked on in Files (see https://github.com/elementary/files/tree/plugin-cloudproviders)