elementary OS 6 introduces two major new ways to make the desktop feel more personal: accent colors and dark style. The latter is something that’s become especially ubiquitous recently on mobile operating systems and the web. Open Source desktops have also begun offering a system-wide dark mode, but typically with a major drawback that operates much differently from the mainstream platforms: it operates on an opt-out basis rather than opt-in. This is what sets the dark style preference in elementary OS 6 apart from the offerings in, for example, Ubuntu or Pop!_OS. You can read a lot more about motivations and research that went into that decision in Cassidy’s previous blog post:
System Settings & Onboarding
The last time we blogged about the dark style preference, we had a very minimal prototype that offered a simple toggle and an explanation that this setting would only affect the panel and “system components”. Originally the plan was to only support the dark style in the desktop shell in elementary OS 6 and not to support changing it for apps at all. This would only include the panel, the dock, notifications, the authentication agent, and the keyboard shortcut overlay.
Eventually we extended “system components” to include apps like Screenshot and Sideload as well as System Settings. We also developed some illustrations that reflected the idea that apps wouldn’t be included. Between these two screenshots you can see how much the dark style has changed: the most noticeable being the use of a much more neutral base color and the improved contrast between buttons and the background. You’ll also notice that since the introduction of the elementary settings daemon you’re now able to schedule an automatic dark style change at sunset or by manually specifying a time. Keep in mind that this has grown quite a lot in a short amount of time and we’re still iterating on the exact design. Things could still change significantly before the final release.
We also now present the dark style and accent color choice when you first log in via Onboarding, and of course this app was added to the list of apps which support the dark style.
Challenges with Apps
As we began to implement dark style support across all of the system components in our desktop, we started to feel confident about the idea of supporting it in apps too. We started small with simple apps like Calculator, but I’m happy to say that as of this time nearly all of the default apps in elementary OS follow the dark style. This isn’t as easy as it sounds. As I alluded to earlier, the dark style preference in elementary OS 6 is “opt-in”, meaning that developers must explicitly choose to support it. This is important because of so many places where app styles break when developers aren’t testing against the dark style. Consider for example, Calendar:
This is a fairly common example of an app that had been developed against the light style and when forced to use the dark style would become completely illegible and thus unusable. Under an “opt-out” system, users would be stuck having to switch the entire system style preference every time they wanted to use this app until the developer hopefully delivered a fix.
Also consider an app like Mail, which still does not support the dark style preference because of the nature of its content. It’s unclear how Mail should handle displaying HTML emails which probably don’t provide CSS that accounts for a dark style. There’s still an open discussion about whether Mail should display HTML emails in a way that may blindingly contrast with its UI.
Another case yet to be resolved is for apps like Code and Terminal which offer multiple color schemes. In these apps, the color scheme also affects the content and there are multiple possible choices for light color schemes. This complexity becomes compounded as soon as these apps support custom color schemes as well. For now, we’re considering a simple switch to alternate between two pre-determined default styles with Terminal defaulting to “off” and Code defaulting to “on”. This keeps with Terminal always using the dark style by default, but Code matching the behavior of other light-by-default apps.
Changes to iconography also have to be considered when supporting a dark style. Several places sidebar icons in Files, for example, are far less legible in the dark style and will need to be redesigned for better contrast.
There are still other places in the UI where we support the dark style, but that support could be made better like in System Settings → Displays. The colors used for each display are quite bright and could be much dimmer when the dark style is activate. If you’re curious about more examples of places where apps could not support the dark style without some modification, you can follow along with our Prefer Dark Style project on GitHub.
Cross-platform & Flatpak Support
Another area we’re still working on is support across the FreeDesktop ecosystem and especially within Flatpak apps. At the moment, apps need to be able to access the system AccountsService to be able to read the elementary dark style preference. After discussion with app developers, this doesn’t seem to be something that works for them and especially for Flatpak’d apps is a bit frowned upon.
Two other approaches are either to expose the dark style preference via GSettings or via a DBus endpoint. GSettings is familiar and simple for developers writing apps for elementary OS or GNOME (among other desktops), but it seems the current consensus is that Flatpak’d apps should only be able to access their own GSettings schemas. This leads us to believe that exposing a DBus endpoint is probably the best option to encourage adoption by 3rd-party apps. So, in the near future, elementary settings daemon should handle that.
We’re looking forward to feedback from some GNOME app developers about the acceptability of the DBus solution. For app developers using Granite, we already provide a very simple
Granite.Settings object that abstracts everything away and makes it as easy as connecting to a signal, the same way you would handle
Gtk.Settings. We’ll provide documentation for this, and more, when elementary OS 6 enters public beta.
Get Early Access
If you’re excited by what you read here and want to get your hands on the developer preview of elementary OS 6, you can! GitHub sponsors at the $10/mo or above tier get access to our daily builds server where you can test the latest and greatest experimental builds, including builds for Pinebook Pro. Subscribing helps us fund the development of elementary OS and brings us that much closer to delivering the final product.
Thanks to all of our supporters, backers, and customers! Your contributions make elementary possible. If you’d like to help build and improve elementary OS, don’t hesitate to Get Involved.