This is Part 2 of a series on what’s wrong with the free desktop app ecosystem and how we can fix it, based on the talk Jordan Petridis and I gave at LAS 2019 in Barcelona.
In Part 1 we looked at all the different elements making up a platform, and found that there is only one “complete” platform in the free software desktop world at the moment. This is because desktops control the developer platforms, while packaging and system integration is managed by separate communities, the distributions, for historical reasons. This additional layer of middlemen is a key reason why we don’t have real platforms.
Power to the Makers
The problems outlined in Part 1 are of course not new, and people have been working on solutions to them for a long time. Some of these solutions have really started to come together over the last few years, empowering the people making the software to distribute it directly to the people using it.
Thanks to the work of many amazing people in our community you can now develop an app in GNOME Builder, submit it to Flathub, get it reviewed, and have it available for people to install right away. Once it’s on there you can also update it on a schedule you control. No more waiting 6 months for the next distribution release!
But though this is all very awesome, Flatpak is unfortunately not a complete solution to the platform conundrum discussed earlier in this series.
Flatpak is Not Enough
Flatpak does solve a number of the issues around app distribution very elegantly, because app developers do their own packaging, and control their release schedule. It’s also a unified package format that works across different host systems, and the Flatpak runtimes are clearly defined development targets to do QA against.
But that doesn’t magically fix all our problems. The two elephants in the room are
- The Host still matters: Flatpak only solves part of the issues with distro packaged apps
- Downstream drama: Flatpak does not address the conflicts between desktops and distributions
1. The Host Still Matters
Even with Flatpak there are still some unpredictable variables on the host system which affect app developers. On the technical side a number of things can go wrong, from an outdated Flatpak version (which can mean some Portals apps rely on may be missing), to missing/incompatible system APIs such as password storage, calendar, or address book.
These things can lead to applications not working properly, or at all. For example, this is why new versions of GNOME Contacts cannot access any contacts on Debian 10, why recent GNOME Calendar cannot access any calendars on Ubuntu 18.04, or why Fractal doesn’t remember your password across restarts on some non-GNOME environments.
There are also user-facing integration points where applications interface with the system. These include things like notifications, the application menu, search providers, the old systray, and the design patterns used in individual apps.
For example, when the system UI or design guidelines change, applications follow the platform and change their UI accordingly. This means if you install newer apps on an older system, there are going to be weird edge cases. For example, if you install new apps on Debian 10 you get a confusing mix of the old and new application menu paradigms because the design guidelines were changed with GNOME 3.32 (early 2019).
Flatpak also applies the host GTK stylesheet and icon set to apps. This means that if the host distribution overrides the system stylesheet, Flatpak will happily apply random, never-tested CSS to every app. Obviously this leads to lots of issues, ranging from ugly but relatively harmless glitches to real usability issues, such as illegible text on buttons. For more background on this particular issue, see this blog post.
Some of these issues could be fixed with more standardization, changes to Flatpak, or new portals. However, fundamentally, in order to be a real platform you need a clearly defined environment to develop and test for. Flatpak alone is not enough to achieve that.
Just like “write once, run everywhere” is always an illusion, it’s never going to be possible to completely split apps from the OS. You always need app developers to do some extra work to support different environments, and currently every distribution represents yet another extra environment to support.
2. Downstream Drama
Flatpak does not completely solve the issues app developers face in shipping their software, because these can not be isolated from the ones desktop developers face. In order to fix the app developer story we need real platforms. In order to get those we need to resolve the desktop/distribution dilemma.
The issues here roughly match the ones with traditional distribution packaging mentioned in Part 1, and can be grouped into three broad categories:
- Structural issues inherent to having distributions and desktops be separate projects.
- Fragmentation issues because we have multiple of everything so there’s duplication and/or bad abstraction layers.
- Configuration issues, primarily around settings and other defaults, which have to be set at the distribution level but affect the user experience.
Structural Issues
One of the biggest structural issues is distribution release schedules not being aligned with the upstream one (or between different distributions). GNOME releases every 6 months, but distributions can take anywhere from a few weeks to several years to ship these releases.
This category also includes distributions overriding upstream decisions around system UX, as well as theming/branding issues, due to problematic downstream incentives. This means there is no clear platform visual identity developers can target.
For example, Ubuntu 18.04 (the current LTS) ships with GNOME 3.28 (from March 2018), includes significant changes to system UX and APIs (e.g. Unity-style dock, desktop icons, systray extension), and ships a branded stylesheet that breaks even in core applications.
Fragmentation Issues
Having multiple implementations of everything means we either need do tons of duplicate work, or try to abstract over the different implementations.
On one end of the spectrum there are OS installers: There is no GNOME installer, so every distribution builds their own. Unfortunately, most of these installers are not very good, and don’t integrate well with the rest of the desktop experience (e.g. they use different design patterns than the OS itself). This can be either due to a lack of resources (e.g. not every downstream has their own GNOME designers), or because different distributions have specific downstream goals and motivations (e.g. Fedora and RHEL share an installer, which introduces lots of complexity).
In other areas we have the opposite problem, because we’re trying to abstract over the fragmentation with a single component. For example, PackageKit is meant to abstract over different package formats, but in practice it only works for a handful of them, and even for those it’s often buggy. The PackageKit maintainers have officially given up on this approach.
Configuration Issues
This includes the default apps, the fonts shipped with the system by default, the terminal shell and prompt, and the UX around things like Plymouth. All of these things are usually configured at the distribution level and are therefore often not great, because these choices need to be made in concert with the rest of the platform UX.
Forging Platforms
Given the constraint of there being multiple different desktops projects and technology stacks (and the host still mattering), we’ll never have a single “Linux” or “FreeDesktop” platform. We could have one platform per desktop though.
From an app developer point of view, testing for GNOME, KDE, and elementary isn’t as nice as testing only for a single platform, but it’s not impossible. However, testing for Debian, Fedora, multiple Ubuntu releases, OpenSUSE, Arch, Endless, and dozens more is not and never will be feasible, even with Flatpak. Multiple different distributions, even ones that ship the same desktop environment, don’t add up to a platform. But exactly that is what we need, one way or another.
The question is, how do we get there?
The Nuclear Option
When we look at it from a Flatpak context, the solution seems obvious. Flatpak is solving the middleman problem for app developers by circumventing the distributions and providing a direct channel between developers and end users. What if we could do the same thing for the OS itself?
Of course the situation isn’t exactly the same, so what would that mean in practice?
With Flatpak runtimes there is no extra “distribution” abstraction layer. There are no Debian or Fedora runtimes, just GNOME and KDE, because those are the technology stacks app developers target.
These runtimes are already more or less full-fledged distributions which are controlled by the desktops, we’re just not using them as such. The Freedesktop SDK (which most runtimes are based on) is not based in any distro, but built directly from upstream sources using Buildstream as the build tool, and it already has most of the things you need to make a basic operating system.
There is an early-stage effort to make bootable nightly GNOME OS images for development/testing, built on top of the Freedesktop SDK. From there it wouldn’t be a huge leap to actually make an independent, consumer-facing platform OS for GNOME (and KDE, and other platforms).
However, though this is likely to become a very attractive solution in the future, there are a number of hurdles to be overcome:
- An OS needs an installer, OS updates, a Plymouth theme, etc. All of these are being worked on for the nightly GNOME OS images, but are not quite there yet.
- A “real” OS needs a dedicated group of people doing things like release management, security tracking, and QA. These are being done to some degree for the Flatpak runtimes, but a consumer OS would need more manpower.
- It’s an OSTree-based immutable system, which means there is no traditional package management. Apps are installed via Flatpak, and server/developer workflows need to happen in containers. Though projects like Silverblue’s toolbox have come a long way over the past few years, there’s still work to be done before immutable OSes can painlessly replace systems with old-school package managers for all use cases.
It takes time to start a new operating system from scratch, especially when it’s using cutting-edge technology. So while things like GNOME OS could be amazing in the longer-term future, it’s likely going to take a few more years before this becomes a viable alternative.
Squaring the Circle
What could we do within the constraints of the technology, ecosystem, and communities we have today, then? If we can’t go around distributions with a platform OS, the only alternative is to meld the distributions into a meta platform OS.
Technically there’s nothing stopping a group of separate distributions from acting more or less like a unified platform OS together. It would require extraordinary discipline and compromise on all sides (admittedly not things our communities are usually known for), but given how important it is that we fix this problem, it’s at least worth thinking about.
To get an idea what this could look like in practice, let’s think through some of the specific issues mentioned earlier:
Release Schedule: This is probably among the thorniest issues since release cycles vary wildly in length and structure, and changing them is very difficult. It’s not unimaginable that at least some progress could be made here though. For example, GNOME could have long term support releases every 2-3 years for “stable” distributions like RHEL and Ubuntu LTS. Distributions could then agree to either be on the regular 6 month schedule, or the 2 year “LTS” schedule. Alternatively, all distributions could find a single compromise schedule that can work for everyone (e.g. maybe one release per year, like mobile operating systems do).
Theming/Branding: Some distributions want ways to customize the OS experience such that their system looks recognizably different from others. This is not necessarily a problem, as long as this is done using APIs that are supported and intended to be used in this way (which unfortunately is currently not happening in many cases).
Creating more branding opportunities which do not break APIs which apps rely upon (especially third party apps shipped via Flatpak), is certainly possible and there have been discussions in this direction (e.g. GTK accent colors). Whether distributions would limit themselves to these APIs once they exist is of course an open question, but at least there is a ongoing dialog about this.
System UX/API Changes: Some distributions make significant changes to the core system, which fragments the visual identity of the platform at best, and severely damages the app ecosystem at worst. This includes things like adding a permanent dock, icons on the desktop, re-enabling the systray, or a “dark mode” setting which just changes the system stylesheet from under apps.
The solution here is simple in theory: If you think a change to the system UX is needed to fix a specific problem, don’t just patch it downstream, but instead help to address the actual underlying issue (We already touched on this in Part 1). For example, if you find that new users are confused by the empty desktop at startup, don’t just ship an extension that completely breaks the structure of the shell. Bring the problem to the upstream designers and developers, figure out a solution together, and help implement it upstream.
In practice it’s not always that easy, but a lot can be done by simply adopting an upstream-first UX mindset. It can take a while to get used to, especially for companies with more, uh, “traditional” internal processes, but it’s definitely possible seeing as it’s working well for Red Hat and Purism, for example.
OS Installer: It may not be doable to have a single code base, but we could definitely share at least the design (and possibly some UI code) for the installers used across distributions. A cross-distribution initiative for nice, native GNOME installers across the major distributions would probably not be easy logistically, but is not unimaginable.
Software Installation & Updates: GNOME Software and PackageKit’s “abstract across distros” strategy has clearly failed, and we need a new approach here. For applications there is a relatively easy solution: Distributions stop packaging apps, and work together on a common repository of developer-submitted Flatpaks (e.g. something like Flathub). We’d need to work out how this common solution can accommodate various distribution policies around e.g. proprietary software, but this seems very doable and most of it already exists in Flathub.
The resources currently going into repackaging every app for every distribution could be pooled to review the apps submitted by developers to the common Flatpak repository.
Seeing as most distributions are not (yet) image-based like e.g. Silverblue or Endless, we would still also need a way to update the packages that make up the core system. For this there’s probably no way around backend duplication.
System Default Configuration: Making progress in this area is likely not too difficult comparatively. The main thing we’d need is better coordination between the various parties needed to synchronize these things better (which is of course easier said than done). Having some kind of common forum where the upstream design and release team, as well as people in charge of major distributions can discuss and standardize defaults across the entire ecosystem might work for that.
The Bottom Line
If we want a future with real platforms we can either go around the distributions or have them all work together (or potentially both), but one way or another we need to vertically integrate.
Neither path is straightforward or easy, and there’s a huge amount of work ahead either way. However, the first and most important step is acknowledging that this problem exists, and that we need to radically change our approach if we’re serious about building attractive app ecosystems.
The good news is that many people across different projects are already working towards enabling this future. We hope that you’ll join us.
Happy hacking :)
Hi! I’ve read your article and I love it! But here I would like to ask some questions about the “platform”.
– There are many ways for developers to provide the users with their application. Apart from Flatpak, there are also snap, AppImages, etc.. It seems that there are still many developers, however, *don’t* use Flatpak. (For example, Visual Studio Code, the code editor I really love.) When users use a Flatpak-based distro, what should they do to use their favorite apps which are not in Flathub? Yes we can re-package it, but it can break the app.
– When we are focusing on the desktop experience, what about the development experience? Yes we can use something like fedora toolbox, but how can the apps work together with the toolbox? A code editor need to have rights to work with the environment, like start a terminal, run a command, etc.. But the apps in a container can’t do these. For example, vscode in Flathub can’t work correctly without some special configuration.
– When we are using the same application repository, it’s easier for some people to block it. For instance, Flathub is nearly completely blocked in China, and mirroring it is much harder than we think.
Of course, I love the idea about creating a real platform for Linux applications, but it still seems impossible, at least at the moment. We, obviously, need to work harder :)
If there’s an app you’re using which isn’t available on Flathub (or is there, but not developer-submitted), I’d suggest asking the app developers about it :)
As far as I know there’s nothing stopping e.g. VSCode working well in Flatpak (other IDEs like GNOME Builder work great, and it does lots of hard-to-sandbox things, such as having a terminal on the host). Most likely it’s just a matter of the app developers accounting for Flatpak/sandboxing when developing certain features.
No idea how/why Flathub is different from a traditional distro repository in terms of mirroring/censorship-resistance, but this doesn’t seem like an insurmountable problem.
Well, I don’t think asking developer for a special build is a good idea. Many application developers offer only one kind of the Linux build and don’t want to work on Linux build any more, since it’s really complex.
After all, we have three “universal” Linux packaging method: Flatpak, snap and AppImages! That’s plenty and really confusing. The developers *don’t* have the responsibility to offer all of them.
Btw, Flathub uses Fastly CDN and the access to Fastly is stricted by China’s government.
Have you read the article? My entire point here is that there’s no such thing as “one Linux build”. You always need do *some* extra work for every platform you support.
That said, I don’t think it’s true that there are three universal package formats. AppImage is a niche thing, and Snap is tied to a distro, making it kind of a non-starter. Flatpak is clearly the future :)
I’d suggest opening an issue or getting in touch with the Flathub developers about the CDN thing.
If your argument is that Microsoft didn’t package the flatpak themselves I understand but both VScode and the OpenSource edition of it are packaged on flathub. I used VSCode OSS everyday via flatpak.
https://flathub.org/apps/search/visual%20studio
Power to the Makers
I think GNOME Builder is a great start at an IDE. That said GNOME Builder doesn’t seem to be well supported by the GNOME app developers. Download GNOME Builder in Ubuntu Software Center, run GNOME Builder, select GNOME Calendar from the suggested projects. Watch the dependency downloads fail. There doesn’t seem to be a window that shows status or what the problem is. Give up and try again using Flatpak. Dependencies downloaded (I guess they require flatpak?) but then try running Calendar. Oops more downloads. Finally, all downloads are done but sadly Meson errors out and doesn’t run. Lets check out the Calendar .ui files. They don’t help much either. I guess the developers prefer to inject the UI at runtime? Why even suggest a project that is so poorly supported?
Flatpak is Not Enough
No, it isn’t enough. It doesn’t offer support for services like SNAP for example. And how do I access my media files that are mounted in /storage using my Flatpak installed media app?
And if you want developers to use Flatpak, perhaps setup a way for them to sell their app.. You know like the Elementary folks. Great job and idea guys!
1. The Host Still Matters
Sure does. The sys tray is necessary for many people because the apps they use and require still require it. Some of us use our computers for work and some of what we use is partially out of our control. GNOME does things like discontinue all gasoline/diesel cars because it has decided electric is better. But many users do not have access to charging stations; not even at home. Too bad GNOME says.. we’ve been telling you for years we were going to do this. But how will I drive to work now?
Theming is broken because GNOME never provided a great way to customize the UI. Even the dark Adwaita theme has poor support in some GNOME apps. So even the GNOME devs can’t get it right with their own themes. KDE does a far better job at sorting this problem out. Maybe ensure the CSS file used is signed? And offer free signing of CSS files. The theme creator app could auto submit a JSON file to a webservice that generates the signed CSS file. The web service ensures the values provided are “acceptable”. This will allow distributions to use their color scheme for example.
Fragmentation Issues
Forget the installer. GNOME Disks can’t even handle fixing USB drives formatted with the built in Image writer. And now that Canonical is sorta supporting ZFS, that should be supported as well.
Configuration Issues
Default apps vary because most of the GNOME offering is severely lacking in features 80% of people use. Like Photos can’t rotate for example. And when I multi select photos why doesn’t it let me print them?
The Nuclear Option
I’d love a more standardized linux OS. The problem is the GNOME team is so overworked as it is. How about getting Wayland the default and adding some features to Photos and Disks and … Forget about the OS, the team can’t even get the GUI and apps right yet. Where are the kickstarter style pages with goals? I am not going to donate to GNOME without knowing what they will be using that money for. It is likely many are similarly skeptical of the GNOME team and their priorities. Let people donate to the features they want to see. Please, please set up a (https://kickstart.gnome.org)!
Squaring the Circle
Offer two releases? Stable and Rolling? Stable is updated os-tree style periodically?
The Bottom Line
IBM Redhat and Canonical Ubuntu are competitors. Add Microsoft (Platinum Linux sponsor) with their WSL2 ambitions. They care about dollar$ 1st and 2nd. 3rd is Image / Community. Don’t look to them.. they are Corporations who are required by law to favor money over morality.
Let’s kickstart these initiatives! Let the community take back the Linux kernel and Desktop OS.
Chrome OS is another example of Linux based platform.
With Chrome OS supporting Linux in a container (based on Debian 10) this could be a viable platform for app developers to target.
It is still missing a Linux based app store (it has Chrome Web app store and Android app store) but that should be fixable.
There’s no SDK, no docs, and really no means to make Chrome OS apps that way. There are Material design guidelines, but without an SDK the most realistic way to do that is to do a web app. In which case, why would you need a container if Chrome OS can do that natively?
Actually, I think you are missing out on one major aspect (even though you touched it slightly with the different GNOME UI paradigms): Different needs for release cycles.
This “one platform fits all” approach, just doesn’t work for everyone. Some people always want/need the latest and greatest (STS, rolling release), others don’t want anything to change at all (apart from security fixes) (LTS).
And that’s the great thing about traditional packages and distributions: You can choose whatever release model suits your use case the best. Even if the application developers don’t want to maintain a separate LTS branch, your distribution will make sure that the package continues to be maintained. Furthermore all packages in one distribution release are maintained for exactly the same time, so you can plan your major version upgrades without worrying about each app individually.
Flathub doesn’t work like this: The app developer dictates the release cycle. As a user I can only decide between updating or not updating and missing out on important security fixes.
If there are LTS releases available, each application has a different LTS cycle. It is impossible to do major upgrades (UI changes, functionality, etc.) as a single major upgrade (and educate the users about the changes in a single training). Instead I have a rolling-release-like approach, where I have to take new features/UI changes whenever the app developer thinks it may be time for them.
For personal use this might not be a significant issue, but if you are managing hundreds or thousands of desktops, this can be a major issue (training for new versions required, file format incompatibilites, etc.).
Another thing Flathub is missing: Reproducible builds
With traditional package repositories, I have to trust a single entity: My distribution (which hopefully carefully selects the package maintainers). The distribution makes sure that the packages don’t contain harmful functionality and that the binary and source code match (they are building each application from source). Many distributions also take part in the reproducible builds effort, so most packages (often times >= 80 %) can be verified by each individual user.
With Flathub I no longer have this “single entity of trust”, since I have to trust the developer of each individual application. Without reproducible builds, it is not guaranteed that the binary of an app on Flathub even remotely matches the available source code for that app.
So as long as Flathub doesn’t support and prominently displays if an application is build in a reproducible way, I would consider Flathub to be dangerous and untrustworthy.
Obviously these issues are Flathub, but not Flatpak, specific, since one could always create another Flatpak repository with reproducible builds.
> Even if the application developers don’t want to maintain a separate LTS branch, your distribution will make sure that the package continues to be maintained.
Let’s take a look at an application called GNOME Builder.
The latest point release in 3.28.x series is https://gitlab.gnome.org/GNOME/gnome-builder/-/tags/3.28.4, released almost 2 years ago.
Let’s take a look at Ubuntu LTS:
https://packages.ubuntu.com/bionic/gnome-builder
3.28.1.
If the distributions can’t maintain applications when the app developer _does_ maintain stable branches, what makes you think they would if the app developer doesn’t?
Ubuntu is certainly a bad example, since the universe and multiverse repositories are “community-maintained” and (security) updates are not guaranteed by Canonical (unless someone from the “community” steps in and maintains the package). gnome-builder is in universe, so it is not supported by Canonical and is not guaranteed to receive updates.
https://help.ubuntu.com/community/Repositories/Ubuntu
This is actually a major issue with Ubuntu LTS (since lots of people use these packages without knowing that they are unmaintained), but there are other LTS-distributions (Debian, Red Hat, SLES, …), which don’t ship such repositories by default.
Another noteworthy thing is that some distributions have restrictive policies that forbid version number changes within a release.
This creates unnecessary downstream effort, since fixes need to be backported to an older minor version.
For example gnome-builder 3.28.1 gets shipped on release day by some distribution. The next day gnome-builder 3.28.2 is released upstream, but rather than pulling in the minor release and bumping the version number by a minor version to 3.28.2, the distribution might start to backport the fixes from 3.28.2 to 3.28.1 and “bump” the version number to 3.28.1-1.
This certainly creates confusion for the end user (are the security issues fixed or not?) and creates unnecessary backporting.
These problematic distributions also often declare bug-fixes as new features since the behaviour of the application changes. So if gnome-builder 3.28.1 contained a bug which made it impossible to start FreeDOS VMs and 3.28.2 fixes this regression, the downstream might not integrate this bugfix into the “LTS” release, since it changes the behaviour of gnome-builder.
As a consequence the user has to wait for the next major release of the distribution, until a bug (which may be fixed upstream since a long time ago) is fixed in the distribution.
I did certainly not make these things up, as I was exactly in this kind of situation multiple times with Debian (primarily with bugs in drivers, memory leaks in mpv, etc.) …
I don’t like these kind of policies myself, but these policy issues don’t justify a whole new approach to package management in my opinion, but rather require revisiting by distribution maintainers.
As a user you luckily have a great selection of different distributions, so if you are unhappy with policies of one distribution, you can “simply” choose another one.
> these policy issues don’t justify a whole new approach to package management
Fair, it’s your opinion, we don’t have to agree on it :)
From my perspective as an app maintainer, I’ve seen distributions package the app I maintain without its runtime dependencies, hurting the reputation considerably (“I installed the app, but it couldn’t run any games, I had to apt-get install libretro-something, 1 star”). And you could say that maintainers can’t know all the app quirks when they package it. Of course they can’t, but they didn’t have to package it in the first place, that’s why we have Flatpak where is all just works. Literally a case when doing nothing would have been better.
I am somewhat still amused by your hope that Ubuntu will ever conform to a vanilla GNOME experience, or that they would “discuss radical changes upstream”, because I don’t expect for a minute that upstream GNOME will accept reverting back to showing icons on the desktop or having a permanent dock/launcher or having minimize buttons on windows again. Suppose Canonical folks went upstream to propose all that; It’ll last a whole five minutes before they’re told “Well thank you for your proposal, but that’s not how we designed it and we think this is out of scope”, leaving them with no choice but to continue their downstream forks. Let me be clear (before someone claims there is some sort of conspiracy/kabbal going on), I do not think there is any “animosity” on either side of upstream/downstream on those issues, just that the result of such major differences in design visions will inevitably lead to “we agree to disagree”. I’m a vanilla GNOME kind of guy, but I have empathy for Canonical/DIY folks in that way.
The only way out is to make GNOME OS a real end-user-facing and free-standing distro that lives or dies on its own (and then you will see if there is real demand for a pure upstream vanilla GNOME), but the problem is that for this to happen you need resources; as in, full-time paid people who will do the boring work of architecting and maintaining this thing without burning out or living on the streets.
I would tend to think it’s not “that” hard to create GNOME OS, in a way. Grab Fedora, rip out all the branding, make a handful of changes to the default selection (-SELinux, -firewalld, -Firefox, +Epiphany, etc.), nuke the Anaconda installer and plug https://calamares.io/about/ in its place, and then find someone insane enough to maintain PackageKit and GNOME Software. “Done!” But I’ve been waiting a decade for this and have not yet seen it happen—hence my presumption that you’ll need a paid team if you want it done in a timely fashion.
> the result of such major differences in design visions will inevitably lead to “we agree to disagree”.
I don’t think that has to be true, as long as the parties involved are interested in solving a problem rather than some particular solution. For most design problems there are multiple potential solutions, and some of them may work better than others in the context of the rest of the OS.
To take the example from the article: It’s not great for onboarding that the current GNOME Shell layout shows an emtpy desktop after boot, since you have to go to the overview before you can launch something.
One way you can solve this problem is by having the dash be visible on the desktop. This may seem like an “easy fix” but ends up having massive repercussions for the structure of the Shell. For example: If you can launch/switch apps directly from the dock, you end up barely using the overview. If you don’t use the overview, you’re less likely to use workspaces. If you don’t use workspaces you need some other way to hide windows, so you’ll want minimize. The list goes on. If go down this path you end up re-creating Windows 7, but with an awkward “Activities” button in the top left which nobody uses. At that point you’d be better off just redesigning the Shell without an overview.
A dock isn’t the only potential solution though. For example, what if we directly opened the app grid on startup? It’s possible this would solve same problem in a way that doesn’t break what’s great about GNOME Shell (e.g. the “single destination” overview, distraction-free layout, great keyboard workflow).
My point is: Pushing for having a problem fixed (e.g. “new users are confused by the empty desktop at startup”), rather than a specific implementation (e.g. “add a dock”), is much more likely to succeed and produces better results for everyone. As pointed out in the article this isn’t always easy, but it’s working well for some companies. I see no reason why it couldn’t work for Ubuntu, Endless, etc.
All of the really big and important applications transcend this whole discussion, because they aren’t just available across distributions but across OSes. As is every web site (which is a sandboxed application). The visual consistency and theming goal was abandoned a very long time ago. Perhaps not abandoned, but relegated in significance. People cope.
On the other hand, it’s pretty uncommon for web sites to push the “do this now” button off-screen to a place where it is both invisible and inaccessible, but that seems to be the common design pattern of Gnome applications when I run them on small (default size) virtual screens.
Interesting posts, thanks. I agree with you about many of the problems with distros – as an upstream developer, it’s very frustrating when packagers decide they know better and change things with no consultation.
But I can’t agree that the solution is to target desktops as platforms instead. All the major applications I spend time using – both open source things like Firefox and proprietary ones like Dropbox or Jetbrains IDEs – work the same on GNOME, KDE, Xfce, or any other major Linux desktop. It’s quite possible to target desktop Linux as a single platform, and I can only imagine it would be easier if the big desktop projects accepted this, and focused more on interoperability rather than trying to get people to build GNOME- or KDE-specific apps.
Of course, that won’t give us consistent UI across applications. But focusing on consistency is not exactly playing to the strengths of the open source community. And I think its importance is often overrated – many successful applications do not look fully native on successful platforms. For many years, even Microsoft Office didn’t follow the look & feel of a standard Windows application.
> All the major applications I spend time using […] work the same on GNOME, KDE, Xfce
> It’s quite possible to target desktop Linux as a single platform
Read the article again (specifically this part), my entire point here is that it’s not.
Even apps that don’t use the native toolkit, bundle all their libraries, don’t use any system APIs, run via Flatpak, etc. still face both technical and design problems. For example, most apps use notifications, but different desktops support very different subsets of the Freedesktop notification spec (e.g. until recently GNOME was the only desktop that supported notification actions). Even games, which are about as self-contained as you can get, still face these problems, because they are still relying on the host for graphics drivers.
So while it’s possible to have apps work in a range of environments if you do very little system integration, this doesn’t come for free. Just ask the people developing these apps ;)
I am one of these application developers you speak of. My application is written in Qt 5 and looks the same regardless of which desktop its running in. It’s not a KDE app (for technical reasons it cannot be, because it’s not written in C++), and it’s certainly not a Gnome app, obviously. I’ve had to write custom code to fit in with the peculiarities of different desktops, of which there are many.
I fear the vision you lay out, Tobias, because of how it will inevitably be implemented. Take something very small & simple: application launcher progress bars. Ubuntu pioneered them, probably after copying Windows 7 (or was it Vista?). KDE picked them up using Ubuntu’s libunity. Sounds good so far for the application developer. One API, easy to use, cross-platform. Cool. But wait, of course, it’s Linux. Life is not so simple. So the Mint people go ahead and do their own thing, independently of everyone else, with their own incompatible API, which does not support Qt. And as for the Elementary folks, well, I don’t know what the heck they’re doing, but it seems their solution is different again (I’m assuming they use them at all; certainly they use a libunity incompatible version of badge counters) . Great. Lots of fragmentation. :-/
(And of course, vanilla Gnome doesn’t want application launcher progress bars or badge counters because they make no sense in its paradigm, which is unique. More fragmentation there too.)
But the point is, the Elementary and Mint folks are the ones trying to build a platform. A consistent look. Easy to use. Etc. Yet in doing so they’re introducing fragmentation and making life for cross platform developers like me more difficult, not less.
And I’m not optimistic this will ever change, because Linux desktop developers — more than anything else — like following their own star. This is how one Mint developer put it:
“Whenever we introduce a new standard like this, the point is never to push for universal adoption. Rather, we simply aim to make it work well for Mint itself. Our point is really to make Mint feel like more than just a collection of packages, and a big part of that is making all of our stuff feel more integrated. If someone else does find these things useful, that’s great, and we’ll do our best to support that, but we don’t do what we do because we’re trying to change what everyone else does – just to do what we do better.”
Could there be a better summary of why a unified platform vision will fail? And let’s be honest — this is not unique to Mint. Lots of developers on all platforms think like this. Some get away with it because they have more top-down control and more power than others.
Having said all that, a counter-argument to my objections is Python. They’ve manged to keep rolling without too many wheels falling off. They have clearly been blessed with leaders of great vision and technical ability — and most of all, arguably, real care for the varying needs of their diverse community.
Thanks for your blog post. I know and feel the pain. What I missing here two things:
We should use the distributions, there knowledge, especially package management and maintainers to build a “Linux OS”. Especially the maintainers. Because there is not just GNOME and some KDE applications but much more CLI and TUI applications and users which need to use an all purpose computer. A good example is already Archlinux, it ships plain vanilla software. Actually a foundation to build upon. GNOME and KDE shouldn’t “win” against distributions, because the people and infrastructure there is actually the solution which should be combined. We should merge them together.
Yep. Probably 15 out of 18 distributions and forks of distribution will disappear, but all the people working there are actually needed. Please don’t give anyone the feeling of being an problem which need to be vanished. Actually these people (maintainers) are all the solution we need to merge together.
To other thing is, GNOME is part of the problem:
Since how many years we have this “small issue around terminal transparency”? It was a main feature for years, it’s thankfully maintained and got re-implemented in VTE3 and still we have to patch it in downstream. I don’t want start the blame game again. But GNOME states always “settings are bad, options are bad, expert options which are hidden are bad”. Same for the option which prevents suspend to S3 on LID-CLOSE. Everyone which want just cover his keyboard, keep the compiler working or move around without loosing WiFi has to use Systemd for this now. Users decide themselves what is useful ;-)
I know, that the lesson learned from GNOME 1 and that old dusty website is that “three clock widgets are two to much”. Well, one would be enough – if it overs the necessary options. GNOME doesn’t need need to be KDE which allows you to choose between “modal popup renaming of files” and “inline renaming of files” in Konqueror. But application features need to fit for the application developer and users :)
Bloat is bloat. Useful features and options are useful for some of us.
I totally agree with your statements. I am not a developer but I’ve understood what you’ve just said. There is ONE windows, ONE mac and MANY linux. Not just XFCE,KDE,GNOME and PANTHEON. Four platforms might not be a problem for the developer in this stage, but every distros customize the desktop experiences by modifying the base desktop environment.
If its four platforms, we need every distros to provide the raw experience of DE and the package management like Elementary team had proposed.
*** I am using a Vanilla GNOME on my Arch Linux. But I’ve enabled Adwaita Dark Theme.***
I’m creating an XR DE (Stardust) that’s almost entirely modular for Linux, and since XR is a field that Linux has never been established in before I’d like to know how to best prevent these issues. I’m sure other DEs will come around, but from my knowledge Stardust will be the first that is more than flat rectangles in space that you point at, having full 3D app support with an API similar to Ubuntu Touch. I will make sure to support Wayland/X and such through a generic API, but even so I am having difficulty with aspects such as app theming and a way to make 3D apps interoperable between other environments than mine. Any thoughts or help would be appreciated, and let me know if you want my email. Stardust is very early in development and can be found at https://github.com/technobaboo/stardust-xr.
Since XR is such a new medium I want to make sure GNU/Linux gets the best shot it can at reducing fragmentation and increasing vertical integration, so any help would be nice.
Thanks!
My recommendation is simple: Don’t build an XR desktop, build a platform with everything that entails: Desktop, apps, OS, design guidelines, developer docs, app store, etc.
Part 1 of this series has a full list, and a bit more context. In a nutshell, don’t build something like KDE, build something like elementary.
Bonus points for not basing it on an existing distribution, but going the Flatpak/FreedesktopSDK route :)
I’ve just created new project GNOME OS Installer (not only for future GNOME OS). You can take a look and contribute .
https://gitlab.gnome.org/okalousek/gnome-os-installer
Cool stuff! I’d recommend joining #gnome-os on IRC/Matrix and talking to people there about it. As far as I know they’re currently using a modified version of the Endless installer, which is itself based on GNOME Initial Setup.
From a design point of view I think we have a fairly clear vision: Do as little as possible in the installer, and defer decisions to inital setup. There are some initial designs here: https://gitlab.gnome.org/Teams/Design/os-mockups/blob/master/installer/installer.png
Join us in #gnome-design on IRC/Matrix to discuss the design side :)
Sad thing is, endless os have already done it, so…
I’ve not been following this closely, but last I saw it, the Endless OS one was not really what we’d want upstream design-wise and the GNOME OS devs said they’re using it mostly a stop-gap/starting point.
I’d recommend asking in #gnome-os about the current status.