Xfce, the "Just Works" of Linux desktop environments not only the DE itself but also its suite of apps like Thunar.
They recently moved to gtk4 (or are planning to?). I wonder what would be the difference between gtk3 and gtk4 apps in terms of latency and performance.
Think of it as the product of the new generation of techies who had their first contact with computers after Mac OSX was released, and now all they can/want to do is emulate Apple and their HIG.
I'd be inclined to agree with you, but it's hard to me to believe that all these kids went to college (or got some type of computer training) only by working with their phones/tablets.
It's not that they only use their phones/tablets, it's that the phone/tablet is the first tool they reach for, the default device, and UI conventions from that space feel correct and natural to them, just as they feel clumsy and jarring to me. (How old am I? Old enough that I still use an opto-mechnical mouse with a ball, because I still like the extra weight and inertia it has over a pure optical mouse!)
GNOME is primarily about making Free Software that is highly accessible. The desktop and GTK toolkit both predate OSX, so I'm not really sure what the purpose of the comparison is.
This criticism is for the more recent versions of GTK.
Killing theming and removing features when they do not have a serviceable usable alternative does not make it more "accessible", it is just the standard "we know it better because we study the behavior of a large group of users" excuse that they give to treat it everyone by the lowest common denominator - just like Apple.
Yeah, that much I generally agree with. Many of the 'opinionated' decisions that came with GTK4 are either regressions or strange and inflexible.
That being said, I will shamefully echo the words of the GNOME maintainers; their goal was not to "kill theming". They wanted to stop distros from shipping themes by default, which was arguably just as deranged but at least somewhat understandable. Nowadays we have stuff like Gradience too, which lets you theme LibAdwaita apps. You're still forced to use the ugly old Adwaita buttons, though.
So... make of it as you will. I left GNOME completely after the GNOME 40 update, I sympathize with people who hate the current desktop. The toolkit itself is "fine" in my unprofessional developer opinion.
I didn't know people used xfce as their main desktop, I had only experienced it because it's easy and resource light to set up for VNC. It's cool to see people singing its praises. It was always definitely adequate for my 'remote development with desktop GUI' needs.
Funny how with anything on the internet there's always Ayes and Nays. It's almost hilarious to me about humans that "the market always segments" into all these trivial seeming (but decidedly important if you have skin in the game) choices.
I'm not questioning at all the importance of UI and UX in any way. It's fundamental. These visual virtual environments are the primary tools we humans use every day for our information manipulation snow-shoveling knowledge work. They have to be refined and have exquisite ergonomics tailored to our every whim. That's undeniable and it's not surprising at all that people have strong preferences.
I just think it's funny that people can't seem to agree, on anything. The market always segments.
Example from my business: we build a remote browser that has a kind of real time streaming optimized for adapting many bandwidth conditions to reduce lag (which often occurs by trading away raw framerate). For some people (normally the security conscious crowd), this is perfect. For other people (the app virtualization crowd) this is terrible: they want silky smooth high framerate remote streaming. I suppose people get could lectures about trade-offs, but it really is a kind of enjoyable thing: there's always something to work on.
An advantage of being open source is people can tweak it to their needs as much as they want. There's no bottlenecks in the system besides what you want to do, and how much compute and bandwidth you can throw at it. It can be as fast and smooth, or as resource efficient and minimal as you want.
> I didn't know people used xfce as their main desktop
Hahaha, really? It's been my desktop since I started using Linux in the 2000s. It's great! It presents windows, has a small set of high quality built in applications (file browser, application launcher, etc), has a big and flexible set of keyboard shortcuts, and other than that, it just gets out of your way.
Other DEs like to shove themselves in your way -- put your mouse in the corner of the screen? Something shows up! Hit a wrong keyboard button? Something shows up! Open the application launcher? It's fullscreen, baby! Do something to a window? Here's some jiggly wiggly animations!
XFCE just does what it needs to do, quietly, with no fuss. It's fantastic.
> I just think it's funny that people can't seem to agree, on anything. The market always segments.
I have it running very nicely on an ASRock 4x4 R1000M, which is a fairly cheap NUC-ish sized box with a Ryzen R1606G - 2c4t, from 26 to 3.5GHz. Decent 4K desktop graphics via amdgpu.
When I was all about the bling in the late 90s, I used Enlightenment. When I wanted to get stuff done, I used KDE. XFCE bored me. Flash forward to 2020, when I wanted to get stuff done AND have a nice tiling window experience, it was i3+XFCE all the way. Something about having nice stability without huge RAM-guzzling (and battery depleting) processes, just makes life more pleasant.
I use xfce as my main desktop. It is lightweight, functional, familiar, and it gets the job done.
At one point in time I used it because I couldn't afford a decent computer and XFCE used fewer resources (so my slow computer would be a little more responsive). Eventually I went back to it because it was familiar and it gets the job done.
XFCE is frankly the last full featured Desktop Environment, truly focusing on responsiveness and zero-lag SGI-style: https://www.youtube.com/watch?v=9EEY87HAHzk&pp=ygUbc2lsaWNvb...
MacOS X, Windows and the mainstream Linux DEs have nice animations, but it is fun watching them the first day. After that it is just annoying.
Really hope that Wayland integration works well for them.
Cinnamon is also in this ballpark. Each have their strengths and weaknesses but both are awesome.
Both are pretty dumb when it comes to Hi-DPI support although Cinnamon does an acceptable job at staying coherent when configured with bigger fonts so it’s a workaround. XFCE manages bigger fonts very badly so I have big hopes that real Hi-DPI support will be better with wayland.
You tell me. My biggest pain with XFCE is multi-monitor support. Like having the menu bar also on the second display and not have two of them when you switch back to single-monitor.
As long as the animations are done right (subtle and short) they make the experience feel smoother without slowing you down or annoying you. At least that’s my experience, it’s probably not the same for everyone
Not an XFCE user (I'm comfortably satisfied with the simplicity that is Gnome) but I'm very happy to see XFCE's concrete plans to move towards Wayland!
I've been using Xubuntu for years - it just works, with no clutter. Absolutely my only complaint are the very thin window borders - this is a setting you cannot individually adjust. However, one quickly gets used to (alt + right-click + drag).
Alt+space brings up the window menu. Press R to resize, or M to move the window with either the arrow keys or by moving the mouse pointer. Finalize with Enter, cancel with Escape.
Can you resize a window with only the arrow keys? For example hit r+up and raise the upper border upward, then s+left, and shrink the window by moving the right border leftward, or something like that?
Yes. After pressing Alt+space then R, the first pressing of an arrow key selects the border you want to move, let's say the left. You can then move that with the left/right arrows. If you press up or down in this state, it will, again, select the corresponding border to work on.
XFWM themes support different thicknesses for the window with focus vs those without. In my custom theme, the focus window get a thick accent-colored border all around, and non-focus get a 3 pixel black/white/black border that guarantees a visible separation without drawing much attention.
How amusing, the thinnest possible window borders and using Alt+drag is a feature I desire and intentionally wrote myself:
https://github.com/superjamie/onepx
Sort of. The foundational issue here is the longstanding premise "Wayland can replace X!". The problem is that Wayland can't replace X, only Wayland plus a bunch of other components - or as I like to call it, Wayland++.
So Wayland++ can provide network transparency, but whenever a W++ feature has issues and those issues are criticized, Wayland advocates will just motte-and-bailey the issue by saying "but that's not part of Wayland!", which is technically true but irrelevant. "Wayland" can mean Wayland++ or just Wayland-core, depending on what's convenient.
Wayland proper is a protocol specification. By it itself, it's completely inert and it's all up to an implementation.
The protocol uses shared memory buffers and file descriptors, so it can't be just transported through TCP as-is. You need something like waypipe, which parses part of the protocol, extracts things like file descriptors that won't make sense on the other end, and then reconstructs things on the destination.
waypipe turns out not to be that complicated, it's just 15K lines of code.
>Wayland proper is a protocol specification. By it itself, it's completely inert and it's all up to an implementation.
Wayland should have shipped with a default implementation that had screen sharing, recording, clipboard and everything else that x11 had by default. The fact that they've thrown all that responsibility on DEs without so much as a HOWTO on how to reach parity is ridiculous. I will never understand why anyone took their effort seriously.
> The fact that they've thrown all that responsibility on DEs without so much as a HOWTO on how to reach parity is ridiculous.
Well, all DEs (excepting maybe Xfce?) have members in the work groups that design the wayland protocol extensions, so it can be assumed that people are well aware of what needs to be done.
Wayland has a default implementation called Weston, but I'm not sure that any of its devs cared enough to implement the extensions which are responsible for all the other bits that you mentioned.
most software which did support network transparency in a way similar to what X11 started out with has giving up on it (like in the industry as a whole) and there seems to be a clear technical consensus that it's best to not to approach remote access this way, even in X11 it was kind of semi-abandoned long before X11 was semi abandoned (from developers not from people using it)
As far as I can tell from the POV of the discussion of weather Wayland (or any other hypothetical replacement) needs to support it the answer always had been a clear "no it doesn't need to, nor should it try to".
This doesn't mean that you can't have remote shared applications, desktops, screen sharing or similar just not using network transparency. I.e. not by pretending the things the application communicates with (compositor, GPU, etc.) are on the same computer and "transparently" routing (part of) them to a different computer. And if you consider the stark difference in latency, reliability and throughput between a Unix pipe/speaking to a GPU over PCIe and TCP over Ethernet it can feel surprising that it was ever considered to be a good idea (but then when X11 was build network transparency was just that big think people put into everything, from most of which it is removed by now).
So what replaces network transparency (and did replace it in many cases long before Wayland was relevant) is typical remote desktop functionality. I.e. and additional application will grab the mouse/keyboard input on one side and the rendered output on the other side and sends them to each other. This has many benefits both for the people not using it and the people using it while many of the drawbacks often practically do not make much of a difference anymore. The main issue is if there is a high quality open source for free program you can use and if it's installed on the system where you want to use it...
A server in a datacenter generally doesn’t have a GPU, certainly not enough to support thousands of clients (each of which does have a GPU plugged right into one user’s monitor). Software rendering is a regression that didn’t need to happen, and Javascript apps seem to be the way the industry is avoiding it (with the browser as a remote display server).
Sometimes because you want users to be able to change workstations, sometimes because you want a highly specific environment outside of the user's control (it can reset on each connection), sometimes because you want nothing to be kept locally. Eg, the country somebody works in is untrustworthy, so they access everything somewhere remote and safe.
virtual desktops on demand tends to be run on servers with GPUs and in general prefers server side GPU rendering because it's meant to work with any client which can access it even if it's has an extremely weak GPU
and if you have no complex rendering requirements then often it's a much better choice to place the network gap in the GUI toolkit instead of the DM as this tends to work way better, in this case you do need a thin client on the other side, but so do you need for X11 remote (the client needs to run X11) so it's kinda not that difference. And today the easiest way to ship thin clients happens to be JS/WebGPU, which is how we have stuff like GTKs webrender backend.
> Software rendering is a regression that didn’t need to happen
Actually, it is. The actual straw that broke the X developers was font metrics, IIRC. Essentially, if you want to support fonts for the language of the most populous country on Earth, you need to do more or less complete font rendering to answer questions like "how long is this span of text going to be" (so that you can break it). And the X developers tried to make it work with the X model, but the only way they could get it to work well was to have the X server ship the font to the X client and the X client ships rendered bits back to the X server [even over the network!].
this use case is broken in X11 since a very long time, because to make this work well you don't just need some form of network transparency in the network manager but also remote rendering for OpenGL and Vulcan
> Software rendering is a regression t
But in most cases it's not happening, because you don't render on the server for most applications you render on a client which interacts with a server.
> and Javascript apps seem to be the way the industry is avoiding it (with the browser as a remote display server).
Today many JS apps are not thin clients they are often quite complete applications, but lets ignore that for a moment.
I'm not sure what exactly you are imagining, but as far as I can tell the only way to make this kind of remote rendering you are implying work in general would be by making X11 a GUI toolkit with some form of cross OS stable interface and it also would be the only supported GUI toolkit and any fancy GPU rendering (e.g. games) would fundamentally not work. There is just no way this would ever have worked.
The reason the industry mostly abandoned network transparency not just for remote display servers but also in most other places is because it's just not working well in practice. Even many of the places which do still use network transparency (e.g. network file systems) dent to run into unexpected issues due software happen to not work well with the changed reliability/latency/throughput characteristics this introduces.
Someone mentioned waypipe which I don't know but which seems to be the way to go if one can use it (it does seem to require installing waypipe on the server).
In any case ssh -X still works fine out of the box, using which transparently uses XWayland behind the scene.
It has limitations compared to native Wayland like good support for multi screen with different DPIs, but the same limitations will be found in a native X11 session anyway.
So Wayland is at least not a downgrade on this topic. It's been handled well.
It still has abysmal performance (and many other issues), though. I've been using Xpra for a while now, to at least let programs survive if my connection is interrupted. Makes it possible to work from a train or conference Wi-Fi.
waypipe has good performance, but IIRC it suffers from the same disconnection issue. Hopefully recent work from KDE on surviving a compositor restart means that restarting a waypipe session will be possible, or even juste deciding to forward a program after starting it (which wouldn't be possible with X).
One could also imagine exposing a window to both local and remote compositors (could be implemented in waypipe), with simultaneous access leveraging Wayland multiseat. "Multiplayer" compositing.
Forwarding after starting program or disconnecting would be entirely possible with X if toolkits supported it. I wrote a tool once which this for my own work.
I also use ssh -X a lot from home to work and performance is sufficient. Xpra shows that it could also work over low latency links if you have latency hiding which the X supports but because it is asynchronous but - again - toolkits never bothered. Fixing these issues would be a million times more useful than redeveloping everything from scratch.
> Forwarding after starting program or disconnecting would be entirely possible with X if toolkits supported it.
Sure, in that case you could even switch back-ends and have your toolkit interrupt its connection with X and start talking with GBM/DRM, Wayland, or another X server. However, the required changes would likely be invasive. I get your point though, this is relatively similar to Wayland programs surviving compositor restarts. However, you would need to start tracking all the state that the X server tracks, to replay it later. Not impossible, but quite hard to bottle on existing implementations, I think.
> Fixing these issues would be a million times more useful than redeveloping everything from scratch
That's your opinion. In my opinion, Wayland does a lot of things right; the main one being a specification that everyone can implement. That makes it much easier to start from scratch to implement an innovative feature in a proof-of-concept toy compositor or program. We've seen a lot of these projects, and consolidation takes time. Once proven, features tend to trickle down to general purpose compositors.
I am really satisfied with the tools Wayland has given us, from gamescope to nested compositors, better isolation, better-behaved clients (no more clients that refuse to go fullscreen, etc), a very stable experience with few crashes (compared to misbehaving clients taking down the X server with them), easy multiseat, no more tearing, no more xorg.conf, better client isolation (notably remote apps cannot spy on locally-running apps), pipewire-based screensharing, choose-your-own-compositor-features approach (granted, not for everyone; but those uncomfotable can stick with KDE or GNOME).
The future seems promising, mostly thanks to wlr protocols, especially wlr-layer-shell that should allow running UI elements from a DE on other compatible compositors (I can't wait to use xfce4-panel on sway starting from their next release[1]).
> I also use ssh -X a lot from home to work and performance is sufficient
Personally, I ran into issues with Cadence, even on a LAN: that software uses some X toolkit, and some very long lists (scrollable form-like dialog) took dozen of seconds to display; I also had various font issues, issues with software moving my mouse (I hate this), performance issues with complex drawings. Most of these disappeared when running through Xpra. Not to mention losing my work because of small internet cuts, putting my computer to sleep, or having the ssh connection interrupted somehow (ssh has trouble with roaming, connecting over wireguard helps with that).
> Xpra shows that it could also work over low latency links if you have latency hiding which the X supports but because it is asynchronous but - again - toolkits never bothered
This is getting too technical, I don't think I'm qualified to discuss this. Though don't you mean high latency links? Xpra is basically a local X server that sends data with a protocol similar to VNC. It is quite similar to how Waypipe handles things. I may be wrong on this, but I think RDP may combine the best of both worlds? Dumb "vnc-like" connection by default, and make use of optimized implementations in the toolkits when available.
>> Xpra shows that it could also work over low latency links if you have latency hiding which the X supports but because it is asynchronous but - again - toolkits never bothered
>This is getting too technical, I don't think I'm qualified to discuss this. Though don't you mean high latency links?
Yes, of course.
>Xpra is basically a local X server that sends data with a protocol similar to VNC. It is quite similar to how Waypipe handles things. I may be wrong on this, but I think RDP may combine the best of both worlds? Dumb "vnc-like" connection by default, and make use of optimized implementations in the toolkits when available.
I do not think you will every get good client integration as good as X with dumb protocols and my experience with RDP was always relatively poor. Xpra uses its own protocol between two proxys but supports good integration so is different to a stupid screen scraping approach, but I think it could just work by doing the latency handling on the client and speaking directly to a remote X server using X. The reason that I believe that would be possible is that X is a very flexible remote buffer handling protocol. So caching of some image content and copying it around could all be done remotely controlled by the client. I started to implement something like this but then did not have time... But the flexibility and extend-ability of X is also the reason I think that throwing it away is completely unnecessary.
I used to use XFCE (specifically XUbuntu), but found that its handling of hi-dpi displays on laptops etc. wasn't very good, so switched to Plasma/KDE which seems to work better. Still have issues with certain flatpak apps not scaling properly though.
If scaling is off, there's a good chance the application is using GTK. GTK4 doesn't support fractional scaling but I believe GTK5 might.
If applications are written in GTK2/3/4, fractional scaling won't work well and lead to blurry windows.
Integer scaling (1x, 2x, 4x) should work just fine, but fractional scaling isn't implemented consistently across GUI frameworks. Hopefully Wayland will fix the inconsistencies between implementations, though GTK and some other GUI frameworks will likely remain broken for a while.
The constant GTK rewrites are a disaster. Why should applications even bother starting with GTK(n) if it will be obsolete and incompatible when GTK(n+1) comes around?
You're exaggerating. GTK2 came out in 2002, GTK3 in 2011 and GTK4 in 2020. That' s almost a decade for each version, and you have to consider that GTK2 was maintained for a long time after 3's release and that current Linux distros still package it. And the GTK3 to 4 transition required some changes, but far from a rewrite.
If you need multi-decade support from your GUI layer, I can recommend raw Win32 or VT100 terminal codes. There's hardly any other API with that kind of backwards compatibility.
That's assuming downstream is even still around to adopt the new version. There are plenty of simpler tools which are "done" - itch scratched - and the author has long since moved onto new things. Duct-taping the bitrot inflicted by toolkit churn is something that requires resources - if nothing else it consumes time and energy that people could otherwise be spending on current interests and projects. That's where the "open-source means everything's free" mindset can be a problem, since it's just assumed the authors will step up and do work made necessary by the decisions of others, with no remuneration or consideration.
I meant OpenMotif as pjmlp mentioned. These days it seems to mainly receive patches to keep it working but it maintained API (and ABI where possible) compatibility even when it was more actively developed as it was a design choice, not a byproduct of not receiving updates. AFAIK it is how Lesstif managed to be a (mostly) drop-in binary compatible alternative to Motif before the latter became open source.
Multi-decade support should be the norm for GUI toolkits. Why should all GUI apps of the world have to be rewritten every decade? That’s just a wasteful use of developer resources, and also a wasteful disruption of end user habituation.
Because requirements change and you can't keep API's sane when only bolting on new functionality.
You can disagree about the support timeframe, but in 10-15 years time we've gotten used to high resolution screens, HDR, HFR, multitouch etc. If you don't ever change API's you're leaving a lot of potential on the table.
Windows added all those functions without breaking compatibility. Yes, applications might have to be modified to take advantage of new features that make sense for the application in question, but that doesn’t imply that they should have to switch toolkits.
While Windows doesn’t provide a unified GUI toolkit, win32 UI controls of different generations can be mixed freely within an application, enabling gradual upgrades.
Windows is a paid operating system with thousands of developers working on it. GTK has 3 regular developers. Please step up if you're going to complain.
Meanwhile a Windows application compiled 25 years ago still runs today. A Windows application compiled 30 years ago runs with a very small compatibility shim you can ship with it as a DLL.
My xv copy has a mtime of Aug 4 1998 (pre-compiled binary from the RPM on the website). It runs on my current Void Linux system. Not GTK, but that's a detail: point is it runs, and is 25 years old. I've also run old Opera copies from the 90s, although that's longer ago and I'm not sure if that still works.
Having discussed this issue with friends at Microsoft, they apparently spend astronomical amounts of time, money, and effort to maintain backwards compatibility while still adding new capabilities, functionality, and toolkits. They know that this is a key reason many organizations rely on Windows.
I have no specific insight into decision-making in open source organizations, but given that the resources they're working with are several orders of magnitude less it's not surprising to me that they sometimes end up having to choose between stability and new functionality. (While I personally prefer projects towards one end of that spectrum, I'm happy that different projects have different values for other people.)
A big part of it is the ecosystem is mostly/almost entirely open-source, so in theory you can update all your applications to use the new API. So breaking changes are not as big a deal in that world, as they are on Windows where you definitely do not have that option due do the primacy of closed-source software. I think this view is short-sighted, though. If there are 100 users of a given library, then it takes 100x more effort to update all the applications than for the 1 library developer to avoid making breaking changes.
>There's hardly any other API with that kind of backwards compatibility.
Qt? 99.99% of the API from Qt 4 (2005) is identical in Qt 6 (ongoing). A few headers were renamed, and a few minor functions, generally stuff you can port in 1 day.
When they released Qt 5 and 6 and decided to switch from Qt Widgets to a new GUI toolkit (QML), they didn't say "umm, just rewrite your whole codebase in QML bro", they kept widgets around in perpetual maintenance mode. This is how you respect your users.
I think what Qt does is a good compromise, but there are breaking changes. Complex FLOSS projects spent months or years upgrading from Qt4 to Qt5 and then to Qt6. The exact timeframe is a matter of priorities and available developers, but someone had to put a not insignificant amount of work into porting. A far cry from decades-long ABI compatibility.
There are going to be apps that only run on x11 for a long time and will need to use xwayland, so it's unlikely that linux distributions will stop distributing x11 libraries entirely.
However, development of xorg is completely dead so it is pretty likely that distributions will stop support running xorg sessions in the future, and at some point xorg will likely not run on new graphics cards anymore.
KDE has announced plans to discontinue support for running x11 sessions and only runs on wayland in the upcoming plasma 6 version.
For now all the gui toolkits will presumably continue to support x11, but at some point, it is likely that new applications will only care about supporting wayland, and after that, it is possible that future versions of gui toolkits will stop supporting x11.
Maybe "ripping out working code" is a bad thing, but at a certain point people would have to put in extra effort to ensure that x11 stays "working" and if nobody steps up to put in that effort and x11 support breaks, it won't be ripping out "working" code anymore.
It's weird the certainty with which people say "wayland is the future" when that's not how free software works; nobody knows what "the future" is because it depends largely on volunteer labor (even if some FDo devs are paid, the packagers aren't for the most part and that's who actually gets the software to users).
Xorg, possibly, but Xenocara is an X11 implementation that is currently maintained and regularly updated. The OpenBSD team says it's largely feature-complete so there won't be new big changes, but it's getting regular commits. OpenBSD is a small userbase but it's important enough in security circles that I have trouble imagining toolkit implementors will drop support simply because some people have a weird need to delete working software.
Work has already begun to get Wayland working on OpenBSD. With the major toolkit and DE projects removing X support in upcoming releases, even Xenocara's long-term relevance is very much in doubt.
Not really. Matthieu's done some work to almost get it usable, but if there's been any talk of ever taking it out of ports and into the base system it hasn't happened on any public mailing lists. Given that xenocara is rootless and pledged there's not really a security argument for it, and there just isn't that much interest from the team, at least not that they've expressed. Also OpenBSD doesn't have Linux's weird insistence that a process somehow can't find out who owns a display, which makes a lot of Wayland's model kind of pointless on the platform.
I suppose OpenBSD might not ever have a GTK5 desktop if GTK5 for whatever reason drops X11 as a target (remember they still support DirectFB) but I don't think that's really a showstopper since users seem to prefer cwm anyways.
The X code path has to be maintained as the toolkit evolves. X is old, bletcherous code written for graphics hardware of the 80s and 90s. It's holding modern apps back. No one working on modern apps wants to maintain anything having to do with X.
And network stacks would be simpler if they took out token ring support, too, and that doesn't happen either. An interface once shipped is basically frozen whether people like it or not. The toolkits still support DirectFB, even if it's not built by default.
The first one works fine with Gtk 3 and newer; the application renders its output at nearest higher integer scale, and then the compositor downscales it to requested fractional scale (i.e. app renders at 200% and compositor downscales it to 175%). Apple does exactly this same thing (just with slightly different scales; they won't show you nice 150% or 175% for a reason; they optimize for different thing).
The second one is rendering at fractional scales directly by the application; then the compositor doesn't downscale anything, just displays the buffer as it is (i.e. app renders at 175% and compositor displays it as it is). Since rendering at fractional scales is more demanding (just think about fractional mouse coordinates or how to display 1px straight line and don't get lost in the rounding errors), it took longer to materialize. It is this support that will have to wait for Gtk 5.
But meanwhile, your (Gtk) apps will be displayed at fractional sizes using the first method.
On Wayland, GTK3/4 windows work well with fractional scaling (on GNOME). They are rendered at 200% and then downscaled by the compositor, which looks mostly fine.
Blurryness is often caused by GTK2/old Qt5/Electron applications that don't support Wayland and are rendered using XWayland at 100% and then upscaled by the compositor.
There is a new wayland extension, that allows for rendering at fractional scales directly in the application, so when you use a display with fractional scaling, there is no downscaling done by the compositor.
Support for this kind of rendering is going to wait until Gtk 5 -- implementing it in Gtk 4 would break ABI, and then the world would have to listen to cries about Yet Another Breakage. The current system, rendering at integer scale and then compositor-downscale is working fine since Gtk 3. Btw, exactly this way is how Apple does it, and it was lauded as a great way to support scaling.
I also believe this is only the case for Wayland, so X11 users may be out of luck here. Actual fractional support would require breaking API compatibility, which is why integer scaling+downscaling is necessary.
200% scaling looks bad depending on the size of the screen. I have a 27" screen, and 175% is much better, but you cannot do it on Linux (last I checked...)
I tried Plasma many times (just briefly installed a distro like Kubuntu), and while very complete, I find it "lifeless". Is purely a graphical sensation. Is like it has no life, compared to Mint with either Cinnamon or Gnome. I don't know how to better explain it.
I imagine that it is by design. For me, I prefer a more "lifelike" experience, with shadows, curves, etc. But I was wondering if there was a way (theme) to make it so for KDE, as I really like the tech.
There are lots of themes for KDE, but installing them can be a little messy. Unlike Gnome where it’s all handled through the dconf program, there’s some manual setup involved with KDE - config files, replacing icons in different directories, etc. For example, here’s a step-by-step guide to installing a beautiful KDE Nord theme, which turns into a bit of a PITA:
Personally, I just want a desktop environment to get out of my way as much as possible, which is why I liked XFCE. If I notice it, then it's usually doing something annoying like a file manager checking if some remote mounted directory is working, despite me not wanting to use that directory.
I use KDE now but I agree. It very blandly utilitarian. Bland gradients of bland greys and bland blues. Even Windows 95 had more personality with its saturated red-grey and bold colours.
KDE does not spark joy, but then again, most devs and most users have no real artistic sensibility to speak of. Have you ever looked at a random person's desktop? So I don't give weight to anybody that says "it looks good to me."
That said, I am now on KDE after a decade of GNOME because I need some of its configurability, and GNOME is starting to become too opinionated even for me, even though they have a slightly better design team not afraid of colours with more than 20% saturation.
This is not a solved problem until they support DMA-BUF import (i.e on laptops with iGPU and Nvidia GPU, your external monitor connected to Nvidia will be very sluggish as the compositor will have to copy the framebuffer - rendered on the iGPU - to nvidia GPU using CPU instead of directly importing it to Nvidia GPU using DMA-BUF)
This doesn't add DMA-BUF import but it does mitigate the issue for the use case of many dGPU/iGPU laptops when an external monitor is used (independent of weather they are Nvidia laptops):
I have not opened the ticket. I though I should understand bit more. Is it a bug/feature-request to be opened (Sharing clipboard with guest VM)?
How it should be handled? any thoughts?
Only GNOME supports clipboard sharing with guests, because GNOME unifies X11 and Wayland clipboards in the compositor. None of the other Wayland DEs are supporting it since it requires special handling in their respective compositors.
I've been using XFCE for the last 15 years. Before that it was vtwm, fvwm, afterstep, but I could never get into GNOME or KDE. XFCE just does everything I need and I don't see any reason to switch.
I really love XFCE. I used it on and off on low-resource machines since the late 00s, and then moved to it for my main desktop when the Gnome3 thing happened. I've never looked back (though I'll admit I'm also a macbook user!).
What do I like? It's never forced me to change the way I work. That's up to me.
So if Wayland is the future, then I look forward to using XFCE on Wayland somewhere down the line too.
By far the best thing with XFCE is that it does not change, it merely improves. Other DEs and applications radically change the UI between releases.
I have my XFCE desktop working as I want now and I don't want to change it or having to learn where buttons are located after an update. With Gnome and Windows I feel like a lab rat for their UI experiments.
But Gnome did only a revolution once and since then it is the same.
I personnally totally saw it as a different project as gnome 2 didn't become obsolete immediately and Mate&Cinnamon forks took over so quickly for those looking for a gnome classic evolution that no one was really forced into using gnome 3.
> I personnally totally saw it as a different project as gnome 2 didn't become obsolete immediately
Yeah it did. They announced gnome 3 and deprecated 2 on the same day, and seemed to have made the deliberate choice to not allow them to coexist. As soon as your distro moved, bam, you were done.
> Mate&Cinnamon forks took over so quickly
After some months. This stuff was not there on day 1.
In the mean time, those of us who did not want to work the way Gnome 3 decided we should, had to find an alternative. And when we found a good one (Xfce for me), we stuck with it.
GNOME makes often changes without long term strategy or asking their actual users. The removal of Type-Ahead-Find in Nautilus or background-transparency in GNOME-Terminal where mistakes. On the other hand new applications like Documents or Console required resources but provide no benefit over it counterparts. That said - Nautilus improved a lot in recent years and there are even patches available for Type-Ahead-Find (or Navigation). Same for background-transparency in the GNOME-Terminal. The separated top-bar-menus were also a problem (decoupling menus from application-windows was copied from Apple) but now reverted, they learn.
If the design team is aware of the usage and has a plan things fit well! The overview is great for keyboard and mouse users, the dash make simple things simple, they got rid of the useless desktop-metapher (copied from Win95) and also the system-tray (another thing from Win95). The keyboard focused use of GNOME is use core-feature, fast for experienced users and a relieve for novice users. The GNOME-Shell provided a good UI and removed many questionable ideas of the past.
Wishlist?
Decouple the release cycle of most applications from GNOME, excepting Nautilus and Settings. There is no need to couple Epiphany, Terminal, Maps, Calendar and so. Evolution already skips every second release. And feature-removal should require a good reasoning and not just „I don’t need that myself“. Many options are bewildering, many forks without merges are worse (lost developers and lost users).
My biggest gripe with gnome is how dependent each individual app is on installing the whole gnome-shell packages, want to use their email app without using gnome as a DE, well too bad Gmail/office and all other kind of providers won't work.
More like wannabe Windows philosophy, at least in the early days. Their founding document was called "Let's Make Unix Not Suck" and was all about how the Linux desktop should be architected like Windows, COM components and all.
I'd argue that is more a symptom of applying the UNIX philosophy, if anything. A lot of those "hundred KDE packages" are very tiny, highly modular libraries that do "one thing". And no, the apps don't depend on the shell. In fact it's often the distros asking us to go a bit more monolithic again to ease the packaging overhead.
Those packages are separate because the system is modular. I assure you, it's more difficult for the team to do it like this, and in many ways it's a welcome feature. The package number might seem insane, but compare the aggregate size of them vs other DEs. It's still not a fair comparison, but it's arguably better than the number of packages.
Either way, many package managers provide groups or patterns to make it easier for an end user to maintain their system. Pacman does have such a feature.
Look, for example, do you prefer to be able to install SDDM just because you like the themeing capabilities, and be able to do so, with just the bare minimum packages; or, install GDM and having to pull the whole GNOME DE as a requirement?
It's purpose is to provide and manage account information for applications that need it, so the user doesn't have to configure their email, calendar, whatever, in each application separately. With each application storing passwords in a who knows where, or each implementing their Gmail OAuth.
So it is quite logical, that application that uses accounts will also need gnome-online-accounts.
'Do one thing and do it well` -- how is that anti Unix philosophy?
Keyring is another component, specifically for passwords.
GOA is for storing account information: e.g. you configure your Gmail/nextcloud/whatever account once, and then all apps that need it can access it. So your Geary, Contacts and Calendar (separate applications) do not need each to implement account management and account specific auth flows -- not just passwords, OAuth is all the rage nowadays. And I, as the user, do not have to keep tokens in each app current.
It is also not 'entire gnome shell`. Just the required components.
sure but to setup gnome online accounts the official documented way you need gome-control-center, other ways to do seems to not have official documentation and have failed me.
here the required dependency list for control center on arch:
accountsservice bolt colord-gtk4 cups-pk-helper gcr gnome-bluetooth-3.0
gnome-color-manager gnome-desktop-4 gnome-online-accounts
gnome-settings-daemon gnome-shell gsettings-desktop-schemas gsound gtk4
libadwaita libgnomekbd libgtop libgudev libibus libmalcontent libmm-glib
libnma-gtk4 libpwquality smbclient sound-theme-freedesktop udisks2 upower
while it may follow the letter of the philosophy is certainly doesn't feel like it's following the intent of it. the components form a sort of cyclic graph, where technically you can install any component but soon you'll find that you need all the others with no viable alternative component that will work reasonably well.
using these component outside of the DE feel like being a second class citizen that will be kicked out at any update, and then you'll have to scavenge for information from unofficial sources and the source code for what has changed that broke your setup.
Isn’t that a gripe about the individual applications?
Applications which are part of GNOME itself probably try to remain small and integrate well into GNOME e.g. Nautilus and Evolution. Applications which aren’t part of GNOME like Gimp or Geeqie rely only Gtk.
It just hurts if you want use a integrated GNOME-Application with a sole window-manager. That makes sense and we shouldn’t blame the developers for modularity and re-using.
I for one love Gnome and have seen nothing but a steady stream of improvements since 3.0. Sure 3.0 was a shock, but they stuck to it, and perfected their vision. And now it’s just a joy to use. If that’s not long term plans/vision idk what is.
I don’t know about Type-Ahead-Find in Nautilus, but typing to search in the file choosers is comically bad.
“Comically bad” here goes slightly beyond not working right to mildly destructive. I don’t know how the software pulls it off, but trying to open a folder found by Tracker search shows a nonsensical UI (no, I don’t want to “replace” the folder) and sometimes removes the x bit from the folder mode. I don’t even know how. A random chmod(2) call deep in glib? Why would the file chooser ever use chmod or fchmod?
> Gnome kept a way to have a more classic behavior.
Not really, even with Plugins everything is handled by Mutter - you don't have the modularity of Gnome 2 where you can switch out the panel, file browser or window manager as you please.
Fortunately Mate forked Gnome 2 to retain the old desktop.
MATE is my preferred environment, but is it even viable anymore?
Despite being in the package list for fedora(?) on recent versions, It fails to install and talk on the bug thread is just to remove the packages from the repo.
One of the nice things about Linux is that users have choice. A lot of people were put off by the transition to Gnome 3 and continue to be (self included). Which is fine since the desktop environment/window manager can be swapped out. It's nice to see Xfce being added to the mix for Wayland since is is clear that Wayland is going to be the future.
As for Xfce changing, that is to be expected since people's needs change over time. It is simply nice when those changes are gradual and not radical.
>It's nice to see Xfce being added to the mix for Wayland since is is clear that Wayland is going to be the future.
It's not clear at all - Wayland is in some ways a regression compared to X (try writing your own WM - tinyWM is 50 LOC, whereas the Wayland equivalent TinyWL is over 1000), and doesn't just "improve" X but changes paradigm entirely.
I'd like to see [Arcan](https://www.arcan-fe.com) be the future, it seems more elegant than Wayland.
Yes, quite different but roughly the same paradigms. I recently used an old HP-UX workstation with HP VUE and it felt very familiar and intuitive, not to mention the aesthetics were awesome.
Oh my. Gnome3 is so beautiful and so weird. WTF with "activities"? And why have the activities menu at the top left? the menu with all the apps is as horrible as the Windows 8 menu, etc. I rather use Mate, Cinnamon, XFCE, or even KDE.
KDE's Plasma hasn't changed the UI radically since the 4.0 release, and 6.0 will also not introduce any radical UI changes. It's settled down quite nicely, and most of the effort has gone into performance optimizations and polish.
This is not to detract from XFCE, which is a cool project with many strengths as well, and certainly deserving of enthusiastic users (doesn't matter which FOSS desktop you love, we all win).
Has KDE fixed the inconsistent spacing in their default themes? In past eras every time I tried to use KDE the inconsistent spacing in the apps included with the desktop was jarring.
I really, really wanted to like KDE as it's super powerful otherwise.
There's certainly always a lot of effort going into that direction. The KDE community also has a goals voting process that elects multi-year community-wide goals (each goal gets their own leadership, funded hackathons, budget, etc.), and "Consistency" was one of the more recent batches and is still ongoing: https://community.kde.org/Goals/Consistency
So I'd say it's worth checking back, and certainly the developers/contributors take your ask seriously enough to vote for it themselves.
I'm running i3 + xfce-settings for many years and to me it's a perfect solution, extremely stable. I have no opinion on wayland, but I dread the day when I'll have to move to it, as it will mean switching WM, and I assume lots of details will change. But at least it seems XFCE should still work! I just want my desktop environment to fade into the background and not bother me. I'm used to all the little quirks now :)
I feel much the same, though I'm running bspwm, with my own cobbled together scripts rather XFCE. There's zero upside to me in an upgrade, but I worry it eventually will become hard to avoid.
I'm increasingly tempted to grab a simple Wayland compositor and "bolt on" a minimalist X implementation directly on it to also allow X connections with just enough of the protocol implemented to allow running some simpler X WMs (but I'd love it if someone beat me to it).
For WMs with lots of fancy stuff it'd can take quite a bit of the X API to support, but a simple X WM doesn't typically use that many request types (I just looked at i3's source, and it's X interactions are pretty simple...
exactly this is the reason why I sticked to XFCE. Super stable, no useless changes, easy to use and configurable. Lets me keep my workflow. It's a tool like the workbench of a carpenter. I want to decide how its organized once. And if there is a need to change something, then I will be the one to change that, as I am the one who uses it. Looking forward to Wayland support!
At which point, inevitably, a new generation of devs will look at the now-huge wayland codebase and say "what is all this cruft?! who wants color management in what should just be a display protocol? let's start over and This Time We'll Get It Right™", and the circle of life will continue.
Luckily they’re both WIP at this time. That said, the color management, just the spec, has been in the works for what feels like ever—to the point that some of the window managers are going around them in implement their own spec.
Actually, I would expect that it will be a separate protocol, so the next generation will instead ask why you would ever leave color management out of the core protocol and proceed to immediately bake it in.
There are a couple reasons I can only back Gnome at this point, even though I loved/miss XFCE.
Wayland multi-seat + idle-inhibition
HDR + variable refresh
Fractional scaling (I think XFCE has some/all of this?)
We're just playing catchup to MacOS for over a decade, and soon enough Linux will have to compete with 3d desktop environments (Apple Vision Pro interface). I think we're almost to the point where the DE will be just a physics simulator (game engine) to help augment your reality.
Anyway, I still use XFCE on resource-limited hardware but Gnome has been the only option for a while because progress isn't being made by other DEs on these critical things (color, refresh, alpha-composition, and some wayland protocols missing in wlroots).
I'm just glad Gnome isn't the dependency hell it used to be, and has slimmed down. I really love what they've done with GJS but I believe there's a competing KDE bindings project.
xfce isn't even useful on resource limited hardware, you are better of using a much lighter weight wm like icewm , openbox or fluxbox + a lightweight launcher and a lighter set of file managers and viewers [1].
[1] even window maker could do it, I saw it was recently updated.
The move to Wayland is interesting to observe. On first glance it seems that moving to Wayland provides a load of burden on DEs that they never had before - and not just because of the work required to transition. And that obviously this is all Wayland's fault.
What I think is actually going on though is that we expect quite a rich feature set from a modern DE - exactly as you have listed.
We could never do most of this stuff on X, but Wayland enables it and then follows a load of work to get it all going.
In an ideal world there would be a nice clean abstraction boundary between compositor and DE so that this underlying work was shared between DEs. Maybe that is possible, but people who know what they're talking about seem to agree that the Wayland approach is the right way to go and I don't know enough to disagree. Plus, it makes some intuitive sense that your DE should know how windows share rendering space.
>> In an ideal world there would be a nice clean abstraction boundary between compositor and DE so that this underlying work was shared between DEs.
Not sure what's ideal about that. With Wayland the DE IS the compositor. There are a lot of benefits to that. I would hope basic compositing is a fairly small amount of code and many DEs could build on that - which I guess would your clean boundary even if it's in the same process.
I think my point is that wlroots is a set of building blocks, rather than a single library. You can't build an unopinionated single library that just takes care of the Waylandness of your DE, that you can build on top of. The compositing and the windowing and the event handling are all intertwined, so instead the best you can do is wlroots which gives you some blocks you can put together in the appropriate way.
It makes for complex, significant work for any Wayland DE, with less shared work. I don't think this is wrong - it seems this is the approach we need to get full featured DEs, it's just unfortunate that that's how reality has worked out.
The point of Xfce for me is that it is configurable, the way Gnome is explicitly not.
Of all that, I only care about fractional scaling. If I wanted Apple-like experience, I'd be using a Mac. Imitating Mac experience on different hardware can be a worthy goal, but it's definitely not the only worthy goal.
on the topic of XR desktop environments, Linux is possibly well positioned with projects such as monado, xrdesktop, and SimulaVR: https://www.youtube.com/watch?v=RXQnWJpMLn4
Not so sure that VR will take off that much, or that soon. The Apple Vision Pro is still pretty heavy, working for hours with that thing, well I hope you have strong neck muscles.
I feel like 3D desktops will be about as useful as 3D televisions; to whit, not useful.
Probably 25 to 50% of the usefulness of a monitor is that you can show your neighbor what's on it. Also 3D gives the user headaches often, and you have to wear these huge goggles.
Finally, I have enough trouble wrangling windows and getting them to behave with two dimensions. A third dimension just adds a place where the windows can go that I don't want them to go.
Gnome doesn't work well for me unless I find a bunch of half maintained bug-ridden extensions to fix the problems that have it has and it still doesn't work properly.
KDE is perfect. It used to be slow but now it's not. It's very configurable but doesn't need it most of the time.
XFCE for many including myself is the ideal, and is not playing catch up. At least I hope it isn't.
I switched to a Mac temporarily recently. I had to install an additional app just so that I could tile my windows in a basic way that is already supported by KDE, windows, pretty much everyone else. They have alpha compositing and all that, but it still felt like a step backward.
Not everyone uses a nonlinear video editor for a living.
Wayland protocol will celebrate its 15th birthday later this month. TFA is great news, but something isn't right here.
I really start to think that the X11->Wayland migration is a bigger clusterfuck than Python2->3 was - even if we consider that a compositor migration is much bigger task than Python migration.
Wayland on sway has been a smooth sailing for me, the only thing that made be go back was barriers KVM not working and not finding an open source alternative that works for both Linux and windows.
I’ve been using it with KDE on my laptop and desktop (which has an Nvidia GPU).
The laptop is flawless, and the desktop only has minor issues with display configuration (order and/or resolution) getting messed up sometimes when waking from sleep. I’m pretty sure that’s an Nvidia driver bug.
Anyways, it is 100% usable. To say otherwise suggests you haven’t actually tried using it within the past 2 years (at least)
> Anyways, it is 100% usable. To say otherwise suggests you haven’t actually tried using it within the past 2 years (at least)
IDK why, but the way you say it really annoys me. Like disregarding people's experiences because you have not faced the same issues.
Anyway, I try to shift to plasma wayland atleast every month. But there's always these weird graphical issues on nvidia (desktop) that ruin my experience, so i switch back to my x11 session. Even KDE has a page detailing the various problems in wayland https://community.kde.org/Plasma/Wayland_Showstoppers
My experience was that Python3 became a meaningful upgrade over Python2 around the 3.5 release. That was less than seven years of transition!
I've been happy with Wayland for most of my Linux desktopping since 2018, so that was a ten year transition from first release to full adoption on my part.
Of course, there is a long tail of things that can't/won't migrate. I still see Python2.7 production code on a semi-regular basis (not network exposed, but very much at the core of critical business processes of major enterprises).
And I'm sure we'll have X11 desktops around for various purposes ten years from now.
Wayland has a pretty deep issue that loss of the compositor socket is treated as fatal and kills the client application. And when the IPC socket buffer is full that's leads to a close (so it is one of those fatal errors). So any latency spike in the event loop of the client process can lead to a process kill. The GTK implementation even calls _exit() which means atexit handlers won't trigger and save-on-exit or crash reporters won't run. So with wayland lag gets "upgraded" to hard process kills. That's a pretty crazy design choice.
X11 handles momentarily unresponsive processes far more gracefully.
This is not a wayland (the protocol) issue. It's a client issue. In fact Qt6 was recently in the news here for having fixed it in their client code, by simply reconnecting when the wayland socket closes instead of crashing.
Wayland is like systemd all over again. We had something ancient and crufty which just about worked, but was a genuine obstacle to progress. A group of crazy people got together and designed a replacement. Everyone else pointed out that the design was crazy. The designers carried on anyway. And now the crazy project is the only game in town.
Well perceived as ancient and crufty. I do not think there is any genuine obstacle to progress. But the thing is not just that some crazy people got together and implemented something we could all use or not, the problem with both systemd and Wayland is that it comes with all the propaganda that this is the future and nothing else, that everything else is "ancient and crufty", "unfixable", and "broken". This is clearly meant to demoralize everybody interested in alternatives. For example, there was no really good reason for Debian to force the systemd decision. That an entire distribution spawned from frustration about this decision clearly shows that there is enough interest and man power to maintain alternatives. Let's hope some people step up for X as well.
Wayland is more than a compositor protocol. It's a whole suite of replacement protocols for all the functionality that X used to offer.
And it takes time to replace an established protocol. Especially when you need to provide a feature-complete fallback for all the applications that are never going to do the switch.
For me that transition has been pain free. First I heard that X is going to be retired, then I saw some development note popping up here and there and then one day I was offered to log in to a Wayland session instead of a X session. I never experienced any problems I could directly attribute to Wayland.
I don't know why Wayland gets so much hate. To me it feels very much like the systemd hate: I don't know why this needs to change; I was happy after all. I don't want to learn about a new thing, so I'm angry.
> I don't know why Wayland gets so much hate. To me it feels very much like the systemd hate: I don't know why this needs to change; I was happy after all. I don't want to learn about a new thing, so I'm angry.
Yes, it's a very similar situation; in both cases people are really fond of pretending that the only reason you could possibly object is that you hate change just because, while ignoring the actual regressions that it's causing. For instance, Wayland does not support (and probably never will support) some accessibility tools that make my life much easier (because the desktop must be secured against programmatic manipulation).
I use X remoting every day. Being told that I do not need it and it would not work anyway, is what makes me angry. Then I hate that decades of protocol compatibility are broken, which i think is sad and stupid. Finally, I saw people had issues with Wayland (screen sharing etc). Then - after 15 years of development - being somewhat usable also does not convince me that it is so much simpler because of an superior design. Regarding design, I think the monolithic design is inferior. Finally, I never found the technical arguments terrible convincing (such as that an unused old line drawing API in X somehow holds modern clients back - obviously this is BS.).
Thanks for providing some context. I still don't get one point though;
Nobody is taking X away. You can still run any DE and any application on X if you want to. You're not being restricted in your ability to run applications, quite the contrary; your are being given more options. So even if your use-case is not yet fully supported on Wayland, why hat on it? No one is taking anything away.
But yeah; ever since Sun stopped founding it, the accessibility situation on Linux has been dire.
> You can still run any DE and any application on X if you want to.
That's unfortunately incorrect; so far Waydroid is the only program I've hit that explicitly requires Wayland, but I expect the list to grow with time.
> So even if your use-case is not yet fully supported on Wayland, why hat on it? No one is taking anything away.
> I don't know why Wayland gets so much hate. To me it feels very much like the systemd hate: I don't know why this needs to change; I was happy after all. I don't want to learn about a new thing, so I'm angry.
Perhaps you haven't experienced it yourself, but systemd and Wayland have both caused a lot of unjustifiable problems for a lot of people.
That's where the widespread displeasure with them comes from.
It has nothing to do with dealing with change itself or learning something new.
If systemd and Wayland had brought me some tangible benefits, without also bringing me significant pain, then I'd be perfectly happy adopting them like I frequently do for other new-to-me software that makes my life better.
Unfortunately, that's not reality. For example, I've had to deal with far too many Linux installations that no longer boot thanks to systemd (or one of its many components) unexpectedly breaking in one way or another, often after what should be routine updates.
I've never had any success with the Wayland implementations I've tried, either. They've performed horribly on the computers of mine that I've tried them on, to the point of being pretty much unusable. A default installation of X on the same Linux installations works much better and is completely usable, however.
Based on all of the mailing list emails, forum postings, chat logs, bug reports, articles, and other online material that I've seen while trying to sort out such problems with systemd or Wayland, it's clear to me that I'm not the only one experiencing such troubles.
Even if I hadn't experienced such problems, neither systemd nor Wayland would benefit me in any meaningful way. At best, they're merely replacing what I've already been using for years or even decades, rather than improving upon them.
systemd brought me a lot of benefits (both as a power user and as a sysadmin), I'm not that much in the know with regards to X vs Wayland, but nowadays stock Ubuntu with Gnome on AMD uses Wayland and dual 4K monitors with hi-dpi scaling and 60Hz and 120Hz works.
the more important thing is ... not a lot of people stepped up to maintain the old ways. if they are so superior, why isn't there a big group doing it?
...
that said, yes, systemd is crap, it's an endless pile of C instead of the previous [ba]sh bonanza, but it works, and it does a lot of things, and the maintainers are active and doing a lot of good things. plus it's finally standardized across distros.
and any talk about Wayland or X is completely irrelevant as the bugs that frustrate users are not in the protocols, all of them are in the implementations. I, like many starry eyed nix users, motivated to grow the bazaar [had many attempts at contributing] by opening issues, reporting bugs, trying to debug stuff, using beta/dev/nightly/canary/RC stuff ... but it did not make much of a difference. there's just not enough dev bandwidth to deal with even trivial stuff.
I mean it's sometimes* after wake up it's impossible to interact with the Gnome lockscreen with the keyboard unless first clicking on it with the mouse, on Xfce sometimes after opening the lid the screen is visible, and on KDE ... well, on KDE I don't even know what bug I tried to report, but no, fuck Bugzilla.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3135
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4858 [something solved]
https://bbs.archlinux.org/viewtopic.php?id=251935 [on xfce just uninstall "light locker"]
https://wiki.ubuntu.com/DebuggingScreenLocking#Known_bugs [it's just madness]
... and of course I could go on.
And why these problems happen? Because the stack is ossified as fuck, because complexity is through the roof (due to hardware frontrunning the whole show by a (?) decade), and because OS developers being, well, folks who in their infinite wisdom stick to C and C++ and even introducing JS to the stack. (And many people remember when Ballmer-peak Microsoft tried to move to something memory safe, but couldn't... because "it was too hard". Yeah, just hacking everything together somehow is always the smart solution.)
My favorite combination is Mint + Xfce + openbox as the window manager which leaves the CPU at 0% when not doing anything, and is very responsive and versatile. I had to setup separate dark themes for each one but now it looks good.
The only thing I don't like is thunar freezing often when doing long blocking IO operations...
I've recently been giving Xfce a try again on one of my machines, and even though I still prefer KDE on my main machine, I've been quite enjoying it. Especially the SPEED of it has been astonishing. Everything is just absolutely instant. I also really like the "spartan" feel of it.
Probably the main thing I'm missing from KDE is being able fo use Super+Number to switch between windows, i.e. Super+1 switches to the window at the first position in the taskbar, etc.. I've been searching around, but haven't found anything that'd be 100%. Would anyone happen to have a solution by any chance?
I guess you would need 9 shortcuts and you would set nth to the number associated with that shortcut. Works for me at least. You might have to define the shortcut to "bash -c " followed by the above oneliner with some appropriate quoting and escaping of inner quotes.
This is what I'm doing right now, but the issue is that it'll only work as long as the order in the taskbar and the window manager list stay consistent. I like to manually reorder my windows in the taskbar and that makes this approach break.
You could use wmctrl -l -p to also get the pids and then get the start times for each PID with ps -p $$ -o lstart. Then you could sort by start time and only then choose the nth window. There still might be multiple windows belonging to the same pid, though. And if you close windows, the list might still change. You could also hardcode win+1-9 to specific programs, then they would even be consistent over restarts. Then again, the docklike plugin mentioned in the other answer might be similar to that.
I hope this will be a slow transition but I am pretty sure it will since that's how xfce usually works.
I switched to xfce not so long ago after almost 15 years of using KDE for that slow pace exactly. I had small problems and annoyances with KDE on nvidia for a long time but it got worse over time and reached a breaking point lately. Not even talking about Wayland.
Anyways, I am happy to have a rock solid and stable alternative like xfce.
These days I can't be bothered to deviate from the happy path anymore as I've already spent too much time in my life customizing my desktops.
I just use whatever GNOME offers and maybe 1-2 extensions. A few months ago I switched from Fedora to Debian 12 and barely noticed it. Thanks to GNOME and systemd, which I hate independently for various reasons.
- It is not clear yet which Xfce release will target a complete Xfce Wayland transition (or if such a transition will happen at all).
- We do not have the resources to maintain our own Wayland compositor
This should tell you everything. Since the Wayland ecosystem is extremely developer hostile it cements the KDE/GNOME duopoly and eliminates the long tail. XFCE might maybe make the push to Wayland but after that that's it. The rest of the tail is dead.
This has already proven to be wrong, imho. There's numerous Wayland versions of popular niche X11 WMs, for example the way sway is a Wayland implementation of i3, and some exciting new experiments (like scrolling tiling WMs) that never really existed on X11.
It's usually a lot easier to make a compositor/WM with unusual or innovative behavior on the Wayland stack than it was with X11 in general, as far less behavior is presumed/baked-into either the display server or the existing applications. For example, apps not being able to introspect or manipulate their global coordinates also means the compositor can arrange them however it wants without breaking app assumptions, which enables fancy new layouts.
There's prominent libraries that make compositor development easier, for example wlroots and QtWayland -- XFCE is also using wlroots. "Punt it to a library" isn't radically different from "punt it to Xorg", even if the slicing is a little different.
> "Punt it to a library" isn't radically different from "punt it to Xorg", even if the slicing is a little different.
That's a reasonable expectation, but it turns out the slicing does matter. For example: With Xorg, setxkbmap will always work to change the keyboard layout on the fly. Now, wlroots does support configuring the keyboard layout, but it turns out the compositor has to actually hook that functionality up, so if I try out a new compositor that looks neat, I can quickly discover that there's actually literally no way to change the keyboard layout because the developer hasn't gotten around to adding that yet. This is not a hypothetical example.
Proven wrong by whom? Your opinion is obviously severely biased because you get paid for working on Wayland. Job security is obviously the only reason anyone would defend this pile of garbage of an ecosystem. All your suggestions mean replacing X11 functionality with vendor lock-in de-facto proprietary Qt libraries. I can see why your employer likes that.
Just want to show massive appreciation for Xfce. Best DE ever. I'm currently forced to use macOS in the work laptop and I miss Xfce every second. It'd be amazing to have a Wayland version so we can enjoy it for many more years to come. Thanks to the developers of this fantastic piece of software.
238 comments
[ 3.6 ms ] story [ 309 ms ] threadThey recently moved to gtk4 (or are planning to?). I wonder what would be the difference between gtk3 and gtk4 apps in terms of latency and performance.
https://bugzilla.gnome.org/show_bug.cgi?id=790677#c6
I think 4 plans to kill theming too.
Not having to periodically scrape the crud off the rollers has been such a boon to me.
Such a person may have used a desktop, but desktops are foreign to them.
Killing theming and removing features when they do not have a serviceable usable alternative does not make it more "accessible", it is just the standard "we know it better because we study the behavior of a large group of users" excuse that they give to treat it everyone by the lowest common denominator - just like Apple.
That being said, I will shamefully echo the words of the GNOME maintainers; their goal was not to "kill theming". They wanted to stop distros from shipping themes by default, which was arguably just as deranged but at least somewhat understandable. Nowadays we have stuff like Gradience too, which lets you theme LibAdwaita apps. You're still forced to use the ugly old Adwaita buttons, though.
So... make of it as you will. I left GNOME completely after the GNOME 40 update, I sympathize with people who hate the current desktop. The toolkit itself is "fine" in my unprofessional developer opinion.
Funny how with anything on the internet there's always Ayes and Nays. It's almost hilarious to me about humans that "the market always segments" into all these trivial seeming (but decidedly important if you have skin in the game) choices.
I'm not questioning at all the importance of UI and UX in any way. It's fundamental. These visual virtual environments are the primary tools we humans use every day for our information manipulation snow-shoveling knowledge work. They have to be refined and have exquisite ergonomics tailored to our every whim. That's undeniable and it's not surprising at all that people have strong preferences.
I just think it's funny that people can't seem to agree, on anything. The market always segments.
Example from my business: we build a remote browser that has a kind of real time streaming optimized for adapting many bandwidth conditions to reduce lag (which often occurs by trading away raw framerate). For some people (normally the security conscious crowd), this is perfect. For other people (the app virtualization crowd) this is terrible: they want silky smooth high framerate remote streaming. I suppose people get could lectures about trade-offs, but it really is a kind of enjoyable thing: there's always something to work on.
An advantage of being open source is people can tweak it to their needs as much as they want. There's no bottlenecks in the system besides what you want to do, and how much compute and bandwidth you can throw at it. It can be as fast and smooth, or as resource efficient and minimal as you want.
Hahaha, really? It's been my desktop since I started using Linux in the 2000s. It's great! It presents windows, has a small set of high quality built in applications (file browser, application launcher, etc), has a big and flexible set of keyboard shortcuts, and other than that, it just gets out of your way.
Other DEs like to shove themselves in your way -- put your mouse in the corner of the screen? Something shows up! Hit a wrong keyboard button? Something shows up! Open the application launcher? It's fullscreen, baby! Do something to a window? Here's some jiggly wiggly animations!
XFCE just does what it needs to do, quietly, with no fuss. It's fantastic.
> I just think it's funny that people can't seem to agree, on anything. The market always segments.
Well, I guess I'm just proving your point :)
Now I just need hardware to run it on local. Can you suggest some? M1 ARM is out...so what should I get?
At one point in time I used it because I couldn't afford a decent computer and XFCE used fewer resources (so my slow computer would be a little more responsive). Eventually I went back to it because it was familiar and it gets the job done.
If XFCE ever adopts the GTK4 ugly topbar cancer I'll switch to KDE and the entire K application suite and never run a GTK application again.
Really hope that Wayland integration works well for them.
Both are pretty dumb when it comes to Hi-DPI support although Cinnamon does an acceptable job at staying coherent when configured with bigger fonts so it’s a workaround. XFCE manages bigger fonts very badly so I have big hopes that real Hi-DPI support will be better with wayland.
Wobbly Windows are amazing and never get old. It's been years, and I still get joy from them.
I'm sure there are other nice effects too, but I don't feel that strongly about them - Wobbly Windows are the hill I'd die on.
And in gnome's case you can just disable animations in Settings-->Accessibility-->Seeing-->Reduce animation
So Wayland++ can provide network transparency, but whenever a W++ feature has issues and those issues are criticized, Wayland advocates will just motte-and-bailey the issue by saying "but that's not part of Wayland!", which is technically true but irrelevant. "Wayland" can mean Wayland++ or just Wayland-core, depending on what's convenient.
x11 had long time become unsustainable in multiple ways
braking changes where inevitable
all of the most relevant DE had somewhat already gutted out X11 leaving nothing behind then the interfaces
so the replacement being defined by interfaces and "every DE for themself" was just natural, for the large DEs it was already the case anyway
and for the other DEs you could say wlroot is now the common core they need because they don't have the will/time to implement everything by themself
The protocol uses shared memory buffers and file descriptors, so it can't be just transported through TCP as-is. You need something like waypipe, which parses part of the protocol, extracts things like file descriptors that won't make sense on the other end, and then reconstructs things on the destination.
waypipe turns out not to be that complicated, it's just 15K lines of code.
Wayland should have shipped with a default implementation that had screen sharing, recording, clipboard and everything else that x11 had by default. The fact that they've thrown all that responsibility on DEs without so much as a HOWTO on how to reach parity is ridiculous. I will never understand why anyone took their effort seriously.
Well, all DEs (excepting maybe Xfce?) have members in the work groups that design the wayland protocol extensions, so it can be assumed that people are well aware of what needs to be done.
Wayland has a default implementation called Weston, but I'm not sure that any of its devs cared enough to implement the extensions which are responsible for all the other bits that you mentioned.
most software which did support network transparency in a way similar to what X11 started out with has giving up on it (like in the industry as a whole) and there seems to be a clear technical consensus that it's best to not to approach remote access this way, even in X11 it was kind of semi-abandoned long before X11 was semi abandoned (from developers not from people using it)
As far as I can tell from the POV of the discussion of weather Wayland (or any other hypothetical replacement) needs to support it the answer always had been a clear "no it doesn't need to, nor should it try to".
This doesn't mean that you can't have remote shared applications, desktops, screen sharing or similar just not using network transparency. I.e. not by pretending the things the application communicates with (compositor, GPU, etc.) are on the same computer and "transparently" routing (part of) them to a different computer. And if you consider the stark difference in latency, reliability and throughput between a Unix pipe/speaking to a GPU over PCIe and TCP over Ethernet it can feel surprising that it was ever considered to be a good idea (but then when X11 was build network transparency was just that big think people put into everything, from most of which it is removed by now).
So what replaces network transparency (and did replace it in many cases long before Wayland was relevant) is typical remote desktop functionality. I.e. and additional application will grab the mouse/keyboard input on one side and the rendered output on the other side and sends them to each other. This has many benefits both for the people not using it and the people using it while many of the drawbacks often practically do not make much of a difference anymore. The main issue is if there is a high quality open source for free program you can use and if it's installed on the system where you want to use it...
Sometimes because you want users to be able to change workstations, sometimes because you want a highly specific environment outside of the user's control (it can reset on each connection), sometimes because you want nothing to be kept locally. Eg, the country somebody works in is untrustworthy, so they access everything somewhere remote and safe.
and if you have no complex rendering requirements then often it's a much better choice to place the network gap in the GUI toolkit instead of the DM as this tends to work way better, in this case you do need a thin client on the other side, but so do you need for X11 remote (the client needs to run X11) so it's kinda not that difference. And today the easiest way to ship thin clients happens to be JS/WebGPU, which is how we have stuff like GTKs webrender backend.
Actually, it is. The actual straw that broke the X developers was font metrics, IIRC. Essentially, if you want to support fonts for the language of the most populous country on Earth, you need to do more or less complete font rendering to answer questions like "how long is this span of text going to be" (so that you can break it). And the X developers tried to make it work with the X model, but the only way they could get it to work well was to have the X server ship the font to the X client and the X client ships rendered bits back to the X server [even over the network!].
this use case is broken in X11 since a very long time, because to make this work well you don't just need some form of network transparency in the network manager but also remote rendering for OpenGL and Vulcan
> Software rendering is a regression t
But in most cases it's not happening, because you don't render on the server for most applications you render on a client which interacts with a server.
> and Javascript apps seem to be the way the industry is avoiding it (with the browser as a remote display server).
Today many JS apps are not thin clients they are often quite complete applications, but lets ignore that for a moment.
I'm not sure what exactly you are imagining, but as far as I can tell the only way to make this kind of remote rendering you are implying work in general would be by making X11 a GUI toolkit with some form of cross OS stable interface and it also would be the only supported GUI toolkit and any fancy GPU rendering (e.g. games) would fundamentally not work. There is just no way this would ever have worked.
The reason the industry mostly abandoned network transparency not just for remote display servers but also in most other places is because it's just not working well in practice. Even many of the places which do still use network transparency (e.g. network file systems) dent to run into unexpected issues due software happen to not work well with the changed reliability/latency/throughput characteristics this introduces.
0. https://gitlab.freedesktop.org/mstoeckl/waypipe/
The internet suggests increasing the responsiveness checker or disabling it entirely, but that makes Firefox unresponsive to mouse input.
Waypipe does have some great hardware acceleration advantages over remote X11 sessions, but for me it's currently not usable.
In any case ssh -X still works fine out of the box, using which transparently uses XWayland behind the scene.
It has limitations compared to native Wayland like good support for multi screen with different DPIs, but the same limitations will be found in a native X11 session anyway.
So Wayland is at least not a downgrade on this topic. It's been handled well.
It still has abysmal performance (and many other issues), though. I've been using Xpra for a while now, to at least let programs survive if my connection is interrupted. Makes it possible to work from a train or conference Wi-Fi.
waypipe has good performance, but IIRC it suffers from the same disconnection issue. Hopefully recent work from KDE on surviving a compositor restart means that restarting a waypipe session will be possible, or even juste deciding to forward a program after starting it (which wouldn't be possible with X).
One could also imagine exposing a window to both local and remote compositors (could be implemented in waypipe), with simultaneous access leveraging Wayland multiseat. "Multiplayer" compositing.
I also use ssh -X a lot from home to work and performance is sufficient. Xpra shows that it could also work over low latency links if you have latency hiding which the X supports but because it is asynchronous but - again - toolkits never bothered. Fixing these issues would be a million times more useful than redeveloping everything from scratch.
Sure, in that case you could even switch back-ends and have your toolkit interrupt its connection with X and start talking with GBM/DRM, Wayland, or another X server. However, the required changes would likely be invasive. I get your point though, this is relatively similar to Wayland programs surviving compositor restarts. However, you would need to start tracking all the state that the X server tracks, to replay it later. Not impossible, but quite hard to bottle on existing implementations, I think.
> Fixing these issues would be a million times more useful than redeveloping everything from scratch
That's your opinion. In my opinion, Wayland does a lot of things right; the main one being a specification that everyone can implement. That makes it much easier to start from scratch to implement an innovative feature in a proof-of-concept toy compositor or program. We've seen a lot of these projects, and consolidation takes time. Once proven, features tend to trickle down to general purpose compositors.
I am really satisfied with the tools Wayland has given us, from gamescope to nested compositors, better isolation, better-behaved clients (no more clients that refuse to go fullscreen, etc), a very stable experience with few crashes (compared to misbehaving clients taking down the X server with them), easy multiseat, no more tearing, no more xorg.conf, better client isolation (notably remote apps cannot spy on locally-running apps), pipewire-based screensharing, choose-your-own-compositor-features approach (granted, not for everyone; but those uncomfotable can stick with KDE or GNOME).
The future seems promising, mostly thanks to wlr protocols, especially wlr-layer-shell that should allow running UI elements from a DE on other compatible compositors (I can't wait to use xfce4-panel on sway starting from their next release[1]).
> I also use ssh -X a lot from home to work and performance is sufficient
Personally, I ran into issues with Cadence, even on a LAN: that software uses some X toolkit, and some very long lists (scrollable form-like dialog) took dozen of seconds to display; I also had various font issues, issues with software moving my mouse (I hate this), performance issues with complex drawings. Most of these disappeared when running through Xpra. Not to mention losing my work because of small internet cuts, putting my computer to sleep, or having the ssh connection interrupted somehow (ssh has trouble with roaming, connecting over wireguard helps with that).
> Xpra shows that it could also work over low latency links if you have latency hiding which the X supports but because it is asynchronous but - again - toolkits never bothered
This is getting too technical, I don't think I'm qualified to discuss this. Though don't you mean high latency links? Xpra is basically a local X server that sends data with a protocol similar to VNC. It is quite similar to how Waypipe handles things. I may be wrong on this, but I think RDP may combine the best of both worlds? Dumb "vnc-like" connection by default, and make use of optimized implementations in the toolkits when available.
[1]: https://gitlab.xfce.org/xfce/xfce4-panel/-/merge_requests/10...
>> Xpra shows that it could also work over low latency links if you have latency hiding which the X supports but because it is asynchronous but - again - toolkits never bothered
>This is getting too technical, I don't think I'm qualified to discuss this. Though don't you mean high latency links?
Yes, of course.
>Xpra is basically a local X server that sends data with a protocol similar to VNC. It is quite similar to how Waypipe handles things. I may be wrong on this, but I think RDP may combine the best of both worlds? Dumb "vnc-like" connection by default, and make use of optimized implementations in the toolkits when available.
I do not think you will every get good client integration as good as X with dumb protocols and my experience with RDP was always relatively poor. Xpra uses its own protocol between two proxys but supports good integration so is different to a stupid screen scraping approach, but I think it could just work by doing the latency handling on the client and speaking directly to a remote X server using X. The reason that I believe that would be possible is that X is a very flexible remote buffer handling protocol. So caching of some image content and copying it around could all be done remotely controlled by the client. I started to implement something like this but then did not have time... But the flexibility and extend-ability of X is also the reason I think that throwing it away is completely unnecessary.
If applications are written in GTK2/3/4, fractional scaling won't work well and lead to blurry windows.
Integer scaling (1x, 2x, 4x) should work just fine, but fractional scaling isn't implemented consistently across GUI frameworks. Hopefully Wayland will fix the inconsistencies between implementations, though GTK and some other GUI frameworks will likely remain broken for a while.
If you need multi-decade support from your GUI layer, I can recommend raw Win32 or VT100 terminal codes. There's hardly any other API with that kind of backwards compatibility.
It take 2-3 years to iron out the bugs. Non-gnome downstream take another 3 years to adopt and stabilise.
By the time the adoption is finished, another major version emerges.
We don't have any good way to maintain compatibility that long.
X11/Xlib, though obviously you have to do the GUI bits yourself (but then you mentioned VT100 terminal codes so i guess that is acceptable).
Also AFAIK Motif is backwards compatible going back to the 90s.
While Windows doesn’t provide a unified GUI toolkit, win32 UI controls of different generations can be mixed freely within an application, enabling gradual upgrades.
*Usually, not always.
A GTK 2 application compiled 25 years ago usually still runs today, too. Just because GTK 3 is available doesn't mean GTK 2 stopped existing.
I have no specific insight into decision-making in open source organizations, but given that the resources they're working with are several orders of magnitude less it's not surprising to me that they sometimes end up having to choose between stability and new functionality. (While I personally prefer projects towards one end of that spectrum, I'm happy that different projects have different values for other people.)
Qt? 99.99% of the API from Qt 4 (2005) is identical in Qt 6 (ongoing). A few headers were renamed, and a few minor functions, generally stuff you can port in 1 day.
When they released Qt 5 and 6 and decided to switch from Qt Widgets to a new GUI toolkit (QML), they didn't say "umm, just rewrite your whole codebase in QML bro", they kept widgets around in perpetual maintenance mode. This is how you respect your users.
I do not think this is current info, but otherwise might be the reason as it is an experimental feature.
For example, you can enable fractional scaling in GNOME right now.
https://www.youtube.com/watch?v=BjfZ8TSXsps
This phoronix article shows the variable to enable it in GTK.
https://www.phoronix.com/news/GTK-4.11.1
Edit: added a little clarification + cited the specific bit of text I was responding to.
Debian still ships support for token ring; the idea that X11 is ever "going away" really misunderstands how free software works.
However, development of xorg is completely dead so it is pretty likely that distributions will stop support running xorg sessions in the future, and at some point xorg will likely not run on new graphics cards anymore.
KDE has announced plans to discontinue support for running x11 sessions and only runs on wayland in the upcoming plasma 6 version.
For now all the gui toolkits will presumably continue to support x11, but at some point, it is likely that new applications will only care about supporting wayland, and after that, it is possible that future versions of gui toolkits will stop supporting x11.
Maybe "ripping out working code" is a bad thing, but at a certain point people would have to put in extra effort to ensure that x11 stays "working" and if nobody steps up to put in that effort and x11 support breaks, it won't be ripping out "working" code anymore.
I don't think that's true; didn't it just recently get a new maintainer who put out a bug fix release and everything?
- fractional scaling of the display output
- app rendering at fractional scales.
The first one works fine with Gtk 3 and newer; the application renders its output at nearest higher integer scale, and then the compositor downscales it to requested fractional scale (i.e. app renders at 200% and compositor downscales it to 175%). Apple does exactly this same thing (just with slightly different scales; they won't show you nice 150% or 175% for a reason; they optimize for different thing).
The second one is rendering at fractional scales directly by the application; then the compositor doesn't downscale anything, just displays the buffer as it is (i.e. app renders at 175% and compositor displays it as it is). Since rendering at fractional scales is more demanding (just think about fractional mouse coordinates or how to display 1px straight line and don't get lost in the rounding errors), it took longer to materialize. It is this support that will have to wait for Gtk 5.
But meanwhile, your (Gtk) apps will be displayed at fractional sizes using the first method.
Blurryness is often caused by GTK2/old Qt5/Electron applications that don't support Wayland and are rendered using XWayland at 100% and then upscaled by the compositor.
Support for this kind of rendering is going to wait until Gtk 5 -- implementing it in Gtk 4 would break ABI, and then the world would have to listen to cries about Yet Another Breakage. The current system, rendering at integer scale and then compositor-downscale is working fine since Gtk 3. Btw, exactly this way is how Apple does it, and it was lauded as a great way to support scaling.
I also believe this is only the case for Wayland, so X11 users may be out of luck here. Actual fractional support would require breaking API compatibility, which is why integer scaling+downscaling is necessary.
This is a feature
https://youtu.be/2GYT7BK41zk?si=INGkzL9sF5tkvm1q
KDE does not spark joy, but then again, most devs and most users have no real artistic sensibility to speak of. Have you ever looked at a random person's desktop? So I don't give weight to anybody that says "it looks good to me."
That said, I am now on KDE after a decade of GNOME because I need some of its configurability, and GNOME is starting to become too opinionated even for me, even though they have a slightly better design team not afraid of colours with more than 20% saturation.
AFIK this problem was solved ~2 years ago when Nvidia added support for GBM in version 495.44 (https://www.nvidia.com/download/driverResults.aspx/181274/en...)
https://www.phoronix.com/news/NVIDIA-Better-wlroots-Secondar...
Is it the way like this? is there any workaround? Could someone please enlighten me?
Have you tried opening a bug with them to see if just got broke in your display manager?
What do I like? It's never forced me to change the way I work. That's up to me.
So if Wayland is the future, then I look forward to using XFCE on Wayland somewhere down the line too.
I have my XFCE desktop working as I want now and I don't want to change it or having to learn where buttons are located after an update. With Gnome and Windows I feel like a lab rat for their UI experiments.
XFCE started as a clone of CDE. Now compare original CDE with XFCE and it is not really the same thing.
Sure, Gnome change from v2 to v3 was a major change in UI, but mostly for the better and Gnome kept a way to have a more classic behavior.
I personnally totally saw it as a different project as gnome 2 didn't become obsolete immediately and Mate&Cinnamon forks took over so quickly for those looking for a gnome classic evolution that no one was really forced into using gnome 3.
Yeah it did. They announced gnome 3 and deprecated 2 on the same day, and seemed to have made the deliberate choice to not allow them to coexist. As soon as your distro moved, bam, you were done.
> Mate&Cinnamon forks took over so quickly
After some months. This stuff was not there on day 1.
In the mean time, those of us who did not want to work the way Gnome 3 decided we should, had to find an alternative. And when we found a good one (Xfce for me), we stuck with it.
GNOME makes often changes without long term strategy or asking their actual users. The removal of Type-Ahead-Find in Nautilus or background-transparency in GNOME-Terminal where mistakes. On the other hand new applications like Documents or Console required resources but provide no benefit over it counterparts. That said - Nautilus improved a lot in recent years and there are even patches available for Type-Ahead-Find (or Navigation). Same for background-transparency in the GNOME-Terminal. The separated top-bar-menus were also a problem (decoupling menus from application-windows was copied from Apple) but now reverted, they learn.
If the design team is aware of the usage and has a plan things fit well! The overview is great for keyboard and mouse users, the dash make simple things simple, they got rid of the useless desktop-metapher (copied from Win95) and also the system-tray (another thing from Win95). The keyboard focused use of GNOME is use core-feature, fast for experienced users and a relieve for novice users. The GNOME-Shell provided a good UI and removed many questionable ideas of the past.
Wishlist?
Decouple the release cycle of most applications from GNOME, excepting Nautilus and Settings. There is no need to couple Epiphany, Terminal, Maps, Calendar and so. Evolution already skips every second release. And feature-removal should require a good reasoning and not just „I don’t need that myself“. Many options are bewildering, many forks without merges are worse (lost developers and lost users).
Gnome feels very anti Unix philosophy.
Either way, many package managers provide groups or patterns to make it easier for an end user to maintain their system. Pacman does have such a feature.
Look, for example, do you prefer to be able to install SDDM just because you like the themeing capabilities, and be able to do so, with just the bare minimum packages; or, install GDM and having to pull the whole GNOME DE as a requirement?
It's purpose is to provide and manage account information for applications that need it, so the user doesn't have to configure their email, calendar, whatever, in each application separately. With each application storing passwords in a who knows where, or each implementing their Gmail OAuth.
So it is quite logical, that application that uses accounts will also need gnome-online-accounts.
'Do one thing and do it well` -- how is that anti Unix philosophy?
GNOME has a keyring system service for storing passwords, so it's not necessary to get the entire desktop shell to access the keyring.
GOA is for storing account information: e.g. you configure your Gmail/nextcloud/whatever account once, and then all apps that need it can access it. So your Geary, Contacts and Calendar (separate applications) do not need each to implement account management and account specific auth flows -- not just passwords, OAuth is all the rage nowadays. And I, as the user, do not have to keep tokens in each app current.
It is also not 'entire gnome shell`. Just the required components.
here the required dependency list for control center on arch: accountsservice bolt colord-gtk4 cups-pk-helper gcr gnome-bluetooth-3.0 gnome-color-manager gnome-desktop-4 gnome-online-accounts gnome-settings-daemon gnome-shell gsettings-desktop-schemas gsound gtk4 libadwaita libgnomekbd libgtop libgudev libibus libmalcontent libmm-glib libnma-gtk4 libpwquality smbclient sound-theme-freedesktop udisks2 upower
while it may follow the letter of the philosophy is certainly doesn't feel like it's following the intent of it. the components form a sort of cyclic graph, where technically you can install any component but soon you'll find that you need all the others with no viable alternative component that will work reasonably well.
using these component outside of the DE feel like being a second class citizen that will be kicked out at any update, and then you'll have to scavenge for information from unofficial sources and the source code for what has changed that broke your setup.
Applications which are part of GNOME itself probably try to remain small and integrate well into GNOME e.g. Nautilus and Evolution. Applications which aren’t part of GNOME like Gimp or Geeqie rely only Gtk.
It just hurts if you want use a integrated GNOME-Application with a sole window-manager. That makes sense and we shouldn’t blame the developers for modularity and re-using.
I don’t know about Type-Ahead-Find in Nautilus, but typing to search in the file choosers is comically bad.
“Comically bad” here goes slightly beyond not working right to mildly destructive. I don’t know how the software pulls it off, but trying to open a folder found by Tracker search shows a nonsensical UI (no, I don’t want to “replace” the folder) and sometimes removes the x bit from the folder mode. I don’t even know how. A random chmod(2) call deep in glib? Why would the file chooser ever use chmod or fchmod?
Not really, even with Plugins everything is handled by Mutter - you don't have the modularity of Gnome 2 where you can switch out the panel, file browser or window manager as you please.
Fortunately Mate forked Gnome 2 to retain the old desktop.
Despite being in the package list for fedora(?) on recent versions, It fails to install and talk on the bug thread is just to remove the packages from the repo.
As for Xfce changing, that is to be expected since people's needs change over time. It is simply nice when those changes are gradual and not radical.
It's not clear at all - Wayland is in some ways a regression compared to X (try writing your own WM - tinyWM is 50 LOC, whereas the Wayland equivalent TinyWL is over 1000), and doesn't just "improve" X but changes paradigm entirely.
I'd like to see [Arcan](https://www.arcan-fe.com) be the future, it seems more elegant than Wayland.
Say what now? Gnome 3 is such a shitshow that I switched to XFCE because of it.
I only miss 3 column tiling on my ultra wide screen.
https://en.m.wikipedia.org/wiki/Who_Moved_My_Cheese%3F
[0] - https://www.amazon.com/Moved-Your-Cheese-Someone-Business/dp...
[1] - https://www.bkconnection.com/static/I_Moved_Your_Cheese_EXCE...
cheese moving, in this context, is not a force of nature. it's something that other people do upon you, and they could elect not to
This is not to detract from XFCE, which is a cool project with many strengths as well, and certainly deserving of enthusiastic users (doesn't matter which FOSS desktop you love, we all win).
I really, really wanted to like KDE as it's super powerful otherwise.
So I'd say it's worth checking back, and certainly the developers/contributors take your ask seriously enough to vote for it themselves.
You would probably have to change your keybindings a little but otherwise it's very similar... before the Wayland part
Switching from i3 to Sway kept 90% of the same config for me, changing only keybinds and output configuration.
Keybinds are mostly the same, just some arguments for 'bindsym' don't make sense with Wayland.
I did have to override args/env for some things to truly do Wayland, but that's shortening every day
It supports X too, but you'll find oddities with copying/pasting between native Wayland and X things
I'm increasingly tempted to grab a simple Wayland compositor and "bolt on" a minimalist X implementation directly on it to also allow X connections with just enough of the protocol implemented to allow running some simpler X WMs (but I'd love it if someone beat me to it).
For WMs with lots of fancy stuff it'd can take quite a bit of the X API to support, but a simple X WM doesn't typically use that many request types (I just looked at i3's source, and it's X interactions are pretty simple...
Wayland multi-seat + idle-inhibition HDR + variable refresh Fractional scaling (I think XFCE has some/all of this?)
We're just playing catchup to MacOS for over a decade, and soon enough Linux will have to compete with 3d desktop environments (Apple Vision Pro interface). I think we're almost to the point where the DE will be just a physics simulator (game engine) to help augment your reality.
Anyway, I still use XFCE on resource-limited hardware but Gnome has been the only option for a while because progress isn't being made by other DEs on these critical things (color, refresh, alpha-composition, and some wayland protocols missing in wlroots).
I'm just glad Gnome isn't the dependency hell it used to be, and has slimmed down. I really love what they've done with GJS but I believe there's a competing KDE bindings project.
</naive>
[1] even window maker could do it, I saw it was recently updated.
The move to Wayland is interesting to observe. On first glance it seems that moving to Wayland provides a load of burden on DEs that they never had before - and not just because of the work required to transition. And that obviously this is all Wayland's fault.
What I think is actually going on though is that we expect quite a rich feature set from a modern DE - exactly as you have listed.
We could never do most of this stuff on X, but Wayland enables it and then follows a load of work to get it all going.
In an ideal world there would be a nice clean abstraction boundary between compositor and DE so that this underlying work was shared between DEs. Maybe that is possible, but people who know what they're talking about seem to agree that the Wayland approach is the right way to go and I don't know enough to disagree. Plus, it makes some intuitive sense that your DE should know how windows share rendering space.
Not sure what's ideal about that. With Wayland the DE IS the compositor. There are a lot of benefits to that. I would hope basic compositing is a fairly small amount of code and many DEs could build on that - which I guess would your clean boundary even if it's in the same process.
It makes for complex, significant work for any Wayland DE, with less shared work. I don't think this is wrong - it seems this is the approach we need to get full featured DEs, it's just unfortunate that that's how reality has worked out.
Of all that, I only care about fractional scaling. If I wanted Apple-like experience, I'd be using a Mac. Imitating Mac experience on different hardware can be a worthy goal, but it's definitely not the only worthy goal.
Probably 25 to 50% of the usefulness of a monitor is that you can show your neighbor what's on it. Also 3D gives the user headaches often, and you have to wear these huge goggles.
Finally, I have enough trouble wrangling windows and getting them to behave with two dimensions. A third dimension just adds a place where the windows can go that I don't want them to go.
Gnome doesn't work well for me unless I find a bunch of half maintained bug-ridden extensions to fix the problems that have it has and it still doesn't work properly.
KDE is perfect. It used to be slow but now it's not. It's very configurable but doesn't need it most of the time.
XFCE for many including myself is the ideal, and is not playing catch up. At least I hope it isn't.
I switched to a Mac temporarily recently. I had to install an additional app just so that I could tile my windows in a basic way that is already supported by KDE, windows, pretty much everyone else. They have alpha compositing and all that, but it still felt like a step backward.
Not everyone uses a nonlinear video editor for a living.
I really start to think that the X11->Wayland migration is a bigger clusterfuck than Python2->3 was - even if we consider that a compositor migration is much bigger task than Python migration.
Not so luck for non-GNOME user
The laptop is flawless, and the desktop only has minor issues with display configuration (order and/or resolution) getting messed up sometimes when waking from sleep. I’m pretty sure that’s an Nvidia driver bug.
Anyways, it is 100% usable. To say otherwise suggests you haven’t actually tried using it within the past 2 years (at least)
IDK why, but the way you say it really annoys me. Like disregarding people's experiences because you have not faced the same issues.
Anyway, I try to shift to plasma wayland atleast every month. But there's always these weird graphical issues on nvidia (desktop) that ruin my experience, so i switch back to my x11 session. Even KDE has a page detailing the various problems in wayland https://community.kde.org/Plasma/Wayland_Showstoppers
I've been happy with Wayland for most of my Linux desktopping since 2018, so that was a ten year transition from first release to full adoption on my part.
And I'm sure we'll have X11 desktops around for various purposes ten years from now.
https://gitlab.freedesktop.org/wayland/wayland/-/issues/159 https://bugzilla.mozilla.org/show_bug.cgi?id=1743144
https://news.ycombinator.com/item?id=37480331
(Their main justification is to be resilient to server restarts, but from the client's perspective the two are the same.)
You're welcome to try and convince GTK devs to do the same.
And it takes time to replace an established protocol. Especially when you need to provide a feature-complete fallback for all the applications that are never going to do the switch.
For me that transition has been pain free. First I heard that X is going to be retired, then I saw some development note popping up here and there and then one day I was offered to log in to a Wayland session instead of a X session. I never experienced any problems I could directly attribute to Wayland.
I don't know why Wayland gets so much hate. To me it feels very much like the systemd hate: I don't know why this needs to change; I was happy after all. I don't want to learn about a new thing, so I'm angry.
Yes, it's a very similar situation; in both cases people are really fond of pretending that the only reason you could possibly object is that you hate change just because, while ignoring the actual regressions that it's causing. For instance, Wayland does not support (and probably never will support) some accessibility tools that make my life much easier (because the desktop must be secured against programmatic manipulation).
Nobody is taking X away. You can still run any DE and any application on X if you want to. You're not being restricted in your ability to run applications, quite the contrary; your are being given more options. So even if your use-case is not yet fully supported on Wayland, why hat on it? No one is taking anything away.
But yeah; ever since Sun stopped founding it, the accessibility situation on Linux has been dire.
That's unfortunately incorrect; so far Waydroid is the only program I've hit that explicitly requires Wayland, but I expect the list to grow with time.
> So even if your use-case is not yet fully supported on Wayland, why hat on it? No one is taking anything away.
Because it's abundantly clear that a noticeable set of devs and maintainers would really like to take it away, or at least refuse to support it (if there's a difference); see ex. https://social.treehouse.systems/@marcan/110354541574112092 where the lead dev on Asahi Linux seems ready to drop Xorg completely until someone points out a11y problems with Wayland, or https://www.phoronix.com/news/Fedora-40-KDE-Plasma-6-Plan for Fedora looking to drop KDE+X11.
Perhaps you haven't experienced it yourself, but systemd and Wayland have both caused a lot of unjustifiable problems for a lot of people.
That's where the widespread displeasure with them comes from.
It has nothing to do with dealing with change itself or learning something new.
If systemd and Wayland had brought me some tangible benefits, without also bringing me significant pain, then I'd be perfectly happy adopting them like I frequently do for other new-to-me software that makes my life better.
Unfortunately, that's not reality. For example, I've had to deal with far too many Linux installations that no longer boot thanks to systemd (or one of its many components) unexpectedly breaking in one way or another, often after what should be routine updates.
I've never had any success with the Wayland implementations I've tried, either. They've performed horribly on the computers of mine that I've tried them on, to the point of being pretty much unusable. A default installation of X on the same Linux installations works much better and is completely usable, however.
Based on all of the mailing list emails, forum postings, chat logs, bug reports, articles, and other online material that I've seen while trying to sort out such problems with systemd or Wayland, it's clear to me that I'm not the only one experiencing such troubles.
Even if I hadn't experienced such problems, neither systemd nor Wayland would benefit me in any meaningful way. At best, they're merely replacing what I've already been using for years or even decades, rather than improving upon them.
the more important thing is ... not a lot of people stepped up to maintain the old ways. if they are so superior, why isn't there a big group doing it?
...
that said, yes, systemd is crap, it's an endless pile of C instead of the previous [ba]sh bonanza, but it works, and it does a lot of things, and the maintainers are active and doing a lot of good things. plus it's finally standardized across distros.
and any talk about Wayland or X is completely irrelevant as the bugs that frustrate users are not in the protocols, all of them are in the implementations. I, like many starry eyed nix users, motivated to grow the bazaar [had many attempts at contributing] by opening issues, reporting bugs, trying to debug stuff, using beta/dev/nightly/canary/RC stuff ... but it did not make much of a difference. there's just not enough dev bandwidth to deal with even trivial stuff.
I mean it's sometimes* after wake up it's impossible to interact with the Gnome lockscreen with the keyboard unless first clicking on it with the mouse, on Xfce sometimes after opening the lid the screen is visible, and on KDE ... well, on KDE I don't even know what bug I tried to report, but no, fuck Bugzilla.
... and of course I could go on.And why these problems happen? Because the stack is ossified as fuck, because complexity is through the roof (due to hardware frontrunning the whole show by a (?) decade), and because OS developers being, well, folks who in their infinite wisdom stick to C and C++ and even introducing JS to the stack. (And many people remember when Ballmer-peak Microsoft tried to move to something memory safe, but couldn't... because "it was too hard". Yeah, just hacking everything together somehow is always the smart solution.)
I have used it for 7 years and I love it !
May God keep away animations from XCFE allways !
The only thing I don't like is thunar freezing often when doing long blocking IO operations...
Probably the main thing I'm missing from KDE is being able fo use Super+Number to switch between windows, i.e. Super+1 switches to the window at the first position in the taskbar, etc.. I've been searching around, but haven't found anything that'd be 100%. Would anyone happen to have a solution by any chance?
I switched to xfce not so long ago after almost 15 years of using KDE for that slow pace exactly. I had small problems and annoyances with KDE on nvidia for a long time but it got worse over time and reached a breaking point lately. Not even talking about Wayland.
Anyways, I am happy to have a rock solid and stable alternative like xfce.
I just use whatever GNOME offers and maybe 1-2 extensions. A few months ago I switched from Fedora to Debian 12 and barely noticed it. Thanks to GNOME and systemd, which I hate independently for various reasons.
I do feel like a sellout (but not getting paid).
Gnome made me deviate from the happy path with 3, I switched to where I was happy again, and haven't looked back since.
:shrug:
- It is not clear yet which Xfce release will target a complete Xfce Wayland transition (or if such a transition will happen at all).
- We do not have the resources to maintain our own Wayland compositor
This should tell you everything. Since the Wayland ecosystem is extremely developer hostile it cements the KDE/GNOME duopoly and eliminates the long tail. XFCE might maybe make the push to Wayland but after that that's it. The rest of the tail is dead.
It's usually a lot easier to make a compositor/WM with unusual or innovative behavior on the Wayland stack than it was with X11 in general, as far less behavior is presumed/baked-into either the display server or the existing applications. For example, apps not being able to introspect or manipulate their global coordinates also means the compositor can arrange them however it wants without breaking app assumptions, which enables fancy new layouts.
There's prominent libraries that make compositor development easier, for example wlroots and QtWayland -- XFCE is also using wlroots. "Punt it to a library" isn't radically different from "punt it to Xorg", even if the slicing is a little different.
The tail looks alive and well.
That's a reasonable expectation, but it turns out the slicing does matter. For example: With Xorg, setxkbmap will always work to change the keyboard layout on the fly. Now, wlroots does support configuring the keyboard layout, but it turns out the compositor has to actually hook that functionality up, so if I try out a new compositor that looks neat, I can quickly discover that there's actually literally no way to change the keyboard layout because the developer hasn't gotten around to adding that yet. This is not a hypothetical example.
Now get off my lawn.
You know you're behind the curve when even Xfce is ahead of you.