On removing APIs - Linux status bar, GNOME system tray and ElementaryOS AppIndicators

On removing APIs - Linux status bar, GNOME system tray and ElementaryOS AppIndicators

Removed GNOME status icons? Where are the ElementaryOS status app indicators? Removing APIs without common alternatives may be a bad idea.

I'd been a Mac user since 2010, but in 2020 I became sufficiently annoyed with Apple's poor software quality and awful MacBook keyboards that I switched to a Linux laptop running Manjaro. There were issues - but the bugs were much less frustrating than on macOS Catalina. Linux is highly customizable so I had an efficient setup with a lot of tweaks to the system, using Sway as a tiling window manager with Swaybar.

Then I tried the M1 MacBook Air. Big Sur was a vast stability improvement over Catalina, but the system performance was the biggest difference. The Browser Bench numbers were unbelievable and the chip's capabilities translated into the real-world just as well, particularly as more apps were compiled to support Apple Silicon.

However, I am much more philosophically aligned with Linux. I dislike where Apple is going with OS level restrictions, privacy invasive device scanning and their contempt for developers.

So, I've spent the last few months distro-hopping on my Linux laptop. I've enjoyed experimenting with window managers and the latest releases of all types of window managers, desktop managers, and distros, even as I use the M1 Air as my daily driver. I'm eagerly following Asahi Linux.

My Manjaro Linux desktop running Sway + Swaybar.

Why is a status bar useful?

Every OS has the concept of a status bar. Whether it's at the top or bottom of the screen, this is a customizable location to show things like open applications, workspaces, menu items, date/time and various other indicators.

I use the status bar as a way to see certain things at a glance. Most status bars also get cluttered up with icons from both the system and applications, often known as the system tray (systray). These icons show the status of a particular item or application but should generally be hidden most of the time.

However, there are different from snippets of information I want to see all the time at a glance, not hidden behind a menu or shortcut:

  • How long until my next meeting and what is it? This shows my next Google Calendar meeting in the status bar. On macOS I use Fantastical (MeetingBar is an alternative) and on Linux I use i3-agenda.
  • What is the current weather? On macOS I use iStat Menus. On Linux, most status bars have built-in temperature (sometimes plus weather). The best GNOME weather extension is OpenWeather.
  • What is the current CPU % usage? On macOS I use iStat Menus. On Linux, most status bars also have this built in. The best GNOME system monitor extension is Simple monitor, but unfortunately it is broken on GNOME 40. Vitals is a good replacement.
  • Battery, network status and date/time are generally built into the system and/or default modules in all Linux status bar apps.

There are better ways to implement what most apps show in the system tray, but this is different from the status bar. Different users have different needs - the whole idea is that the status bar should show useful information, but the definition of "useful" depends on the user. It serves as a general-purpose option where native APIs are either not available or not yet implemented.

The macOS status bar showing my next calendar event (Fantastical), Elgato Control Center, iStats Menus weather and CPU stats, battery status, wifi, macOS Control Center and the date/time.

System tray on GNOME

GNOME is a popular desktop environment for Linux. It focuses on simplicity and is designed to offer a friendly, graphical user experience. Back in 2017, GNOME 3.26 removed the legacy system tray. This followed Ubuntu's decision to remove indicators from the status panel many years before.

The proposed replacement AppIndicator spec set out a number of reasons and analysis about why this was removed. It's clear from the screenshots that the system tray had become a problem - buttons, panels, menus, hybrid panel-menus, inconsistent icon styles, fonts, positions, etc. The idea was to introduce a better API, improve consistency, and separate system indicators - sound, power management, etc - from application indicators - icons and menus related to specific apps.

There is a lengthy story behind the proposal and why it ended up being rejected but ultimately GNOME decided to remove not just the legacy tray but also all status icons, except for those provided by the system. They provided several reasons for this:

  • Most use cases can be covered by specialist APIs, such as notifications or media playback indications.
  • Status icons should only be provided by the system.
  • Users should be in control of their environment, status icons are forced on them, and most people don't care about what most status icons show.
  • Status icon click targets are too small and so provide accessibility issues.

GNOME provides replacement APIs for most use cases, but they accept that some people disagree and that the best way to resolve that conflict is through using an extension:

We do recognise that people are using status icons today and that some will continue to want to use them. That’s absolutely fine, and our decision to stop showing status icons by default is in no way a negative judgement on this. If you want or need to continue using status icons, you should feel free to use the TopIcons GNOME Shell extension. This will continue to work and the extension offers a better status icon experience than the current default anyway.

That extension no longer works, but the replacement AppIndicator Support does, even on GNOME 40. Indeed, it is in the top 10 GNOME extensions.

This is clearly a controversial issue that has been debated for a long time. The arguments made by the GNOME developers all make sense, but there is clear demand for these types of indicators. There are a huge number of GNOME extensions which place various status icons in that status bar, or customize it in some way.

The good thing is that even if you disagree with the approach, you can just use an extension to bring back the functionality you want. That's Linux customizability working at its best.

Top 10 GNOME extensions.

Application indicators in the ElementaryOS status bar

ElementaryOS is one of the Linux distros I find most interesting. It is very far away from what I like about Sway / i3 as tiling window managers, but I find the UX choices to be most comfortable coming from macOS.

The latest release - ElementaryOS 6 - provides a polished experience out of the box - a good default font (Inter), sensible changes to things like the terminal copy/paste shortcuts, custom built core apps like Calendar and Mail, and lots of thought into consistent theming throughout the OS (including one of the best dark-mode implementations on Linux).

However, I find their approach to the status bar frustrating. They have built a status bar called Wingpanel that cannot be customized by the user. They go further than GNOME and state that: "application indicators are an anti-pattern, and not supported in elementary OS." This goes against most other approaches to system design and customizability. One of the project leads has created a website that explains that Linux is not about the systray.

ElementaryOS 6 with the default status bar.

ElementaryOS (and GNOME) both take the view that all use cases are covered by native APIs and that app developers should cater to each platform by implementing them. Unfortunately this is not currently the case.

As a developer, it makes sense to follow their guidance where there is an API - communicating cloud storage status (CloudProviders DBus API), offering quick access to common actions (Desktop Actions), showing background progress (LauncherEntry DBus API), media player status (MPRIS), alerts (Notifications), and portals to provide current location or handle screencasting/recording.

But what if your use case falls outside of these APIs?

There are no APIs for most of the things I want to show - meeting details, weather or CPU stats. On GNOME I can just use an extension, but on ElementaryOS I am forced to compile a custom version of Wingpanel someone has created to add those features back in (weather and system stats). If I want generic application indicators then I need to use a different Wingpanel fork.

ElementaryOS 6 with the status bar replaced with wingpanel-monitor.

It's a hack, and it's frustrating to have to keep this type of custom code up to date as new OS versions are released. The ElementaryOS team also have no intention of implementing this - their position is that the status bar is reserved for system status and is not extensible - so this is not likely to change in the future. This is similar to the position taken by GNOME in relation to system theming, which has been called anti-developer.

Further, it assumes that developers will take the time to implement these native APIs. In an ideal world they would. Then the user experience would be much more integrated and could take advantage of useful platform features like native shortcuts, accessibility, theming, etc.

The statement that "App developers should instead use modern, cross-desktop APIs for platform integration" makes sense assuming there are APIs and developers want to do the work to support them. But what if I want to create an app that shows me the current temperature, or when my next meeting is? There is no API for that.

Developers clearly want a cross-platform solution, and if there is no option then they will just not support that platform. This is a design decision by ElementaryOS, but it is at the major sacrifice of customizability. It comes up in every review I've read of ElementaryOS, which suggests there is real user demand.

Conclusions

Removing features that users expect and use is always difficult. There is always controversy. Some platforms are able to force users to adapt - Apple is infamous for its "courage" when it removes ports or forces technology shifts, but the alternatives are generally feature-compatible. Some underlying API may be removed, but the replacement generally doesn't harm the user experience.

The lessons for developers are clear. Progress often means deprecating and breaking APIs, especially when the replacement introduces a better approach to accessibility, consistency and general user experience. But be very careful about removing something that has no alternative. This hurts developers and users.

However, maybe this is a bad design decision. If users keep opening issues/bug reports, if the most popular extensions bring back the features you removed, if the replacement APIs don't cover common use cases, then maybe it's time to reconsider the approach.

Discover the best tools for developers

Console Newsletter - A free weekly email digest of the best tools and beta releases for developers. Every Thursday. See the latest email.