Individual GNOME applications
Individual GNOME applications
Posted Jun 24, 2025 5:40 UTC (Tue) by SiB (subscriber, #4048)Parent article: GNOME deepens systemd dependencies
Will it become difficult or impossible to run individual applications with sysv and X11?
Posted Jun 24, 2025 6:58 UTC (Tue)
by ebee_matteo (subscriber, #165284)
[Link] (16 responses)
At some point the move to wayland will kinda kick in, and then I expect X11 to slowly go away simply because there seem to be a strong dip in number of commits/bugfixes. Certain things like HiDPI and multiple monitor setups that are expected by modern users are very difficult to add to X11. But wayland is quickly closing the gap. Running old applications requiring X under Wayland is mostly fine by now.
But at the end, it's a matter of effort and distro support. As long as there are enough sysv or openrc users around willing to support them, it will keep working. Maybe not with GNOME, but there are other DEs out there. Systemd also has a compatibility layer for sysv.
The reality is that Linux is becoming more successful also for enterprise workstations. Which is what most of us always wished for, right? More "market share". That means that covering a lot of use cases that are "enterprise" in nature (e.g. Microsoft Entra ID interoperability) is mandatory to stay relevant. These were not as important before. Now businesses which are financing development are strongly pushed to cater for these requirements. Read Red Hat, for instance, from governments and companies around the globe.
At some point, we need to understand that we are somewhat victims of our own success. The system becomes more complicated because it needs to, not just because some youngsters think reimplementing everything is fun. This is an hobbyist system becoming finally mainstream, and having to respond to regulatory and interoperability constraints.
Posted Jun 24, 2025 8:18 UTC (Tue)
by pabs (subscriber, #43278)
[Link]
Posted Jun 24, 2025 8:19 UTC (Tue)
by pabs (subscriber, #43278)
[Link] (3 responses)
Posted Jun 24, 2025 17:36 UTC (Tue)
by pbonzini (subscriber, #60935)
[Link] (2 responses)
What you might remember is moving away from supporting all apps in favor of flatpak—one major example being LibreOffice.
Posted Jun 25, 2025 5:28 UTC (Wed)
by ebee_matteo (subscriber, #165284)
[Link]
Posted Jun 26, 2025 3:35 UTC (Thu)
by pabs (subscriber, #43278)
[Link]
Posted Jun 24, 2025 9:56 UTC (Tue)
by paulj (subscriber, #341)
[Link] (3 responses)
That's news to me. I've been running X11 on my Dell XPS laptop with (very) HiDPI and plugging in and out of external monitors since I got that laptop - and it's at least a decade old. (There were HiDPI issues initially, they are largely gone - before Wayland was a useable thing).
Posted Jun 24, 2025 9:57 UTC (Tue)
by paulj (subscriber, #341)
[Link]
Posted Jun 24, 2025 16:32 UTC (Tue)
by smurf (subscriber, #17840)
[Link] (1 responses)
Also, don't even think about trying to span monitors of disparate resolution with a single window.
Also² don't get me started on other silly assumptions in the X11 codebase. Simple example: Wayland thinks that negative pointer coordinates are a perfectly cromulent thing to have. Xwayland does not. You guess what happens on my monitor setup, where monitor #2 is mounted 120 pixels higher than #1.
Posted Jul 19, 2025 14:27 UTC (Sat)
by daenzer (subscriber, #7050)
[Link]
Making the Wayland compositor not advertise any outputs at negative locations to Xwayland, while technically a workaround, should be a much easier solution overall.
Posted Jun 25, 2025 8:38 UTC (Wed)
by patrick_g (subscriber, #44470)
[Link] (6 responses)
How can we be sure it's true? Have you seen that post from Ted Unangst?
Posted Jun 25, 2025 8:48 UTC (Wed)
by pbonzini (subscriber, #60935)
[Link] (5 responses)
Posted Jun 25, 2025 10:06 UTC (Wed)
by smurf (subscriber, #17840)
[Link] (4 responses)
This is a fundamental X11 protocol limitation.
Granted that you could "fix" this by creating a virtual high-res screen that replaces your low-res one, then downscale onto the latter, but (a) the result looks somewhere between ugly and unusable if you want do to Real Work, (b) we're way beyond the point where the heap of hacks and extensions that has been piled onto the original X11 protocol stopped being maintainable in a meaningful way.
Posted Jun 25, 2025 12:37 UTC (Wed)
by dskoll (subscriber, #1630)
[Link] (3 responses)
I have an X11 setup with four monitors, and I can move a window so half of it is on one monitor and the other half on another and it works just fine. Perhaps I am not quite getting what you mean when you write "try a window that spans both screens."
Posted Jun 25, 2025 13:29 UTC (Wed)
by farnz (subscriber, #17727)
[Link] (2 responses)
Under X11, the display is represented as a single large buffer, rectangular sections of which are sent to scanout. Scaling is applied to content as the window content goes from the application's internal representation to the buffer, and this scale factor is the same for all monitors (whether that's the 200 PPI laptop display I'm using as a second screen, or the 150 PPI external monitor I use as my primary display). As a result, I cannot set a scale factor that's right for both monitors - there will always be a discontinuity at the seam, because X11 assumes that something 1,000 pixels high on my laptop screen is visually the same height as something 1,000 pixels high on my external screen, and that's not true (on my laptop screen, that's about 5 inches, on my external screen, it's a bit over 6.6 inches).
Wayland's architecture works differently; the display is considered as-if it's composited from individual windows at scan-out time. The compositor and the application negotiate the window's scaling factor, so the application knows that it's rendering something that's visually meant to be 1,000 abstract units high, but that it's being expected to render (say) a 2,000 pixel high buffer that will be scaled down by the compositor. The compositor can then scale that down to 1,500 pixels on my external monitor (10 inches), and display it at 1:1 on my laptop screen (10 inches), making it look the same on both monitors.
Wayland can also renegotiate the scaling as windows move; so when a window is on my external monitor only, the application can know that it'll be rendering a 1,500 pixel high buffer, which will be rendered as-if it filled 1,000 abstract units of space, while moving that window to my laptop screen gets the same application told to render to a 2,000 pixel high buffer, which will be rendered as-if it filled 1,000 abstract units.
Posted Jun 25, 2025 15:00 UTC (Wed)
by paulj (subscriber, #341)
[Link] (1 responses)
The only time I notice scaling issues now is with xpra to apps running on a server and I havn't set dpi to 48 with xrandr. It doesn't seem to affect any local apps on the HiDPI laptop, but scaling of /1/ particular app (which seems to use some custom toolkit in Java that renders via OpenGL) can be off. Other than, things have been fine for years, with my HiDPI laptop and the monitors I plug into anyway (1 of which is one of those large, v wide Dell ones).
Posted Jun 25, 2025 15:12 UTC (Wed)
by farnz (subscriber, #17727)
[Link]
And I also find that Linux is better at doing the scaling than the monitor is; text is easier to read when the application renders for a 5120x2880 monitor, and then the compositor downscales to 3840x2160, than it is when the application renders for 2560x1440, and the monitor or the compositor upscales to 3840x2160.
Posted Jun 24, 2025 8:16 UTC (Tue)
by pabs (subscriber, #43278)
[Link] (17 responses)
https://blog.gtk.org/2025/02/01/whats-new-in-gtk-winter-2...
So you would need to switch to a Wayland compositor, a way to run Wayland apps on an Xorg server, or a multi-protocol display server like Arcan or Mir.
https://arcan-fe.com/
Posted Jun 24, 2025 10:12 UTC (Tue)
by ebassi (subscriber, #54855)
[Link] (16 responses)
GTK never depended on whatever init system or middleware layer you're using. Only the display server is relevant for, you know, a GUI toolkit.
> GTK intend to drop X11 support with GTK 5:
Dropping the native X11 backend is only ever going to be a problem if Gnumeric is ported to GTK5, which is fairly unlikely to happen within the next 10 years. Gnumeric developers **will** need to port to GTK4 at least, though, because once GTK5 is out, GTK3 will be EOL'ed; nevertheless, GTK4 still has a native X11 backend.
Posted Jun 24, 2025 12:40 UTC (Tue)
by linuxrocks123 (subscriber, #34648)
[Link] (14 responses)
They won't *need* to. It doesn't really matter if your upstream toolkit is EOL. Even GTK+ (GTK1) still compiles and runs and can be packaged for modern distros.
https://mirrors.slackware.com/slackware/slackware64-curre...
Perhaps they *will* stay on the pointless GTK upgrade treadmill, like most Linux GTK software seems to do. But they won't *need* to.
Posted Jun 26, 2025 18:42 UTC (Thu)
by jmalcolm (subscriber, #8876)
[Link] (13 responses)
Probably more than 50% of Linux desktops are Wayland now. It will probably by 80% or more by the end of 2026. When GTK5 ships in 2027 (guess) it will quickly push this number to 90% or more. If Wayland only apps or compositors (like COSMIC) become popular before then, we could hit those percentages sooner.
Of course, all this means is that GTK1 and GTK2 will require Xwayland to run. Xwayland is going to be with us for a long, long time. It is inconceivable that it will not be in RHEL11 for example which pushes it to 2040 at least. No doubt it will be around long, long after that.
I am genuinely curious though how many people will use Xwayland in the future. I have been assuming it would be all of us. However, more and more I am seeing signs that it may actually become fairly niche.
Even if you can run Xwayland, if it is not already installed, it may as well not exist for many users. Apps that need it will simply not run.
Already, we are seeing Wayland compositors appear that do not have Xwayland support. Niri does not as an example. And the Louvre Wayland compositor toolkit only supports Xwayland in rootful mode.
All the toolkits support Wayland now. This means GTK and Qt of course but even stuff like FLTK and wxWidgets. Newer toolkits like Iced are Wayland only as are emerging projects like Cosmoe (BeOS API on Wayland). You do not need to run Xwayland to run any of these apps.
Steam still requires Xwayland (for now) as do Java Swing apps (like JetBrains IDEs and BurpSuite). But it may not be long before 90% of the apps that 90% of users run are Wayland native. Will all those users continue to run an X server in the background that they never use? (Xwayland).
Are most users going to install Xwayland just to pay XBill or run one GTK2 app? Maybe. As I said, until recently I thought everybody would be running Xwayland for the next decade or two. Now I am not so sure.
Posted Jun 27, 2025 6:09 UTC (Fri)
by smurf (subscriber, #17840)
[Link]
None of them will, because these days Xwayland can be auto-started when the first legacy X client wants it.
Posted Jun 27, 2025 8:41 UTC (Fri)
by farnz (subscriber, #17727)
[Link]
All the toolkits support Wayland now. This means GTK and Qt of course but even stuff like FLTK and wxWidgets. Newer toolkits like Iced are Wayland only as are emerging projects like Cosmoe (BeOS API on Wayland). You do not need to run Xwayland to run any of these apps.
Steam still requires Xwayland (for now) as do Java Swing apps (like JetBrains IDEs and BurpSuite). But it may not be long before 90% of the apps that 90% of users run are Wayland native. Will all those users continue to run an X server in the background that they never use? (Xwayland).
First, Niri now supports Xwayland, via xwayland-satellite, as of this commit to Niri, as long as xwayland-satellite has the associated listenfd commits. These will be in the next release as of 2025-06-27.
Second, Xwayland supports socket activation by design - that's what the -listenfd option is for. A Wayland compositor that supports Xwayland but doesn't want to waste resources can open the X11 listening socket, wait for the notification that there's an incoming connection, and spawn Xwayland when an X11 client tries to connect to it; this would let you have Xwayland on your system, not consuming resources (other than storage on your SSD) until you run an X11 client.
And, at least in theory, Xwayland can be terminated when the last X11 client exits, so that running an X11 application doesn't force you to spend the resources on Xwayland until you next log out.
Posted Jun 29, 2025 0:30 UTC (Sun)
by linuxrocks123 (subscriber, #34648)
[Link] (10 responses)
Anyway, GTK1 will still work, as you say, the programs will just run under XWayland.
Here's my personal plan for Wayland, by the way:
Posted Jun 29, 2025 2:40 UTC (Sun)
by pizza (subscriber, #46)
[Link] (6 responses)
"Very popular" according to what objective metric?
...I would be surprised if even 15% of the total "desktop linux" install base is using anything other than GNOME or KDE.
But let's take Debian's limited opt-in popcon stats (about 300K respondents). xfce, kde, gnome, mate, and cinnamon come to about 21%, 21%, 42%, 11%, and 4% respectively. That gives about 59% of Wayland-capable environments. mate will probably be there in its next release.
> Among corporate users, a large percentage of them are probably still on RHEL 7 and therefore very unlikely to be running Wayland.
Given that RHEL7 dropped out of support a literal year ago (June 30, 2024), I'm gonna have to go [citation needed] on this one.
Posted Jun 29, 2025 15:01 UTC (Sun)
by linuxrocks123 (subscriber, #34648)
[Link] (5 responses)
Since all of those desktops also work under X, with those numbers, you'd need about 85% of all desktops that theoretically could be running Wayland to be running it instead of X. That seems unlikely to me.
> Given that RHEL7 dropped out of support a literal year ago (June 30, 2024), I'm gonna have to go [citation needed] on this one.
I've had to use RHEL7 within the last few months. You can buy extended support, and these places do.
Posted Jun 30, 2025 2:18 UTC (Mon)
by pizza (subscriber, #46)
[Link] (4 responses)
You started out using an example of something that didn't support wayland at all (xfce) to support your assertion that most folks weren't using wayland. Now you're moving the goalposts.
Feel free to supply some actual numbers. Otherwise your anectdata is just as worthless as mine. (ie "100% of all linux desktop users I know are running on top of Wayland")
> I've had to use RHEL7 within the last few months. You can buy extended support, and these places do.
"can buy extended support" is not the same as " a large percentage of them are probably still on RHEL 7"
Posted Jul 2, 2025 5:51 UTC (Wed)
by linuxrocks123 (subscriber, #34648)
[Link] (3 responses)
I was using your numbers, from Debian, which back me up? After factoring out the always-non-Wayland desktops, 85% of the remaining desktops, which we don't know are Wayland or X, must be running Wayland in order for over 50% of Linux desktops to be on Wayland. That strains credulity.
But, hey, you want numbers, here are numbers:
https://qa.debian.org/popcon.php?package=wayland
Debian popularity contest points to about 60% X11, 40% Wayland.
> "can buy extended support" is not the same as " a large percentage of them are probably still on RHEL 7"
The extended support is only offered because demand exists, so, yes, that actually does mean there is a lot of RHEL 7 still out there. I've actually personally used RHEL 7 machines recently -- or were they RHEL 6? -- and _NOT_ because I wanted to. I also used Ubuntu 20.04 just yesterday -- and not because I wanted to.
The corporate world really does not like to upgrade their Unix boxes. This has been true for decades and has also been obvious for decades. Or did you think Red Hat was still patching kernel version 2.6.32 in 2024 just for the funzies of it?
Posted Jul 2, 2025 11:21 UTC (Wed)
by pizza (subscriber, #46)
[Link] (2 responses)
You're still moving the goalposts!
You started out claiming that most folks were running in a modern environment that was *incapable* of wayland. I pointed out that this was likely incorrect.
Now you're instead claiming that most folks _aren't_ running wayland. Whether you are correct or not, it's a very different proposition -- of course folks intentionally using old versions of software aren't going to have newer features that come with the newer versions.
(Meanwhile, Debian popcon numbers probably aren't representative of Debian as a whole, nor is it likely representative of the rest of the Linux ecosystem)
> The extended support is only offered because demand exists, so, yes, that actually does mean there is a lot of RHEL 7 still out there. I've actually personally used RHEL 7 machines recently --
Great, more anectdata!
....So, how many of these "lots of RHEL7[+rebuilds] out there" are *desktops* versus servers? IME it was overwhelmingly the latter, even when RHEL was the _current_ release instead of being obsoleted three times over.
Posted Jul 2, 2025 13:21 UTC (Wed)
by jzb (editor, #7867)
[Link]
Posted Jul 2, 2025 13:53 UTC (Wed)
by linuxrocks123 (subscriber, #34648)
[Link]
Posted Jun 29, 2025 3:54 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Wayland support in XFCE is nearly completed: https://wiki.xfce.org/releng/wayland_roadmap
Posted Jun 30, 2025 5:32 UTC (Mon)
by smurf (subscriber, #17840)
[Link] (1 responses)
So you want to run a Wayland compositor with an X11 root window in it and then use 12to11 to X11-ize your Wayland apps.
I'm sure I'll be sorry to have asked, but seriously: what the heck is (or will be) the point of this exercise? All of this cannot possibly work any better than using Wayland directly.
Posted Jun 30, 2025 19:06 UTC (Mon)
by raven667 (subscriber, #5198)
[Link]
<snark>I'm sure the flavor of the pixels have a richness and umami that cannot be described or replicated ;-)</snark>
jokes aside, if they want to run things that way because it makes them happy to do so, then we can just be happy that they are happy even if we don't understand or wouldn't do it that way ourselves, as long as they don't require other users to be harmed by breaking more common workflows to support their personal oddities.
Along those lines I saw a recent project called `wayback` which was for running an X11 desktop on a Wayland graphics output, which might be useful to demonstrate some of the large back catalog of interesting and unique window managers which have been created over the years to new generations of people, and might be useful for cases like this.
Posted Jun 26, 2025 18:51 UTC (Thu)
by jmalcolm (subscriber, #8876)
[Link]
Any wagers on when they move to GTK4 or GTK5?
GTK3 runs native on Wayland. Most users will probably be fine with running GTK3 apps for quite a while.
Posted Jun 26, 2025 10:06 UTC (Thu)
by parametricpoly (subscriber, #143903)
[Link]
Isn't the systemd related stuff only relevant for gdm / gnome-shell sessions? I think you can run individual applications without systemd just fine.
Individual GNOME applications
Individual GNOME applications
Individual GNOME applications
Individual GNOME applications
Individual GNOME applications
Individual GNOME applications
Individual GNOME applications
Individual GNOME applications
Individual GNOME applications
Individual GNOME applications
Individual GNOME applications
https://flak.tedunangst.com/post/forbidden-secrets-of-anc...
Individual GNOME applications
Individual GNOME applications
Individual GNOME applications
If you have different scale factors for each screen, so that windows appear the same size as they cross the boundary even though the screens have different native PPI, you'll see the issue on X11, but not Wayland. You won't see this with 4 monitors of same diagonal size and resolution.
Individual GNOME applications
Individual GNOME applications
Well, depends on the display and the attachment method; my external monitor flickers wildly at any resolutions other than CEA-861 predefined resolutions (and I've not bothered to work out why - there's a firmware update available, but I'd have to get a Windows machine sorted to apply it). No trouble at 640x480, 2880x576, 1280x720 or 3840x2160, but huge trouble at 2560x1440@60Hz. I therefore need Linux to do the scaling, because the scale I'm asking for would need the monitor to run at 2560x1440.
Individual GNOME applications
Individual GNOME applications
https://mir-server.io/
Individual GNOME applications
Individual GNOME applications
Individual GNOME applications
Individual GNOME applications
Individual GNOME applications
Already, we are seeing Wayland compositors appear that do not have Xwayland support. Niri does not as an example. And the Louvre Wayland compositor toolkit only supports Xwayland in rootful mode.
Individual GNOME applications
1. On the hardware side, run XOrg until it breaks, then run XLibre until it breaks, then run a Wayland compositor with a single rootful XWayland instance taking up the entire screen.
2. On the software side, use the X11 versions of programs until they stop being released because the toolkits dropped support, then use 12to11 to run programs that won't run directly under X11 anymore.
3. Proceed to ignore Wayland forever.
Individual GNOME applications
Individual GNOME applications
Individual GNOME applications
Individual GNOME applications
https://qa.debian.org/popcon.php?package=libx11
Individual GNOME applications
Individual GNOME applications
Individual GNOME applications
Individual GNOME applications
Individual GNOME applications
Individual GNOME applications
Individual GNOME applications
Individual GNOME applications