GNOME 42 is fresh out the door, bringing some exciting new features – like the new dark style preference and the new UI for taking screenshots and screen casts. Since we’re right on the heels of a release, I want to keep some momentum going and share my plans for features I want to implement during the upcoming release cycles.
Accent Colors and Libadwaita Recoloring API
The arrival of libadwaita allows us to do a few new things with the GNOME platform, since we have a platform library to help developers implement new platform features and implement them properly. For example, libadwaita gave us the opportunity to implement a global dark style preference with machinery that allows developers to choose whether they support it and easily adjust their app’s styling when it’s enabled. Alexander Mikhaylenko spent a long time reworking Adwaita so that it works with recoloring, and I want to take full advantage of that with the next two features: global accent colors and a recoloring API.
Libadwaita makes it simple to implement a much-wanted personalization feature: customizable accent colors. Global accent colors will be opt-in for app developers. For the backend I want accent colors to be desktop- and platform-agnostic like the new dark style preference. I plan to submit a proposal for this to xdg-desktop-portal in the near future. In GNOME it’d probably be best to show only a few QA-tested accents in the UI, but libadwaita would support arbitrary colors so that apps from KDE, GNOME, elementary OS, and more all use the same colors if they support the preference.
Developers using the recoloring API will be able to programmatically change colors in their apps and have dependent colors update automatically. They’ll be able to easily create presets which can be used, for example, to recolor the window based on a text view’s color scheme. Technically this is already possible with CSS in libadwaita 1.0, but the API will make it simpler. Instead of having to consider every single color, they’ll only need to set a few and libadwaita will handle the rest properly. The heuristics used here will also be used to ensure that accent colors have proper contrast against an app’s background.
There’s no tracking issue for this, but if you’re interested in this work you may want to track the libadwaita repository: https://gitlab.gnome.org/GNOME/libadwaita/
Adaptive Nautilus and Improved File Chooser
The GTK file chooser has a few issues. For example, it doesn’t support GNOME features like starred files, and it needs to be patched by downstream vendors (e.g. PureOS, Mobian) to work on mobile form factors. In order to keep up with platform conventions, ideally the file chooser should become part of GNOME’s core rather than part of GTK. There’s some discussion to be had on solutions, but I believe that it would be smart to keep the file chooser and our file browser in sync by making the file chooser a part of the file browser.
With all of that in mind I plan to make Nautilus adaptive for mobile form factors and add a new file chooser mode to it. The file chooser living in Nautilus instead of GTK allows us support GNOME platform features at GNOME’s pace rather than GTK’s pace, follow GNOME design patterns, and implement features like a grid view with thumbnails without starting from scratch.
If you’re interested in seeing this progress, keep track of the Nautilus repository: https://gitlab.gnome.org/GNOME/nautilus/
Loupe (Image Viewer)
For a while now I’ve been working on and off on Loupe, a new image viewer written in Rust using GTK4 and libadwaita. I plan for Loupe to be an adaptive, touch pad and touchscreen friendly, and easy to use. I also want it to integrate with Nautilus, so that Loupe will follow the sorting settings you have for a folder in Nautilus.
In the long term we want Loupe to gain simple image editing capabilities, namely cropping, rotation, and annotations. With annotations Loupe can integrate with the new screenshot flow, allowing users to take screenshots and annotate them without needing any additional programs.
If Loupe sounds like an interesting project to you, feel free to track development on GitLab: https://gitlab.gnome.org/BrainBlasted/loupe/
Rewrite Baobab in Rust, and Implement new Design
Baobab (a.k.a. Disk Usage Analyzer) is written in Vala. Vala does not have access to a great ecosystem of libraries, and the tooling has left something to be desired. Rust, however, has a flourishing library ecosystem and wonderful tooling. Rust also has great GTK bindings that are constantly improving. By rewriting Baobab in Rust, I will be able to take full advantage of the ecosystem while improving the performance of it’s main function: analyzing disk usage. I’ve already started work in this direction, though it’s not available on GitLab yet.
In addition to the rewrite, I also plan to implement a redesign based on Allan Day’s mockups. The new design will modernize the UI, using new patterns and fixing a few major UI gripes people have with the current design.
You can keep track of progress on Baobab on GitLab: https://gitlab.gnome.org/GNOME/baobab
Opening Neighboring Files from FileChooser Portal
The xdg-desktop-portal file picker doesn’t allow opening neighboring files when you choose a file. Apps like image browsers, web browsers, and program runners all need a sandbox hole if they want to function without friction. If you use a web browser as a flatpak you may have run into this issue: opening an html file won’t load associated HTML files or media files. If you are working on a website locally, you need to serve it with a web server in order to preview it – e.g. with
python -m http.server.
I want to work on a portal that allows developers to request access to neighboring files when opening one file. With this portal I could ship Loupe as a flatpak without requiring any sandbox holes, and apps like Lutris or Bottles would also be more viable as flatpaks.
If you want to learn more and follow along with progress on this issue, see the xdg-desktop-portal issue on GitHub: https://github.com/flatpak/xdg-desktop-portal/issues/463
GTK4 makes accessibility simpler than ever. However, there are still improvements to be made when it comes to making core apps accessible. I want to go through our core app set, test them with the accessibility tooling available, and document and fix any issues that come up.
Sponsoring my Work
I hope to be able to work on all of these items (and more I haven’t shared) this year. However, I am currently looking for work. Right now I would need to be looking for work full-time or working on something else full-time instead of working on these initiatives – I don’t have the mental bandwidth to do both. If you want to see this work get done, I could really use your support. I have three places you can support me:
- GitHub Sponsors
- Paypal.me (for one-time payments)
If I get enough sponsorships, I plan to start posting regular (bi-weekly) updates for GitHub sponsors and Patrons. I also may start streaming some of my work on Twitch or YouTube, since people seem to be interested in seeing how things get done in GNOME.
That’s all for now – thanks for reading until the end, and I hope we can get some or all of this done by the time of the next update.
17 Replies to “Plans for GNOME 43 and Beyond”
Thumbnails? In the file picker. Is this April 1st?
Nice post. One thing that could be improved in Gnome screenshots is how shadows look like in screenshots of windows. The issue is visible quite well in this post. You’ve included a few screenshots. The shadows kind of suddenly stop at some point creating a weird-looking effect.
Great stuff! I can’t wait for the filepicker meme to die. Btw, I think I found a typo – “but I believe that it would be smart to keep the file chooser and our file browser in sync by making the file chooser a part of the file chooser”. I think you meant “by making the file chooser a part of the file browser”.
Accent colors, as implemented in Ubuntu 22.04, are awesome. It is wonderful you will bring this functionality to upstream GNOME.
That sounds great
How will this exactly affect the GTK file picker on other GTK based desktops like xfce or cinnamon.
It won’t – apps on those desktops will continue to use whatever file chooser they call. If they use the GtkFileChooserNative API, then they may get either a file chooser provided by their desktop’s portal implementation or a fallback file chooser.
I am a longtime open source user and particularly interested in gnome (Fedora and Librem 5 user) but I know very little about the costs associated with developing gnome. How can I better educate myself to understand the development costs? I’d like to see what I can do within my own circles to help lobby for funds to see more development happen sooner.
That’s difficult to quantify. It varies from person to person. The development tools are free, but the time we spend working on GNOME means we aren’t working on other things that could bring in money. To work full-time on GNOME, it would essentially need to cover someone’s cost of living.
Great news! I also look forward to see the new StatusNotifierItem/systemtray (tray icon replacement) spec being finished and implemented. This is a big blocker for many users and it’s great to see this finally being worked on. 🙂
You are writing ‘…making the file chooser a part of the file chooser’ – a typo here? If I (as an enduser) understood you correctly – the plan is to use Nautilus as a file chooser too? I think that is a great idea and concept!
Just to mention: in the Rox desktop there is drag-and-drop used for saving too. Just to mention as it is an interesting concept.
Hey I appreciate your post and your helping keep the community up to date with new things Gnome.
I noticed a small mistake,
I believe that it would be smart to keep the file chooser and our file browser in sync by making the file chooser a part of the file chooser.
To be clear, the file chooser will soon be part of the file browser?
Very eager to get my gtk skills up to par so as libadwaita has me very excited about joining the gnome ecosystem.
If the file chooser is taken out of GTK and moves to GNOME core, does that mean GTK would use the native file chooser on other platforms like Windows and MacOS? Or even the KDE one when GTK apps are run in that environment.
I think that could be a good thing, but it may require small tweaks to some APIs because those other file choosers work slightly differently.
That technically should already be the case. I believe it already is the case on KDE. Apps should be using the GtkFileChooserNative API, which calls xdg-desktop-portal on Linux. That should bring up a KDE file chooser on KDE, for example.
For proprietary desktops I’m not entirely sure what it does. I need to look into that further.
I just tried on macOS and GtkFileChooserNative opens a native macOS file chooser.
I’ve added your fundraiser here:
Feel free to update the link or do other edits 😉
Thanks for your work in GNOME 🙂 !
Exited for this constant evolution of the GNOME platform!
As I use Xfce on my (old) laptop the idea of moving the GTK file chooser outside of GTK makes me worry… What’s going to happen, exactly? I don’t think that Xfce has a “native” file chooser that can be used as a fallback.
Oh, and thanks for your work on the Linux desktop 😀