♞ Coming up on 9TO5Linux ♞
GNOME 43 Release Date Slated for September 21st, 2022
While you’re still enjoying the new features of the GNOME 42 desktop environment, the GNOME
Project already kicked off work on the next major release, GNOME 43, with a release date
slated for later this year.
The release schedule for the upcoming GNOME 43 desktop environment series was published
at the end of March 2022, shortly after the release of the GNOME 42 desktop environment,
suggesting that the final release date is slated for September 21st, 2022.
GNOME 43 will be the third major update in the GNOME 4x series, and development slowly
kicked off this month but an alpha version will be readied for public testing in early
July, while the beta version is expected a month later in early August.
Here’s the official GNOME 43 release schedule:
GNOME 43 Alpha – July 2nd, 2022 GNOME 43 Beta – August 6th, 2022
GNOME 43 RC – September 3rd, 2022 GNOME 43 Final – September 21st, 2022
Later in July, the GNOME devs will attend this year’s GUADEC (GNOME Users And Developers
European Conference) event, which will take place between Wednesday, July 20th, and Monday,
July 25th.
GUADEC 2022 will mark GNOME’s 25th anniversary and will take place in Guadalajara, Mexico.
As for the new features to be implemented in GNOME 43, it’s too early to talk about
them.
However, GNOME developer Christopher Davis laid out his plans for an adaptive Nautilus
for mobile form factors, improved file chooser, accent colors, a new image viewer written
in Rust/GTK4 called Loupe, redesign and Rust porting of Baobab (Disk Usage Analyzer), and
improved accessibility.
For more details and if you want to support his work, do check out his blog.
Meanwhile, if you’re using the GNOME 42 and 41 desktop environment series, look out
for the GNOME 42.1 and GNOME 41.6 point releases, which are out this week and should arrive
soon in the stable software repositories of your favorite GNU/Linux distribution.
:: More ::
Plans for GNOME 43 and Beyond 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.
libadwaita recoloring demo 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.
Nautilus with thumbnails of various files 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.
Image of Loupe's main screenLoupe displaying a picture of a field of red flowers
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
Accessibility Fixups 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.
Thanks for watching,
I hope you enjoyed this video,
If you did hit that thumbs up button, it helps me to make good content for you, other then
that, I will see you in tomorrow's video, peace out.