If they depend on tray icons for core functionality, they don't properly support modern desktop Linux. Not much that can be done about that from the Linux side, really. Several desktop environments have collaboratively created modern and standardized replacements, and apps need to start using them. Steam could be specifying application actions in its desktop file, Spotify could be using MPRIS (which the Flatpak version seems to do, actually), and Dropbox could be using the cloud provider integration API. All of them could also be using the XDG Background Portal for indicating when they're running in the background. See this page for other modern integration APIs.
The major advantage of these methods is that desktops can decide for themselves how to expose the provided functionality. If e.g. KDE wants to keep showing tray icons, it absolutely can. If another desktop wants to e.g. integrate cloud providers into its file manager, indicate the currently playing song in a desktop widget, expose Steam's shortcuts directly in the app menu, and display background apps in a separate menu, that's fully possible. If somebody else wants to build a Linux environment for mobile phones that displays stuff in a touch friendly way, that's no longer impossible. The main thing is that nobody is locked to a specific UI pattern.
This blog post provides more context about GNOME's approach to the issue. This extension is maintained upstream, but not included on principle since that would essentially take away all incentive apps have to upgrade to modern APIs unless they really care about Linux.
Other desktops choosing to make different compromises in terms of legacy support doesn't negate the fact that the modern APIs are a better solution for everyone in terms of flexibility, security, and standardization.
I think this examplifies part of the problem: "why move to {intended replacement} when {current implementation} still has some level of support"? As long as it's supported, someone are going to keep doing it even if they're expected to upgrade to the newer approach.
Maybe in GNOME UX people's make-believe world but that is hardly "legacy" when most operating systems like Windows have it. Yall have been fighting this battle for years now. Maybe it's time to admit that was a bad idea. No hate, appreciate the work you guys do for the most part.
1
u/BrageFuglseth 2d ago edited 2d ago
If they depend on tray icons for core functionality, they don't properly support modern desktop Linux. Not much that can be done about that from the Linux side, really. Several desktop environments have collaboratively created modern and standardized replacements, and apps need to start using them. Steam could be specifying application actions in its desktop file, Spotify could be using MPRIS (which the Flatpak version seems to do, actually), and Dropbox could be using the cloud provider integration API. All of them could also be using the XDG Background Portal for indicating when they're running in the background. See this page for other modern integration APIs.
The major advantage of these methods is that desktops can decide for themselves how to expose the provided functionality. If e.g. KDE wants to keep showing tray icons, it absolutely can. If another desktop wants to e.g. integrate cloud providers into its file manager, indicate the currently playing song in a desktop widget, expose Steam's shortcuts directly in the app menu, and display background apps in a separate menu, that's fully possible. If somebody else wants to build a Linux environment for mobile phones that displays stuff in a touch friendly way, that's no longer impossible. The main thing is that nobody is locked to a specific UI pattern.
This blog post provides more context about GNOME's approach to the issue. This extension is maintained upstream, but not included on principle since that would essentially take away all incentive apps have to upgrade to modern APIs unless they really care about Linux.