I hope that XFCE remains a solid lightweight desktop option. I've become a huge fan of KDE over the past couple of years, but it certainly isn't what you would consider lightweight or minimal.
Personally, I'm a big proponent of Wayland and not big Rust detractor, so I don't see any problem with this. I do, however, wonder how many long-time XFCE fans and the folks who donated the money funding this will feel about it. To me the reasoning is solid: Wayland appears to be the future, and Rust is a good way to help avoid many compositor crashes, which are a more severe issue in Wayland (though it doesn't necessarily need to be fatal, FWIW.) Still I perceive a lot of XFCE's userbase to be more "traditional" and conservative about technologies, and likely to be skeptical of both Wayland and Rust, seeing them as complex, bloated, and unnecessary.
Of course, if they made the right choice, it should be apparent in relatively short order, so I wish them luck.
> Still I perceive a lot of XFCE's userbase to be more "traditional" and conservative about technologies, and likely to be skeptical of both Wayland and Rust, seeing them as complex, bloated, and unnecessary.
Very long time (since 2007) XFCE user here. I don't think this is accurate. We want things to "just work" and not change for no good reason. Literally no user cares what language a project is implemented in, unless they are bored and enjoy arguing about random junk on some web forum. Wayland has the momentum behind it, and while there will be some justified grumbling because change is always annoying, the transition will happen and will be fairly painless as native support for it continues to grow. The X11 diehards will go the way of the SysV-init diehards; some weird minority that likes to scream about the good old days on web forums but really no one cares about.
There are good reasons to switch to Wayland, and I trust the XFCE team to handle the transition well. Great news from the XFCE team here, I'm excited for them to pull this off.
I used XFCE for a long time and I very much agree. it just works, and is lightweight. I use KDE these days but XFCE would be my second choice.
> The X11 diehards will go the way of the SysV-init diehard
I hope you are not conflating anti-systemD people with SysV init diehards? As far as I can see very few people want to keep Sysv init, but there are lots who think SystemD init is the wrong replacement, and those primarily because its a lot more than an init system.
In many ways the objects are opposite. People hate system D for being more than init, people hate Wayland for doing less than X.
Edit: corrected "Wayland" to "XFCE" in first sentence!
Not sure I agree here, assuming you mean "... than X11". With Wayland, you put your display code, input-handling code, compositor code, session-handling code, and window-management code all in the same process. (Though there is a Wayland protocol being worked on to allow moving the WM bits out-of-process.)
With X11, display and input-handling are in the X server, and all those other functions can be in other processes, communicating over standard interfaces.
> you put your display code, input-handling code, compositor code, session-handling code, and window-management code all in the same process
That's an implementation detail. You can absolutely separate one out from the other and do IPC - it just doesn't make much sense to do so for most of these.
The only one where I see it making sense is the window manager, which can simply be an extension/plugin either in a scripting language or in wasm or whatever.
It's not an implementation detail that X11 specifies interfaces between those separate components and Wayland does not - X11 is designed for for the window manager being separate from the display server, Wayland is designed for them being the same.
I do not have a strong opinion about Xorg vs Wayland. My only real concern is that it might make it harder for the BSDs but that seems to be being dealt with. I do like being able to use X over the nextwork but that is a problem that can be solved.
I do dislike System D for two reasons. One is exactly because it s a monolith and, in effect, an extension of the OS. The other is the attitude of the developers which becomes very evident if you browser the issues.
How is Wayland more modular? It conflates the window manager, the compositor, and the display server, all into a single component that must be replaced as a single unit. This kind of new conflation is exactly what people dislike about systemd.
It's less monolithic in the sense that instead of one creaky unmaintainable ancient mass of software doing the actual rendering gruntwork there are now five (and counting) somewhat incompatible slick untested new masses of software doing it in slightly different ways that application developers have to worry about. It's kind of a pick your poison situation.
IME it's always best to read any claims of "unmaintainable" as "not as fun as designing something new". Nothing is truly unmaintainable if the will is there.
I know OpenBSD's fork of it is being maintained just fine even though they've declared it feature-complete (which for some reason is anathema to a lot of people).
If Rust has one weakness right now, it's bindings to system and hardware libraries. There's a massive barrier in Rust communicating with the outside ecosystem that's written in C. The definitive choice to use Rust and an existing Wayland abstraction library narrows their options down to either creating bindings of their own, or using smithay, the brand new Rust/Wayland library written for the Cosmic desktop compositor. I won't go into details, but Cosmic is still very much in beta.
It would have been much easier and cost-effective to use wlroots, which has a solid base and has ironed out a lot of problems. On the other hand, Cosmic devs are actively working on it, and I can see it getting better gradually, so you get some indirect manpower for free.
I applaud the choice to not make another core Wayland implementation. We now have Gnome, Plasma, wlroots, weston, and smithay as completely separate entities. Dealing with low-level graphics is an extremely difficult topic, and every implementor encounters the same problems and has to come up with independent solutions. There's so much duplicated effort. I don't think people getting into it realize how deceptively complex and how many edge-cases low-level graphics entails.
> using smithay, the brand new Rust/Wayland library
Fun fact: smithay is older than wlroots, if you go by commit history (January 2017 vs. April 2017).
> It would have been much easier and cost-effective to use wlroots
As a 25+ year C developer, and a ~7-year Rust developer, I am very confident that any boost I'd get from using wlroots over smithay would be more than negated by debugging memory management and ownership issues. And while wlroots is more batteries-included than smithay, already I'm finding that not to be much of a problem, given that I decided to base xfwl4 on smithay's example compositor, and not write one completely from scratch.
Thanks for the extra info. I'm glad it hasn't turned out to be much of an issue. I've looked at your repository and it seems to be off to a great start.
Personally, I'm anxious to do some bigger rust projects, but I'm usually put off by the lack of decent bindings in my particular target area. It's getting better, and I'm sure with some time the options will fill out more.
There really isn't a "massive barrier" to FFI. Autogenerate the C bindings and you're done. You don't have to wrap it in a safe abstraction, and imo you shouldn't.
This. It is somewhat disheartening to hear the whole interop-with-C with Rust being an insurmountable problem. Keeping the whole “it’s funded by the Government/Google etc” nonsense aside: I personally wish that at least a feeble attempt would be made to actually use the FFI capabilities that Rust and its ecosystem has before folks form an opinion. Personally - and I’m not ashamed to state that I’m an early adopter of the language - it’s very good. Please consider that the Linux kernel project, Google, Microsoft etc went down the Rust path not on a whim but after careful analysis of the pros and cons. The pros won out.
> This. It is somewhat disheartening to hear the whole interop-with-C with Rust being an insurmountable problem.
I have done it and it left a bad taste in my mouth. Once you're doing interop with C you're just writing C with Rust syntax topped off with a big "unsafe" dunce cap to shame you for being a naughty, lazy programmer. It's unergonomic and you lose the differentiating features of Rust. Writing safe bindings is painful, and using community written ones tends to pull in dozens of dependencies. If you're interfacing a C library and want some extra features there are many languages that care far more about the developer experience than Rust.
> a big "unsafe" dunce cap to shame you for being a naughty, lazy programmer
You just have to get over that. `unsafe` means "compiler cannot prove this to be safe." FFI is unsafe because the compiler can't see past it.
> Once you're doing interop with C you're just writing C with Rust syntax
Just like C++, or go, or anything else. You can choose to wrap it, but that's just indirection for no value imo. I honestly hate seeing C APIs wrapped with "high level" bindings in C++ for the same reason I hate seeing them in Rust. The docs/errors/usage are all in terms of the C API and in my code I want to see something that matches the docs, so it should be "C in syntax of $language".
> a big "unsafe" dunce cap to shame you for being a naughty, lazy programmer
That's bizarrely emotional. It's a language feature that allows you to do things the compiler would normally forbid you from doing. It's there because it's sometimes necessary or expedient to do those things.
My point is that using C FFI is "the things the compiler would normally forbid you from doing" so if that's a major portion of your program then you're better off picking a different language. I don't dislike rust, but it's not the right tool for any project that relies heavily on C libraries.
> The X11 diehards will go the way of the SysV-init diehards; some weird minority
I upvoted your general response but this line was uncalled for. No need to muddy the waters about X11 -> Wayland with the relentlessly debated, interminable, infernal init system comparison.
> Literally no user cares what language a project is implemented in
This is only true most of the time - some languages have properties which "leak" to user.
Like if it's Java process, then sooner or later user will have to mess with launchers and -Xmx option.
Or if it's a process which has lots of code and must not crash, language matters. C or C++ would segfault on any sneeze. Python or Ruby or even Java would stay alive (unless they run out of memory, or hang due to a logic bug)
> The X11 diehards will go the way of the SysV-init diehards; some weird minority that likes to scream about the good old days on web forums but really no one cares about.
Being proud of how you are uncaring towards others is a sad state of affairs.
> Literally no user cares what language a project is implemented in
I think this is true but also maybe not true at the same time.
For one thing, programming languages definitely come with their own ecosystems and practices that are common.
Sometimes, programming languages can be applied in ways that basically break all of the "norms" and expectations of that programming language. You can absolutely build a bloated and slow C application, for example, so just using C doesn't make something minimal or fast. You can also write extremely reliable C code; sqlite is famously C after all, so it's clearly possible, it just requires a fairly large amount of discipline and technical effort.
Usually though, programs fall in line with the norms. Projects written in C are relatively minimal, have relatively fewer transitive dependencies, and are likely to contain some latent memory bugs. (You can dislike this conclusion, but if it really weren't true, there would've been a lot less avenues for rooting and jailbreaking phones and other devices.)
Humans are clearly really good at stereotyping, and pick up on stereotypes easily without instruction. Rust programs have a certain "feel" to them; this is not delusion IMO, it's likely a result of many things, like the behaviors of clap and anywho/Rust error handling leaking through to the interface. Same with Go. Even with languages that don't have as much of a monoculture, like say Python or C, I think you can still find that there are clusters of stereotypes of sorts that can predict program behavior/error handling/interfaces surprisingly well, that likely line up with specific libraries/frameworks. It's totally possible to, for example, make a web page where there are zero directly visible artifacts of what frameworks or libraries were used to make it. Yet despite that, when people just naturally use those frameworks, there are little "tells" that you can pick up on a lot of the time. You ever get the feeling that you can "tell" some application uses Angular, or React? I know I have, and what stuns me is that I am usually right (not always; stereotypes are still only stereotypes, after all.)
So I think that's one major component of why people care about the programming language that something is implemented in, but there's also a few others:
- Resources required to compile it. Rust is famously very heavy in this regard; compile times are relatively slow. Some of this will be overcome with optimization, but it still stands to reason that the act of compiling Rust code itself is very computationally expensive compared to something as simple as C.
- Operational familiarity. This doesn't come into play too often, but it does come into play. You have to set a certain environment variable to get Rust to output full backtraces, for example. I don't think it is part of Rust itself, but the RUST_LOG environment variable is used by multiple libraries in the ecosystem.
- Ease of patching. Patching software written in Go or Python, I'd argue, is relatively easy. Rust, definitely can be a bit harder. Changes that might be possible to shoehorn in in other languages might be harder to do in Rust without more significant refactoring.
- Size of the resulting programs. Rust and Go both statically link almost all dependencies, and don't offer a stable ABI for dynamic linking, so each individual Rust binary will contain copies of all of their dependencies, even if those dependencies are common across a lot of Rust binaries on your system. Ignoring all else, this alone makes Rust binaries a lot larger than they could be. But outside of that, I think Rust winds up generating a lot of code, too; trying to trim down a Rust wasm binary tells you that the size cost of code that might panic is surprisingly high.
So I think it's not 100% true to say that people don't care about this at all, or that only people who are bored and like to argue on forums ever care. (Although admittedly, I just spent a fairly long time typing this to argue about it on a forum, so maybe it really is true.)
Why does Wayland "feel like the future?" It feels like a regression to me and a lot of other people who have run into serious usability problems.
At best, it seems like a huge diversion of time and resources, given that we already had a working GUI. (Maybe that was the intention.) The arguments for it have boiled down to "yuck code older than me" from supposed professionals employed by commercial Linux vendors to support the system, and it doesn't have Android-like separation — a feature no one really wants.
The mantra of "it's a protocol" isn't very comforting when it lacks so many features that necessitate workarounds, leading to fragmentation and general incompatibility. There are plenty of complicated, bad protocols. The ones that survive are inherently "simple" (e.g., SMTP) or "trivial" (e.g., TFTP). Maybe there will be a successor to Wayland that will be the SMTP to its X400, but to me, Wayland seems like a past compromise (almost 16 years of development) rather than a future.
Wayland supports HDR, it's very easy to configure VRR, and it's fractional scaling (if implemented properly) is far superior to anything X11 can offer.
Furthermore, all of these options can be enabled individually on multiple screens on the same system and still offer a good mix-used environment. As someone who has been using HiDPI displays on Linux for the past 7 years, wayland was such a game changer for how my system works.
Fractional scaling for wayland is broken on a per app basis which feels strictly worse to me than it was before. Libre office currently is broken on wayland and works in x11
LibreOffice works for me on wayland lol. I don't know why you would wanna do fractional scaling on a per app basis whenever you got one screen. But, for your libreoffice woes, try using a different backend?
Which, because we're talking rendering and GPU and drivers, is incredibly frustrating, because if we're here, it's because the system doesn't have working GPU drivers, at which point, a misconfiguration is a crash and a power cycle and a "hope pstore managed to save something", and the hardware/software cursor settings getting lost somewhere-how.
I'm not trying to do it on a per app basis. I mean that some apps work and some don't. I should not be playing with rendering backends per app to get them working. If thats needed its broken.
People keep pushing KDE+Wayland to beginners either through recommendations or preconfigured stuff like bazzite. My experience is that the defaults in such a setup are broken and frustrating.
Even if you dislike Wayland, forwards-going development is clearly centred around it.
Development of X11 has largely ended and the major desktop environments and several mainstream Linux distributions are likewise ending support for it. There is one effort I know of to revive and modernize X11 but it’s both controversial and also highly niche.
You don’t have to like the future for it to be the future.
It's mostly coz nobody really wants to improve X11. I don't think there is many wayland features that would be impossible to implement in X11 it's just nobody wants to dig into crusty codebase to do it.
And sadly wayland decided to just not learn any lessons from X11 and it shows.
What do you mean nobody wants to improve X11? There were developers with dozens of open merge requests with numerous improvements to X11 that were being actively ignored/held back by IBM/Red Hat because they wanted Wayland, their corporate project, to succeed instead.
Reviewing PRs and merging them requires great effort, especially in case of a non-trivial behemoth like X. Surely if all these merge requests were of huge value, someone could have forked the project and be very happy with all the changes, right?
Not having enough maintainers, and some design issues that can't be solved are both reasons why X was left largely unmaintained.
> Surely if all these merge requests were of huge value
There were a lot of MRs with valuable changes however Red Hat wanted certain features to be exclusive to Wayland to make the alternative more appealing to people so they actively blocked these MRs from progressing.
> someone could have forked the project and be very happy with all the changes, right?
That's precisely what happened, one of the biggest contributors and maintainers got bullied by Red Hat from the project for trying to make X11 work and decided to create X11Libre (https://github.com/X11Libre/xserver) which is now getting all these fancy features that previously were not possible to get into X11 due to Red Hat actively sabotaging the project in their attempt to turn Linux into their own corporate equivalent of Windows/macOS.
We’re accustomed to "the future" connoting progress and improvement. Unfortunately, it isn’t always so (no matter how heavily implied). Just that it’s literally expected to be the future state if matters.
Wayland was the first display system on Linux I've used that just worked perfectly right out of the box on a bog standard Intel iGPU across several machines. I think that is a big draw for a lot of people like myself who just want to get things done. For me X11 represents the past through experience I had when I had to tinker with the X11 config file to get basic stuff like video playback to work smoothly without tearing. My first Wayland install was literally a "wow this is the future of Linux" for me quite honestly when I realised everything just worked without even a single line of config. I would recommend a Wayland distro like Debian to the average computer user knowing Wayland just works -- prior to Wayland I'd be like "well Linux is great but if you like watching YouTube you'll need to add a line to your xorg config to trun on the thingy that smoothes out video playback on Intel iGPUs". Appreciate others have different perpectives -- I come from the POV of someone who likes to install a OS and have all the basic stuff working out of the box.
It is many years, I guess close to a decade, since I needed to change X config manually. I still find the odd rough edge in Wayland (the most recent was failing screenshots with KDE).
This argument is actually backwards: one of the goals of the wayland project is to draw development away from X. If wayland didn't exist, people would have worked on X11 a lot more.
This question sounds to me like you suspect some outright evil getting projected here. That would go too far. The wayland project tried to get the support of X developers early so that they could become a sort of "blessed" X successor early on. Plenty of earlier replacement attempts have failed because they couldn't get bigger community support, so this had to be part of a successful strategy. Any detrimental effects on X from that move were never a direct goal, as far as I am aware, just a consequence.
This isn't quite right? Wayland was literally created by an X11 developer who got two more main X11 developers in. It's a second system, not a competitor as such.
Yes, I do interpret your “draw development away from X” as suggesting an attempt to damage X (sorry if I misinterpreted your post, but I do think my interpretation was not really that unreasonable).
This “blessed successor” without and detrimental effects as a main goal: that’s pretty close to my understanding of the project. IIRC some X people were involved from the beginning, right?
Wanting developers to switch projects doesn't have to be malicious, in fact personally i doubt there were any bad intentions in place, the developers of Wayland most likely think they're doing the right thing.
That’s a fork, which is fine. But for example, users from most mainstream distros will have to compile it themselves.
I guess we’ll see if that development is ever applied to the main branch, or if it supplants the main X branch. At the moment, though… if that’s the future of X, then it is fair to be a little bit unsure if it is going to stick, right?
That seems pretty interesting. I guess it relies on BSD plumbing though?
Funny enough, the my first foray into these sort of operating systems was BSD, but it was right when I was getting started. So I don’t really know which of my troubles were caused by BSD being tricky (few probably), and which were caused by my incompetence at the time (most, probably). One of these days I’ll try it again…
Yup, "pledge" is one of my BSD envies. Namespaces and unshare are significantly more complex and we're still told not to use them as a security barrier (which is explicitly in scope for pledge).
I've been on and off linux desktops since the advent of Wayland. Unsure of the actual issues people run into at this point outside of very niche workflows or applications, to which, there are X11 fallbacks for.
Also, by "commercial linux vendors", you do realize Wayland is directly supported (afaik, correct me if wrong) by the largest commercial linux contributors, Red Hat, Canoncial. They're not simply 'vendors'.
> Unsure of the actual issues people run into at this point outside of very niche workflows or applications, to which, there are X11 fallbacks for.
I don't know if others have experienced this but the biggest bug I see in Wayland right now is sometimes on an external monitor after waking the computer, a full-screen electron window will crash the display (ie the display disconnects).
I can usually fix this by switching to another desktop and then logging out and logging back in.
Such a strange bug because it only affects my external monitor and only affects electron apps (I notice it with VSCode the most but that's just cause I have it running virtually 24/7)
If anyone has encountered this issue and figured out a solution i am all ears.
This is probably worth reporting. I don't think I've ever heard or ran into something like that before. Most issues I ran into during the early rollout of Wayland desktop environments was broken or missing functionality in existing apps.
> it doesn't have Android-like separation — a feature no one really wants.
It's certainly a feature I want. Pretty sure I'm not alone in wanting isolation between applications--even GUI ones. There's no reason that various applications from various vendors shouldn't be isolated into their own sandboxes (at least in the common case).
There is a big reason: It impedes usability, extensibility and composability. If you sandbox GUI applications then the sandbox needs to add support for any interaction between them or they will just not be possible - and to fully support many advanced interactions like automation you will essentially have to punch huge holes in the sandbox anyway.
Meanwhile the advantages of sandboxing are pretty much moot in an open source distro where individual applications are open and not developed by user hostile actors.
Yes, sandboxing impedes those things. But I assume you're not advocating against sandboxing in general, right?
Starting with a sandbox and poking holes/whitelisting as-needed is a good way to go. Whitelisting access on a per-application basis is a pragmatic way to do this, and Flatpak with Wayland gives a way to actually implement this. It's imperfect, but it's a good start.
Preventing keylogging is a good, concrete example here. There's no reason some random application should be able to see me type out the master password in my password manager.
Likewise, there is no reason that some other application should be able to read ~/.bash_history or ~/.ssh/. The browser should limit itself to ~/Downloads. Etc.
> Meanwhile the advantages of sandboxing are pretty much moot in an open source distro where individual applications are open and not developed by user hostile actors.
Defense in depth. Belt and suspenders. I do trust the software I run to some degree, and take great care in choosing the software. But it's not perfect. Likewise, I take care to use sandboxing features whenever I can, acknowledging that they sometimes must have holes poked in them. But the Swiss cheese model is generally a good lens: https://en.wikipedia.org/wiki/Swiss_cheese_model
If we weren't concerned with belt and suspenders and could rely on applications being developed by non-hostile actors, then we could all run as root all the time! But we don't do that--we try to operate according to least-privilege and isolate separate tasks as much as is practical. Accordingly, technologies which allow improved isolation with zero or minimal impact to functionality are strictly a good thing, and should be embraced as such.
> given that we already had a working GUI. (Maybe that was the intention.)
Neither X11 nor Wayland provide a GUI. Your GUI is provided by GTK or QT or TCL or whatever. X11 had primitive rendering instructions that allowed those GUIs to delegate drawing to a central system service, but very few things do that anymore anyway. Meaning X11 is already just a dumb compositor in practice, except it's badly designed to be a dumb compositor because that wasn't its original purpose. As such, Wayland is really just aligning the protocol to what clients actually want & do.
- Having a single X server that almost everyone used lead to ossification. Having Wayland explicitly be only a protocol is helping to avoid that, though it comes with its own growing pains.
- Wayland-the-Protocol (sounds like a Sonic the Hedgehog character when you say it like that) is not free of cruft, but it has been forward-thinking. It's compositor-centric, unlike X11 which predates desktop compositing; that alone allows a lot of clean-up. It approaches features like DPI scaling, refresh rates, multi-head, and HDR from first principles. Native Wayland enables a much better laptop docking experience.
- Linux desktop security and privacy absolutely sucks, and X.org is part of that. I don't think there is a meaningful future in running all applications in their own nested X servers, but I also believe that trying to refactor X.org to shoehorn in namespaces is not worth the effort. Wayland goes pretty radical in the direction of isolating clients, but I think it is a good start.
I think a ton of the growing pains with Wayland come from just how radical the design really is. For example, there is deliberately no global coordinate space. Windows don't even know where they are on screen. When you drag a window, it doesn't know where it's going, how much it's moving, anything. There isn't even a coordinate space to express global positions, from a protocol PoV. This is crazy. Pretty much no other desktop windowing system works this way.
I'm not even bothered that people are skeptical that this could even work; it would be weird to not be. But what's really crazy, is that it does work. I'm using it right now. It doesn't only work, but it works very well, for all of the applications I use. If anything, KDE has never felt less buggy than it does now, nor has it ever felt more integrated than it does now. I basically have no problems at all with the current status quo, and it has greatly improved my experience as someone who likes to dock my laptop.
But you do raise a point:
> It feels like a regression to me and a lot of other people who have run into serious usability problems.
The real major downside of Wayland development is that it takes forever. It's design-by-committee. The results are actually pretty good (My go-to example is the color management protocol, which is probably one of the most solid color management APIs so far) but it really does take forever (My go-to example is the color management protocol, which took about 5 years from MR opening to merging.)
The developers of software like KiCad don't want to deal with this, they would greatly prefer if software just continued to work how it always did. And to be fair, for the most part XWayland should give this to you. (In KDE, XWayland can do almost everything it always could, including screen capture and controlling the mouse if you allow it to.) XWayland is not deprecated and not planned to be.
However, the Wayland developers have taken a stance of not just implementing raw tools that can be used to implement various UI features, but instead implement protocols for those specific UI features.
An example is how dragging a window works in Wayland: when a user clicks or interacts with a draggable client area, all the client does is signal that they have, and the compositor takes over from there and initiates a drag.
Another example would be how detachable tabs in Chrome work in Wayland: it uses a slightly augmented invocation of the drag'n'drop protocol that lets you attach a window drag to it as well. I think it's a pretty elegant solution.
But that's definitely where things are stuck at. Some applications have UI features that they can't implement in Wayland. xdg-session-management for being able to save and restore window positions is still not merged, so there is no standard way to implement this in Wayland. ext-zones for positioning multi-window application windows relative to each-other is still not merged, so there is no standard way to implement this in Wayland. Older techniques like directly embedding windows from other applications have some potential approaches: embedding a small Wayland compositor into an application seems to be one of the main approaches in large UI toolkits (sounds crazy, but Wayland compositors can be pretty small, so it's not as bad as it seems) whereas there is xdg-foreign which is supported by many compositors (Supported by GNOME, KDE, Sway, but missing in Mir, Hyprland and Weston. Fragmentation!) but it doesn't support every possible thing you could do in X11 (like passing an xid to mpv to embed it in your application, for example.)
I don't think it's unreasonable that people are frustrated, especially about how long the progress can take sometimes, but when I read these MRs and see the resulting protocols, I can't exactly blame the developers of the protocols. It's a long and hard process for a reason, and screwing up a protocol is not a cheap mistake for the entire ecosystem.
But I don't think all of this time is wasted; I think Wayland will be easier to adapt and evolve into the future. Even if we wound up with a one-true-compositor situation, there'd be really no reason to entirely get rid of Wayland as a protocol for applications to speak. Wayland doesn't really need much to operate; as far as I know, pretty much just UNIX domain sockets and the driver infrastructure to implement a WSI for Vulkan/GL.
Thanks a lot for an actually constructive comment on Wayland! The information tends to be lost in all the hate.
I understand the frustration, but I see a lot of "it's completely useless" and "it's a regression", though to me it really sounds like Wayland is an improvement in terms of security. So there's that.
The fact that this post is downvoted into grayness while lazy hateful rants aren't shows just how rotten HN community has gotten around opensource these days :/
Do you know if global shortcuts are solved in a satisfactory way, and if there easy mechanism for one application to query wayland about other applications.
One hack I've made a while ago was to bind win+t command to a script that queried the active window in the current workspace, and based on a decision opened up a terminal at the right filesystem location, with a preferred terminal profile.
All I get from llms is that dbus might be involved in gnome for global shortcuts, and when registering global shortcuts in something like hyperland app ids must be passed along, instead of simple scripts paths.
Currently, the Wayland protocol itself doesn't have a standard solution to global shortcuts. Instead, it's being pushed to the XDG Desktop Portal API, under the org.freedesktop.portal.GlobalShortcuts service:
This should work with Hyprland provided that you are using xdg-desktop-portal-hyprland, as it does indeed have an implementation of GlobalShortcuts.
I'm not sure if this API is sufficient for your needs, or if it is too much of a pain to use. Like many Wayland things, it prescribes certain use cases and doesn't handle others. The "configure" call seems to rely on xdg-foreign-unstable-v2 support, but AFAIK Hyprland doesn't support this protocol, so I have no idea what you're supposed to do on Hyprland for this case.
I am sorry to see developers have to deal with things in a relatively unfinished state, but such is the nature of the open source desktop.
Thanks for the insight, I really appreciate it. I don't use hyperland (just what came up as brief research). Xfce generally has simple and legible code, hopefully this wayland compositor will be just as hackable and tweakable for my needs.
> xdg-session-management for being able to save and restore window positions
> is still not merged, so there is no standard way to implement this in Wayland
For me, this is a real reason not to want to be forced to use Wayland. I'm sure the implementation of Wayland in xfce is a long time off, and the dropping of Xwindows even further off, so hopefully this problem will have been solved by then.
It's a downgrade that we have no choice but to accept in order to continue using our machines. Anyone familiar with Microsoft or Apple already knows that's the future.
They're trying to "nudge" everyone. Major desktop environments and entire distributions are removing X11 support to varying degrees. A lot of this is because they can't get their adoption rates above about half due to various broken workflows or simply user preference.
They intentionally don't want you to keep using X11, and they'll keep turning up the heat on the pot until we're all boiling.
Gnome just removed the middle-click paste option. Is that because they fixed the clipboard situation on Linux, and there's a universal, unambiguous way of cut and paste that works across every application? No. It's because middle-click to paste is an "X-ism." This is just demagoguery and unserious.
> Gnome just removed the middle-click paste option. Is that because they fixed the clipboard situation on Linux, and there's a universal, unambiguous way of cut and paste that works across every application? No. It's because middle-click to paste is an "X-ism." This is just demagoguery and unserious.
They disabled it by default. You can enable it if you want.
Once again, Gentoo Linux proves (somewhat regrettably) to be one of the best Linux distros out there. OpenRC and Xorg as defaults, with SystemD and Wayland as supported options is quite a lovely way to do things.
> Gnome just removed the middle-click paste option.
Gnome removes useful things all the time. "The Gnome folks do something user-hostile just because they feel like it" isn't news; that's been going on for decades. This habit of theirs is a big reason why I've been using KDE for a very long time.
Unfortunately I don't think Gentoo will keep X11 support in e.g. KDE once its dropped upstream (which is already announced), they don't have the manpower for that.
And KDE itself is also not the bastion of user choice it once was, even if they haven't yet gone quite as hostile as Gnome.
> Unfortunately I don't think Gentoo will keep X11 support in e.g. KDE once its dropped upstream...
IIRC, the only part that's dropping X11 support is Plasma. From [0]:
There are currently no plans to drop X11 support in KDE applications outside of Plasma.
This change only concerns Plasma’s X11 login session, which is what’s going away.
I don't really care about Plasma; a taskbar to house a system tray and clock is nice, as is desktop wallpaper, but I don't particularly care about that stuff. I use very little of KDE: kwin, krunner, kmix, kcalc, okular, dolphin (rarely), and whatever handles the global keyboard shortcuts.
Hell, on my ~twenty-year-old computer I don't use Plasma because it's a resource hog, but I still use KDE.
That's fair, but I would also read it as a sign of things to come for the rest. If you can't run full KDE on X11 there will not be many KDE developers caring about X11 support. KWin for example has already gained many bugs on X11 that I expect to never be fixed. And now KWin for X11 is split into a separate project which will hopefully mean fewer further regressions but probably also not much further development which means bitrot as things around it change.
> That's fair, but I would also read it as a sign of things to come for the rest.
Given this statement from the announcement that I linked to previously
The Plasma X11 session will be supported by KDE into early 2027.
We cannot provide a specific date, as we’re exploring the possibility of shipping some extra bug-fix releases for Plasma 6.7. The exact timing of the last one will only be known when we get closer to its actual release, which we expect will be sometime in early 2027.
I expect that I will get at least a year's notice before they stop actively working on the rest of the parts of KDE that interact with X11... whenever that ends up being. A year is more than enough time to find replacements for things that might eventually stop working one day.
Were I sixteen, I'd be very excited to preemptively move to something else. Now? The folks who work on it say that they'll keep it working for the forseeable future, and their behavior suggests that I'll get ample notice before they stop working on it.
The software in question works now (AFAICT) and will continue to work for quite a while. I am likely to get a significant amount of warning before they stop working on the software. I see no reason to switch. I have much better things to do with my time.
Yeah, I am staunch proponent of "don't try to fix what is not broken". Current XFCE is fast, light-weight, usable and works fine without major issues. While I don't fully understand the advantages / disadvantages of XFCE using Wayland instead of X, if, as someone else pointed out here on HN, running XFCE on Wayland is going to make it slower, it means these developers will be crippling one of XFCE's strongest feature. In that case other minor advantages seems pointless to users like me.
> running XFCE on Wayland is going to make it slower
Citation. None of the other desktops have slowed with Wayland, and gaming is as fast as, if not marginally faster on KDE/Gnome with Wayland vs LXDE on X.
Latency and throughput are very different things. However, it's worth noting that the comparison here is with and without compositing. If you were using compositing already on X11 (I believe XFCE offers it with "Desktop Effects" or something to that tune) then you've already been eating compositing latency, and you should actually get less latency in some situations.
But as far as it performing worse overall, I don't think that would be expected. Compositing itself does lean more on hardware acceleration to provide a good experience, though, so if you compare it on a machine that has no hardware accelerated graphics with compositing disabled, then it really would be worse, yeah.
Little misconception here (beware i'm using xlibre and causal user). On X11 you can find two mechanisms which can be called compositor :
1st: "enable display compositing" option - this one increases latency as every window draw need go though compositor application (in nutshell it exchanging opengl textures - only synchronization messages goes over "wire")
2nd: the Xserver rendering pipeline compositor, this one goes with modesetting (intel, amdgpu) driver TearFree option - almost everything inside X11 server in OpenGL textures and compositor perform direct blending to screen (including direct scanout).
What I want to tell, on modern X (there are merge requests for Xorg server to modesetting driver, amdgpu have this code) with TearFree enabled you by default optimal hardware acceleration - there comes lower latency
Long-time XFCE user here. We care that stuff works the same, we appreciate how much work it is to achieve that when the world is changing out from under you, and we appreciate that XFCE understands this and cares about it. Being in Rust is not a concern.
Wayland has lots of potential, but it's far from ready to replace X11, especially in multitasking environments. XFCE is taking their time, because their community is more very concerned stability.
I predict that XFCE will default to X11 until Wayland has reached broad feature parity, then default to Wayland but keep X11 support until the last vestages of incompatibility are delt with.
There's no reason that this wouldn't be accepted by their community, and it should be lighter weight, in the end.
I am an XFCE user since many years, and am pretty decidedly in the "traditional and conservative about technologies" camp, and I think this is neat and just fine and dandy -- as long as they're not in a hurry to depreciate X11. Whenever I eventually have to go Wayland I would like to continue to use XFCE, so thumbs up for doing the work.
Afaik there exists only X11 and Wayland, and X11 is dying if not dead. And for rust I don't see why a desktop user would be concerned by the language used as long as it is good enough.
Personally, I'm a big proponent of Wayland and not big Rust detractor, so I don't see any problem with this. I do, however, wonder how many long-time XFCE fans and the folks who donated the money funding this will feel about it. To me the reasoning is solid: Wayland appears to be the future, and Rust is a good way to help avoid many compositor crashes, which are a more severe issue in Wayland (though it doesn't necessarily need to be fatal, FWIW.) Still I perceive a lot of XFCE's userbase to be more "traditional" and conservative about technologies, and likely to be skeptical of both Wayland and Rust, seeing them as complex, bloated, and unnecessary.
Of course, if they made the right choice, it should be apparent in relatively short order, so I wish them luck.