GNOME 50 released [LWN.net]

GNOME 50 has been released. Notable changes in this release include enhancements to the Orca screen-reader application, interface and performance improvements for GNOME's file manager (Files), a "massive set of stability and performance updates" for its display-handling technologies, and much more. See also the "What's new for developers" article that covers changes of interest to GNOME and GNOME application developers.

to post comments

X11

Posted Mar 18, 2026 18:13 UTC (Wed) by jond (subscriber, #37669) [Link] (1 responses)

I’d heard it suggested that this release would drop X11 support. Has that happened?

X11

Posted Mar 18, 2026 18:15 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

There is no longer any support for a X11 session. XWayland continues to be included for supporting X11 applications.

Desktop-wide settings not applied to all apps -- freedesktop.org

Posted Mar 19, 2026 4:48 UTC (Thu) by swilmet (subscriber, #98424) [Link] (12 responses)

The new accessibility Reduced Motion option looks great, but only GTK 4 apps apply it, as I understand it. So there is an inconsistency with apps using an older version of GTK, or Qt/KDE apps, etc.

So desktop-wide settings are not applied to all apps, and older toolkit versions will probably never be updated (GTK 3 has entered in deep-maintenance mode: only crash and build fixes are accepted).

Another example is the Large Text accessibility option from GNOME. GTK apps understand it, while Qt/KDE apps not. So when I need to use a Qt app within GNOME Shell, I need to figure out how to zoom in in order to use the app comfortably.

The solution has already existed for a long time: freedesktop.org specs. But GNOME seems less interested by it, for example for the icon themes.

Desktop-wide settings not applied to all apps -- freedesktop.org

Posted Mar 19, 2026 5:49 UTC (Thu) by mroche (subscriber, #137163) [Link] (5 responses)

I'm not a desktop app developer, so what freedesktop.org specs/APIs be analogous or pertinent to solving the GNOME/GTK examples you've mentioned?

Desktop-wide settings not applied to all apps -- freedesktop.org

Posted Mar 19, 2026 9:04 UTC (Thu) by swilmet (subscriber, #98424) [Link] (4 responses)

XSETTINGS is a good example:

https://www.freedesktop.org/wiki/Specifications/xsettings...

> The XSETTINGS protocol provides a mechanism for applications written with different toolkits to share simple configuration settings such as double-click-times and background colors.

GTK has GtkSettings wrapping it:

https://docs.gtk.org/gtk4/class.Settings.html

> Provides a mechanism to share global settings between applications.
>
> GTK relies on the platform-specific API for getting desktop-wide settings.
>
> On Wayland, the settings are obtained via a settings portal that is part of the Linux desktop APIs for application.
>
> On the X window system, this sharing is realized by an XSettings manager.

So yes, as lunaryorn pointed out, there is a cross-desktop portal API.

But legacy toolkits will become more and more inconsistent with the rest of the desktop.

Desktop-wide settings not applied to all apps -- freedesktop.org

Posted Mar 19, 2026 12:36 UTC (Thu) by jond (subscriber, #37669) [Link] (2 responses)

> But legacy toolkits will become more and more inconsistent with the rest of the desktop.

I had to read that a few times to understand what you meant. I presume what you meant is, "non-GNOME toolkits"?

Desktop-wide settings not applied to all apps -- freedesktop.org

Posted Mar 20, 2026 9:43 UTC (Fri) by swilmet (subscriber, #98424) [Link] (1 responses)

By legacy toolkits, I meant old versions like GTK 2 (which has reached end-of-life), or GTK 3 (no longer actively developed; only crashes and build failures are fixed), or old versions of Qt, etc.

So for an app to remain well-integrated with the desktop environment (GNOME, KDE, …) it needs to be ported to the latest toolkit version.

As a developer I use GTK 3 so I see more and more integration issues that crop up. Another example is the Adwaita theme. GTK 3's Adwaita is not the same as GTK 4's libadwaita.

So some users start to complain: "it looks outdated", etc. GUI app development can be ungrateful in that regard, compared to backend software. Like for the fashion industry, things _need_ to change, otherwise users get bored. I don't necessarily agree with that trend, and my hope was that Free Software UI can resist the temptation to constantly change everything…

Desktop-wide settings not applied to all apps -- freedesktop.org

Posted Mar 21, 2026 9:45 UTC (Sat) by jond (subscriber, #37669) [Link]

Thank you for clarifying. I had uncharitably interpreted your message (at least privately) as “anything except gtk4/libadwaita is legacy.” That was unfair and I’m sorry.

Desktop-wide settings not applied to all apps -- freedesktop.org

Posted Mar 19, 2026 16:40 UTC (Thu) by ebassi (subscriber, #54855) [Link]

XSETTINGS is irrelevant in 2026.

Toolkits (and applications) should be using the Settings desktop portal, which includes the reduced-motion setting, and gets proxied by whatever desktop setting—for instance, the reduced-motion setting in GNOME, or the animation duration setting in KDE.

Desktop-wide settings not applied to all apps -- freedesktop.org

Posted Mar 19, 2026 8:21 UTC (Thu) by lunaryorn (subscriber, #111088) [Link] (5 responses)

I'd like to point out that the reduced motion setting is specified as a cross-desktop portal API, and available for all toolkits to consume, under any desktop environment that implements portals.

It's up to Qt/KDE to implement support for this setting. Gtk 3 probably doesn't matter much, since it never had many standard animations to begin with, as far as I remember.

Desktop-wide settings not applied to all apps -- freedesktop.org

Posted Mar 19, 2026 9:14 UTC (Thu) by swilmet (subscriber, #98424) [Link] (4 responses)

> Gtk 3 probably doesn't matter much, since it never had many standard animations to begin with, as far as I remember.

There are animations with GTK 3 too, for example with GtkRevealer (Hide and show with animation) or with a GtkStack transition (show another child widget).

The setting probably also applies to things like background color fading when a row in a list becomes selected/unselected.

Desktop-wide settings not applied to all apps -- freedesktop.org

Posted Mar 19, 2026 16:49 UTC (Thu) by ebassi (subscriber, #54855) [Link] (3 responses)

> The setting probably also applies to things like background color fading when a row in a list becomes selected/unselected.

No, it does not.

Reduced motion has a very specific meaning:

> The user has notified the system that they prefer an interface that removes or replaces the types of motion-based animation that either trigger discomfort for those with vestibular motion sensitivity, or distraction for those with attention deficits.

It's not a toggle to remove all animations—that would be counterproductive, because animations *can* convey meaning, and disabling them altogether (which is what the previous setting did) removes that meaning. Fade in/out should actually be used in place of motion.

Desktop-wide settings not applied to all apps -- freedesktop.org

Posted Mar 20, 2026 9:16 UTC (Fri) by swilmet (subscriber, #98424) [Link]

Thanks for the clarifications.

Desktop-wide settings not applied to all apps -- freedesktop.org

Posted Mar 27, 2026 5:18 UTC (Fri) by jokeyrhyme (guest, #136576) [Link] (1 responses)

i've often wondered if maybe it'd be a good idea to have all accessibility features (or at least the ones without security ramifications) enabled by default, or perhaps to design interactions such that there aren't meaningless flourishes

what would a desktop environment look like (and feel like) if it was accessible by default? or going further, if there weren't any options at all to make something less accessible?

accessibility by default

Posted Mar 30, 2026 14:28 UTC (Mon) by smcv (subscriber, #53363) [Link]

Many accessibility adjustments are necessary for the subset of users who need them, but make things actively worse for users who don't need them, so they're tradeoffs. Perhaps the most obvious is that some desktop environments have a "normal" UI theme for most people, a low-contrast variant for users who find medium to high contrast painful, and a high-contrast variant for users who find low to medium contrast unreadable. None of those is suitable for everyone, and there's no way to have the benefit of all of them at the same time!

Similarly, zoom/magnifier features and large text mean that less information fits on the screen, screen readers are necessary if you can't see the screen but noisy and distracting if you can, and keyboard tweaks like sticky modifier keys are a serious usability problem if you're not expecting them.

For accessibility features that don't involve any trade-off (like making sure colour-coded indicators are distinguishable by shape as well as colour), of course, it makes sense to have them enabled unconditionally and just not have an option.