This post is in part a response to an aspect of Nate’s post “Does Wayland really break everything?“, but also my reflection on discussing Wayland protocol additions, a unique pleasure that I have been involved with for the past months1.
Some facts
Before I start I want to make a few things clear: The Linux desktop will be moving to Wayland2 – this is a fact at this point (and has been for a while), sticking to X11 makes no sense for future projects. From reading Wayland protocols and working with it at a much lower level than I ever wanted to, it is also very clear to me that Wayland is an exceptionally well-designed core protocol, and so are the additional extension protocols (xdg-shell & Co.). The modularity of Wayland is great, it gives it incredible flexibility and will for sure turn out to be good for the long-term viability of this project (and also provides a path to correct protocol issues in future, if one is found). In other words: Wayland is an amazing foundation to build on, and a lot of its design decisions make a lot of sense!
The shift towards people seeing “Linux” more as an application developer platform, and taking PipeWire and XDG Portals into account when designing for Wayland is also an amazing development and I love to see this – this holistic approach is something I always wanted!
Furthermore, I think Wayland removes a lot of functionality that shouldn’t exist in a modern compositor – and that’s a good thing too! Some of X11’s features and design decisions had clear drawbacks that we shouldn’t replicate. I highly recommend to read Nate’s blog post, it’s very good and goes into more detail. And due to all of this, I firmly believe that any advancement in the Wayland space must come from within the project.
But!
But! Of course there was a “but” coming 😉 – I think while developing Wayland-as-an-ecosystem we are now entrenched into narrow concepts of how a desktop should work. While discussing Wayland protocol additions, a lot of concepts clash, people from different desktops with different design philosophies debate the merits of those over and over again never reaching any conclusion (just as you will never get an answer out of humans whether sushi or pizza is the clearly superior food, or whether CSD or SSD is better). Some people want to use Wayland as a vehicle to force applications to submit to their desktop’s design philosophies, others prefer the smallest and leanest protocol possible, other developers want the most elegant behavior possible. To be clear, I think those are all very valid approaches.
But this also creates problems: By switching to Wayland compositors, we are already forcing a lot of porting work onto toolkit developers and application developers. This is annoying, but just work that has to be done. It becomes frustrating though if Wayland provides toolkits with absolutely no way to reach their goal in any reasonable way. For Nate’s Photoshop analogy: Of course Linux does not break Photoshop, it is Adobe’s responsibility to port it. But what if Linux was missing a crucial syscall that Photoshop needed for proper functionality and Adobe couldn’t port it without that? In that case it becomes much less clear on who is to blame for Photoshop not being available.
A lot of Wayland protocol work is focused on the environment and design, while applications and work to port them often is considered less. I think this happens because the overlap between application developers and developers of the desktop environments is not necessarily large, and the overlap with people willing to engage with Wayland upstream is even smaller. The combination of Windows developers porting apps to Linux and having involvement with toolkits or Wayland is pretty much nonexistent. So they have less of a voice.
A quick detour through the neuroscience research lab
I have been involved with Freedesktop, GNOME and KDE for an incredibly long time now (more than a decade), but my actual job (besides consulting for Purism) is that of a PhD candidate in a neuroscience research lab (working on the morphology of biological neurons and its relation to behavior). I am mostly involved with three research groups in our institute, which is about 35 people. Most of us do all our data analysis on powerful servers which we connect to using RDP (with KDE Plasma as desktop). Since I joined, I have been pushing the envelope a bit to extend Linux usage to data acquisition and regular clients, and to have our data acquisition hardware interface well with it. Linux brings some unique advantages for use in research, besides the obvious one of having every step of your data management platform introspectable with no black boxes left, a goal I value very highly in research (but this would be its own blogpost).
In terms of operating system usage though, most systems are still Windows-based. Windows is what companies develop for, and what people use by default and are familiar with. The choice of operating system is very strongly driven by application availability, and WSL being really good makes this somewhat worse, as it removes the need for people to switch to a real Linux system entirely if there is the occasional software requiring it. Yet, we have a lot more Linux users than before, and use it in many places where it makes sense. I also developed a novel data acquisition software that even runs on Linux-only and uses the abilities of the platform to its fullest extent. All of this resulted in me asking existing software and hardware vendors for Linux support a lot more often. Vendor-customer relationship in science is usually pretty good, and vendors do usually want to help out. Same for open source projects, especially if you offer to do Linux porting work for them… But overall, the ease of use and availability of required applications and their usability rules supreme. Most people are not technically knowledgeable and just want to get their research done in the best way possible, getting the best results with the least amount of friction.
Back to the point
The point of that story is this: GNOME, KDE, RHEL, Debian or Ubuntu: They all do not matter if the necessary applications are not available for them. And as soon as they are, the easiest-to-use solution wins. There are many facets of “easiest”: In many cases this is RHEL due to Red Hat support contracts being available, in many other cases it is Ubuntu due to its mindshare and ease of use. KDE Plasma is also frequently seen, as it is perceived a bit easier to onboard Windows users with it (among other benefits). Ultimately, it comes down to applications and 3rd-party support though.
Here’s a dirty secret: In many cases, porting an application to Linux is not that difficult. The thing that companies (and FLOSS projects too!) struggle with and will calculate the merits of carefully in advance is whether it is worth the support cost as well as continuous QA/testing. Their staff will have to do all of that work, and they could spend that time on other tasks after all.
So if they learn that “porting to Linux” not only means added testing and support, but also means to choose between the legacy X11 display server that allows for 1:1 porting from Windows or the “new” Wayland compositors that do not support the same features they need, they will quickly consider it not worth the effort at all. I have seen this happen.
Of course many apps use a cross-platform toolkit like Qt, which greatly simplifies porting. But this just moves the issue one layer down, as now the toolkit needs to abstract Windows, macOS and Wayland. And Wayland does not contain features to do certain things or does them very differently from e.g. Windows, so toolkits have no way to actually implement the existing functionality in a way that works on all platforms. So in Qt’s documentation you will often find texts like “works everywhere except for on Wayland compositors or mobile”4.
Many missing bits or altered behavior are just papercuts, but those add up. And if users will have a worse experience, this will translate to more support work, or people not wanting to use the software on the respective platform.
What’s missing?
Window positioning
SDI applications with multiple windows are very popular in the scientific world. For data acquisition (for example with microscopes) we often have one monitor with control elements and one larger one with the recorded image. There is also other configurations where multiple signal modalities are acquired, and the experimenter aligns windows exactly in the way they want and expects the layout to be stored and to be loaded upon reopening the application. Even in the image from Adlershof Technology Park above you can see this style of UI design, at mega-scale. Being able to pop-out elements as windows from a single-window application to move them around freely is another frequently used paradigm, and immensely useful with these complex apps.
It is important to note that this is not a legacy design, but in many cases an intentional choice – these kinds of apps work incredibly well on larger screens or many screens and are very flexible (you can have any window configuration you want, and switch between them using the (usually) great window management abilities of your desktop).
Of course, these apps will work terribly on tablets and small form factors, but that is not the purpose they were designed for and nobody would use them that way.
I assumed for sure these features would be implemented at some point, but when it became clear that that would not happen, I created the ext-placement protocol which had some good discussion but was ultimately rejected from the xdg namespace. I then tried another solution based on feedback, which turned out not to work for most apps, and now proposed xdg-placement (v2) in an attempt to maybe still get some protocol done that we can agree on, exploring more options before pushing the existing protocol for inclusion into the ext Wayland protocol namespace. Meanwhile though, we can not port any application that needs this feature, while at the same time we are switching desktops and distributions to Wayland by default.
Window position restoration
Similarly, a protocol to save & restore window positions was already proposed in 2018, 6 years ago now, but it has still not been agreed upon, and may not even help multiwindow apps in its current form. The absence of this protocol means that applications can not restore their former window positions, and the user has to move them to their previous place again and again.
Meanwhile, toolkits can not adopt these protocols and applications can not use them and can not be ported to Wayland without introducing papercuts.
Window icons
Similarly, individual windows can not set their own icons, and not-installed applications can not have an icon at all because there is no desktop-entry file to load the icon from and no icon in the theme for them. You would think this is a niche issue, but for applications that create many windows, providing icons for them so the user can find them is fairly important. Of course it’s not the end of the world if every window has the same icon, but it’s one of those papercuts that make the software slightly less user-friendly. Even applications with fewer windows like LibrePCB are affected, so much so that they rather run their app through Xwayland for now.
I decided to address this after I was working on data analysis of image data in a Python virtualenv, where my code and the Python libraries used created lots of windows all with the default yellow “W” icon, making it impossible to distinguish them at a glance. This is xdg-toplevel-icon now, but of course it is an uphill battle where the very premise of needing this is questioned. So applications can not use it yet.
Limited window abilities requiring specialized protocols
Firefox has a picture-in-picture feature, allowing it to pop out media from a mediaplayer as separate floating window so the user can watch the media while doing other things. On X11 this is easily realized, but on Wayland the restrictions posed on windows necessitate a different solution. The xdg-pip protocol was proposed for this specialized usecase, but it is also not merged yet. So this feature does not work as well on Wayland.
Automated GUI testing / accessibility / automation
Automation of GUI tasks is a powerful feature, so is the ability to auto-test GUIs. This is being worked on, with libei and wlheadless-run (and stuff like ydotool exists too), but we’re not fully there yet.
Wayland is frustrating for (some) application authors
As you see, there is valid applications and valid usecases that can not be ported yet to Wayland with the same feature range they enjoyed on X11, Windows or macOS. So, from an application author’s perspective, Wayland does break things quite significantly, because things that worked before can no longer work and Wayland (the whole stack) does not provide any avenue to achieve the same result.
Wayland does “break” screen sharing, global hotkeys, gaming latency (via “no tearing”) etc, however for all of these there are solutions available that application authors can port to. And most developers will gladly do that work, especially since the newer APIs are usually a lot better and more robust. But if you give application authors no path forward except “use Xwayland and be on emulation as second-class citizen forever”, it just results in very frustrated application developers.
For some application developers, switching to a Wayland compositor is like buying a canvas from the Linux shop that forces your brush to only draw triangles. But maybe for your avant-garde art, you need to draw a circle. You can approximate one with triangles, but it will never be as good as the artwork of your friends who got their canvases from the Windows or macOS art supply shop and have more freedom to create their art.
Triangles are proven to be the best shape! If you are drawing circles you are creating bad art!
Wayland, via its protocol limitations, forces a certain way to build application UX – often for the better, but also sometimes to the detriment of users and applications. The protocols are often fairly opinionated, a result of the lessons learned from X11. In any case though, it is the odd one out – Windows and macOS do not pose the same limitations (for better or worse!), and the effort to port to Wayland is orders of magnitude bigger, or sometimes in case of the multiwindow UI paradigm impossible to achieve to the same level of polish. Desktop environments of course have a design philosophy that they want to push, and want applications to integrate as much as possible (same as macOS and Windows!). However, there are many applications out there, and pushing a design via protocol limitations will likely just result in fewer apps.
The porting dilemma
I spent probably way too much time looking into how to get applications cross-platform and running on Linux, often talking to vendors (FLOSS and proprietary) as well. Wayland limitations aren’t the biggest issue by far, but they do start to come come up now, especially in the scientific space with Ubuntu having switched to Wayland by default. For application authors there is often no way to address these issues. Many scientists do not even understand why their Python script that creates some GUIs suddenly behaves weirdly because Qt is now using the Wayland backend on Ubuntu instead of X11. They do not know the difference and also do not want to deal with these details – even though they may be programmers as well, the real goal is not to fiddle with the display server, but to get to a scientific result somehow.
Another issue is portability layers like Wine which need to run Windows applications as-is on Wayland. Apparently Wine’s Wayland driver has some heuristics to make window positioning work (and I am amazed by the work done on this!), but that can only go so far.
A way out?
So, how would we actually solve this? Fundamentally, this excessively long blog post boils down to just one essential question:
Do we want to force applications to submit to a UX paradigm unconditionally, potentially loosing out on application ports or keeping apps on X11 eternally, or do we want to throw them some rope to get as many applications ported over to Wayland, even through we might sacrifice some protocol purity?
I think we really have to answer that to make the discussions on wayland-protocols a lot less grueling. This question can be answered at the wayland-protocols level, but even more so it must be answered by the individual desktops and compositors.
If the answer for your environment turns out to be “Yes, we want the Wayland protocol to be more opinionated and will not make any compromises for application portability”, then your desktop/compositor should just immediately NACK protocols that add something like this and you simply shouldn’t engage in the discussion, as you reject the very premise of the new protocol: That it has any merit to exist and is needed in the first place. In this case contributors to Wayland and application authors also know where you stand, and a lot of debate is skipped. Of course, if application authors want to support your environment, you are basically asking them now to rewrite their UI, which they may or may not do. But at least they know what to expect and how to target your environment.
If the answer turns out to be “We do want some portability”, the next question obviously becomes where the line should be drawn and which changes are acceptable and which aren’t. We can’t blindly copy all X11 behavior, some porting work to Wayland is simply inevitable. Some written rules for that might be nice, but probably more importantly, if you agree fundamentally that there is an issue to be fixed, please engage in the discussions for the respective MRs! We for sure do not want to repeat X11 mistakes, and I am certain that we can implement protocols which provide the required functionality in a way that is a nice compromise in allowing applications a path forward into the Wayland future, while also being as good as possible and improving upon X11. For example, the toplevel-icon proposal is already a lot better than anything X11 ever had. Relaxing ACK requirements for the ext namespace is also a good proposed administrative change, as it allows some compositors to add features they want to support to the shared repository easier, while also not mandating them for others. In my opinion, it would allow for a lot less friction between the two different ideas of how Wayland protocol development should work. Some compositors could move forward and support more protocol extensions, while more restrictive compositors could support less things. Applications can detect supported protocols at launch and change their behavior accordingly (ideally even abstracted by toolkits).
You may now say that a lot of apps are ported, so surely this issue can not be that bad. And yes, what Wayland provides today may be enough for 80-90% of all apps. But what I hope the detour into the research lab has done is convince you that this smaller percentage of apps matters. A lot. And that it may be worthwhile to support them.
To end on a positive note: When it came to porting concrete apps over to Wayland, the only real showstoppers so far5 were the missing window-positioning and window-position-restore features. I encountered them when porting my own software, and I got the issue as feedback from colleagues and fellow engineers. In second place was UI testing and automation support, the window-icon issue was mentioned twice, but being a cosmetic issue it likely simply hurts people less and they can ignore it easier.
What this means is that the majority of apps are already fine, and many others are very, very close! A Wayland future for everyone is within our grasp! 😄
I will also bring my two protocol MRs to their conclusion for sure, because as application developers we need clarity on what the platform (either all desktops or even just a few) supports and will or will not support in future. And the only way to get something good done is by contribution and friendly discussion.
Footnotes
- Apologies for the clickbait-y title – it comes with the subject 😉 ↩︎
- When I talk about “Wayland” I mean the combined set of display server protocols and accepted protocol extensions, unless otherwise clarified. ↩︎
- I would have picked a picture from our lab, but that would have needed permission first ↩︎
- Qt has awesome “platform issues” pages, like for macOS and Linux/X11 which help with porting efforts, but Qt doesn’t even list Linux/Wayland as supported platform. There is some information though, like window geometry peculiarities, which aren’t particularly helpful when porting (but still essential to know). ↩︎
- Besides issues with Nvidia hardware – CUDA for simulations and machine-learning is pretty much everywhere, so Nvidia cards are common, which causes trouble on Wayland still. It is improving though. ↩︎
*sigh* Yet another “we want X11 again” whine. Let me start from the beginning. X11 was awful. It was a monstrosity that, quite frankly, shouldn’t have existed. It tried to be an entire platform in 1 package that failed because of it’s complexity, size, and aimless scope.
Wayland is a display server. That’s it. A display server. It is mean to replace the main piece of X11 that X11 started out as – a display server.
There are other pieces of the puzzle, most are already in place, others could use use TLC, but most of what you’re asking already exists. It’s just that developers have, for too long, be complacent using the 10-legged, 4-headed, 18-arm ugly-stick-beated monster that is X11 and now can’t seem to handle the fact that different pieces of software exist to handle different things.
>>> Window positioning & restoration
Believe it or not, this is no the job of a display server. Shocking, I know. Just because X11 did it, does not mean Wayland needs to. This is the job of the window manager. Most window managers already have their own way of handling window positioning. Some seem to provide a mechanism to remember positioning and others don’t. It might be best to work with them and get a more standardized way of handling this. Outside of that, the apps will currently have to have hooks for each window manager in order to do this in a desktop environment agnostic way. Hopefully there will be a more unified solution at some point.
>>> Window icons
This is actively being discussed and worked on on various fronts, and likely includes Wayland as well, but getting all of the different environments to agree on some standard way of handling this is going to take a bit. Personally, I don’t see this as a deal breaker. It’s more of an annoyance for the time being.
>>> Limited window abilities requiring specialized protocols
As you already said, this is being worked on in xdg and is an ongoing discussion with many pieces of software, including Firefox. For now, it still works. PIP happens, but with limited feature. However, at least some of those features can be brought back within each display manager either user settings or automation. Again, a minor annoyance that is being worked on.
>>> Automated GUI testing / accessibility / automation
I don’t know much about this, but you clearly seem to show that there is work on this going on and solutions are on the way.
>>> Wayland does “break” screen sharing, global hotkeys, gaming latency (via “no tearing”) etc, however for all of these there are solutions available that application authors can port to.
Screen sharing is not broken. Use pipewire.
Global hotkeys is, again, in the realm of the display manger. It’s not for Wayland to do hotkey management, peripheral management, and user settings. Unfortunately I don’t see any DM agnostic way to handle hotkeys so there will have to be hooks added for now. I would continue to pressure the DMs to make a more standardized way of handling them or build a common tool for this.
Not really sure what you mean about gaming latency and tearing. I’ve not seen these issues. Games can still make use of anti-tearing mechanisms. However, gaming on linux in general tends to already be emulated so getting 100% of the framerate as on native OSes is not likely to happen anyway.
>>> The porting dilemma
Linux has always had cross-platform issues. It was made 20 times worse by developers getting too accustomed to using the 4-5-6 poorly-developed X11 ways. Now, those repositories are having to step back, add the pieces they should have had in the first place, and work with other packages the way they should have 20+ years ago. It takes time to figure these things out but many are already in place and others can be handled with interim scripts and hooks. There are also libraries already existing or in the works to allow sharing of data and functionality across DMs.
>>> I think we really have to answer that to make the discussions on wayland-protocols a lot less grueling.
You could start by not acting like Wayland should be another X11, by putting blame on X11 being an 11-headed monstrosity, and by working with other developers to get a more unified connection between managers. You can also allow the time necessary for the pieces that are falling into place to actually fall into place. Until then, there’s X11 and Xwayland. Doesn’t mean they will forever be in some purgatory. Just means until the necessary pieces are production ready that they will remain where they are.
>>> If the answer turns out to be “We do want some portability”, the next question obviously becomes where the line should be drawn and which changes are acceptable and which aren’t.
That is what each software community will need to figure out the best path for itself. Do they port now and have some annoyances and a few missing features until there is support for it or do they wait and stay emulated until they are available? They need to do what they feel is best for them. However, some, like some screen sharing software not working, is on the developer. Just because some people “refuse to use pipewire” or “refuse to use portals” is not a means to sit and complain. Either make a new library that allows for cross-DM features, help out with existing efforts, or wait for the solutions to fall.
>>> For example, the toplevel-icon proposal is already a lot better than anything X11 ever had.
See, making software do specifically what it should can also be a way to fix the many, many flaws of X11 in the process. But it won’t happen instantly. Many open-source libraries are woefully understaffed/underfunded and could use additional help.
Simply complaining that Wayland should copy X11 gets nothing done. If it were to copy X11, it would end up in the same position and developers would eventually abandon it in the same fashion. I feel it’s a good thing that functionality is finally being pushed into the software it was meant to be in.
Please read the blog post to understand my point. I especially recommend you read the second paragraph again. Also, Wayland is a display server protocol, not a display server.
> Simply complaining that Wayland should copy X11 gets nothing done.
You will find this complaint nowhere in this blog post – in fact, you may even find the opposite… 😉
Wayland is the future, 15 years later still the future, people need this feature “it’s not Wayland job” or let pending this infinitely. Screen sharing doesn’t work, use Pipewire. My application doesn’t work, don’t use that compositor. I mean from the many choices we can get from the Linux application ecosystem, if wayland only works in a specific way, press the audience. Just make statement Wayland only work with this or that. We are not future just alternatives that break userspace. It already too long to wait.
> Wayland is a display server
No, it isn’t. Display server/window manager model is gone with Wayland. Every Wayland implementation (compositor) is both display server and window manager.
> Most window managers already have their own way of handling window positioning.
No, they don’t. And even if some do have some API for this, that just does not fly. Applications that NEED this feature, need it in portable way, not through compositor specific implementation.
You just interpreted something into that post that isn’t there.
Or in other words: Constructed a strawman.
Nowhere did he say that Wayland should copy X11.
It’s not the fault of the technology Wayland, but of fanboys like you that it is missing critical functionality for people to do real work. The author of this post is being some nice and just offering constructive criticism but all you can do is pretend that any criticism is unjustified instead of using it to make the product better. If Wayland forks into groups that favor a pragmatic set of protocol extensions and one that doesn’t, it will be because of inflexible people, not an inflexible protocol.
It seems that the people responsible for X11 have learned a lesson so painful that they are now overreacting in the opposite direction, creating another mess.
Wayland would have been a good candidate for a fork. Calmer people would not jumped from one extreme to the opposite. Instead of zeroing on the problem, they just flipped the sign.
> Outside of that, the apps will currently have to have hooks for each window manager in order to do this in a desktop environment agnostic way. Hopefully there will be a more unified solution at some point.
Lol, LMAO even
> *sigh* Yet another “we want X11 again” whine.
Nonsense. Quite the opposite, the author says that “sticking to X11 makes no sense for future projects”. The post just points out a handful specific X11 features that applications NEED and that are still missing in Wayland after all these years due to endlessly protracting discussions.
> Let me start from the beginning. X11 was awful. It was a monstrosity that, quite frankly, shouldn’t have existed. It tried to be an entire platform in 1 package that failed because of it’s complexity, size, and aimless scope.
X11 has not failed. X11 has been a huge success. It has lived for soon 40 years! And in all these years, it has been the de-facto standard for GUIs on all *nix systems, only now to be slowly displaced by this newfangled Wayland stuff. (Yet, many people still use X11 even today.) How is this a failure?
> >>> Window positioning & restoration
> Believe it or not, this is no the job of a display server. Shocking, I know. Just because X11 did it, does not mean Wayland needs to. This is the job of the window manager.
But it is a core part of the Wayland design that the Wayland compositor IS the window manager AND the display server (or embeds one or both as libraries, depending on the compositor’s design, but in any case the same process implements all three parts in one way or the other). There is no separate window manager for the application to talk to. The one other end it talks to is the Wayland compositor, over the Wayland protocol. So any feature it needs from the compositor, no matter whether it is a display server, compositor, or window manager feature MUST be implemented as a Wayland protocol extension. (Any other approach will inherently be compositor-specific and non-portable.)
> >>> Window icons
> [snip] Personally, I don’t see this as a deal breaker. It’s more of an annoyance for the time being.
But it makes applications look broken and unprofessional.
> >>> Automated GUI testing / accessibility / automation
> I don’t know much about this, but you clearly seem to show that there is work on this going on and solutions are on the way.
This would be so much easier without all this security theater preventing this from being done the obvious way it works on all other desktop GUI environments (X11, Windows, Mac), where you just need the other window’s handle to send it keypresses (an essential feature for automated testing), grab its screen contents (to compare them with a reference in QA tools), etc.
> >>> Wayland does “break” screen sharing, global hotkeys, gaming latency (via “no tearing”) etc, however for all of these there are solutions available that application authors can port to.
> Screen sharing is not broken. Use pipewire.
Pipewire by itself will not be able to do anything without the portal that gives you a Pipewire handle to the screen contents. Portal which in turn requires interactively asking the user for permission, which your application design needs to account for. Something that so far was only ever needed on mobile platforms (see, e.g., Android intents). Any other desktop windowing system just lets any application grab what it wants from the screen. So the Wayland behavior is inherently non-portable and a source of complexity.
> Global hotkeys is, again, in the realm of the display manger. It’s not for Wayland to do hotkey management, peripheral management, and user settings. Unfortunately I don’t see any DM agnostic way to handle hotkeys so there will have to be hooks added for now. I would continue to pressure the DMs to make a more standardized way of handling them or build a common tool for this.
X11 just let applications hook into the global keyboard input handler to process their global shortcuts on their own. Same as it works on, e.g., Windows. Wayland’s security theater makes it needlessly complex, in the name of preventing keygrabbers, which is absurd because malware running as your user will still be able to grab the keys in other ways (as well as, e.g., encrypt all your documents for ransom), so protecting against keygrabbers at the Wayland protocol level is entirely ineffective security theater that just breaks applications.
> Simply complaining that Wayland should copy X11 gets nothing done. If it were to copy X11, it would end up in the same position and developers would eventually abandon it in the same fashion.
Developers are moving from X11 to Wayland because it is unfortunately more fun to work on some new half-broken experimental thing where a lot of stuff still needs work (posing interesting design challenges to developers) than to keep working software working (i.e., boring maintenance work).
> *sigh* Yet another “we want X11 again” whine.
What an utterly assholeish way to characterise the post.
The rest of your comment may have been worthwhile — but I’ll never know, because I stopped reading there.
I do not known, what restoring window position protocol and window positioning protocol should work, but maybe connect it?
Simply: allow to create window group, with group leader, and allow to attach window to group. We can also made sub-groups. Restrictions: each window must be created by the same client. We cannot position window.
When apps relaunch, it only creates window with the same id. If this window was group leader, group was recreated. Group leader could be positioned randomly, but each group child should be placed based on leader position. Also, compositor could restore group leader position, but they do not have too.
I have read some blog post about two ticket about window relative positioning under wayland. I only propose to add to this idea window position restoring option.
This is pretty much what https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/264 does, but I did not include session restoration bits to keep the discussion more focused for now. *If* the protocol turns out to be viable, then we can thing about merging the two, if the author of the session-management protocol agrees.
Since not all desktops might implement xdg-positioning, we may still need both protocols though, ultimately. It’s entirely unclear what the end result will be.
Thank you for your analysis in the situation. Linux cannot compete with Windows/MacOS if it has inferior apps capabilities.
Wayland breaks more: it doesn’t have separate window managers (not as modular as it’s made out to be!) and also isn’t network transparent. No, “remote desktop” is in no way comparable to the usefulness of remote individual windows. But I guess I can’t expect people to understand that who are involved for merely a decade.
You may like Waypipe: https://gitlab.freedesktop.org/mstoeckl/waypipe as well as RDP implementations for Wayland, which actually bring pretty good remote desktop capabilities. Not all features are there yet, but this area is actively being worked on.
Separating window managers from the display server does not make sense in Wayland’s architecture. A Wayland compositor does a lot less, and the interaction between Xorg and WMs was always really error prone and had a lot of fun hacks.
It would have been nice of course if we had something like wlroots sooner to make building Wayland compositors easier, but the past is the past and that issue is addressed now.
Well I didn’t like Waypipe. Waypipe doesn’t work with Pipewire. Waypipe doesn’t work with XDG-Portal. Waypipe doesn’t work with D-Bus, Waypipe doesn’t work with X11. So every time when I’ve actually tried to use it, it ended up a. not working immediately, b. crashing during use. c. working with the ‘wrong’ thing.
Fair! I am using RDP, but if you are used to ssh -X, that isn’t actually an implementation with the same featureset.
I am sure it could be made to work, but it would require some compositor cooperation (to for example just transfer a single app).
Ironically, looking at Microsoft’s WSL2 here could be useful, as they use a Wayland compositor and RDP to display windows from the Linux VM in the regular windows desktop and integrate them.
>s, but Qt doesn’t even list Linux/Wayland as supported platform
I probably should. Unfortunately there’s too much to say and the situation is so fragmented it’s hard to make definitive statements.
A lot of the most major Wayland flaws we circumvent by having a protocol with working window positionsso that fixes a lot of things when used with Qt’s compositor just not on the desktop.
Yeah, it’s an odd oversight… I haven’t played with Qt’s compositor, but the documentation makes it sound like it does have an internal way of absolute positioning… But of course, that only works for that compositor, with Qt itself, so isn’t all that helpful.
Love the /r/linux reaction. 4 root replies (i don’t know what was the deleted post), 2 (50%) of them didn’t even bother to read the article and went with dismissive stance from the get go. Tells you a lot.
At this point (10+ years of bikeshedding and still going strong) it’s hard to not be extremely pessimistic. Good luck, i guess.
It’s almost like there should be a professional/industrial shell protocol that extends xdg-shell and adds features that are more uniquely found in professional and scientific software. I agree with you, in my experiences in industrial and scientific environments, multi-window is exceedingly common and for exactly the use case you described: lots and lots of monitors and customizing the working area to the needs of the team. Completely reworking the UI shouldn’t be a Linux porting hurdle.
You’d probably get some compositors (KDE maybe?) to agree to implement the deltas between xdg-shell and (whiffing on a name here) scientific-shell. But not all. And that’s OK – there’d be clarity on where to direct QA.
It’s baffling me how we now have larger screens with higher resolutions that benefit multi-window applications a lot…. but we decide to not include that ability in the “modern next generation display protocol”.
I lived through the days when these styles of interfaces were a bit more common. GIMP comes from that era. They, along with MDI interfaces (i.e. windows inside a single app frame) fell out of favor and practice for the most common sorts of applications. We can all say good riddance to MDI apps, at least the ones that were like having a separate desktop inside an app — MFI and tabbed interfaces like those we see in modern web browsers seem the best replacement for those. Word used to be MDI, but for a long time now has been MFI (multiple independent windows). But for multi-window SDI, even though they never made sense on small screens, you’re right – big screens, and multiple screens, affect the value proposition. Most consumer-oriented apps (like GIMP!) that used this style got a lot of flak/hate and that is the lasting taste most people have in their mouth. Over time, use of anything but single-window apps have taken over as the primary interface paradigm and many think it to be a “best practice.” For the majority of apps, it is exactly that. Except perhaps the kinds this author is talking about, and the environments in which they tend to live.
Most people are unlikely to be aware of the use and importance of this style of application in niche environments like scientific and industrial. But unfortunately many in the tech world live or die by inherited principles of potentially unknown origin. It’s similar with global menu vs per-window menu – whether it’s good or bad can depend on monitor configuration.
Thanks, a really good write up of some important use cases that need solving.
I often find people think of these things, eg. apps that make many windows, as “niche use-case” – which is true from a global perspective, but from the perspective of a single person, like a scientist in a lab, it’s not niche, it’s massive. It may be, for them, the difference between a machine being unusable/extremely frustrating vs. fast and easy.
We, as a Linux-loving community, should want it to be a great UX for these people too, not just the developer/office worker with a web browser use-case.
A big problem with Wayland are the different Compositors. With X11 you can be sure your Program works the same on every Desktop. That’s no longer the case with Wayland. There are many Programs which work on one Compositor but does not work on another.
Another thing to keep in mind is fragmentation.
First from the X11/Xorg side, different window managers are meeting different goals. You can’t expect users to flush their workflow down the drain (which they might have customized over decades) for no benefit beyond “bruh, pixel perfect frames”. I’m in that camp, I’m using a niche(?) window manager and it’s not getting ported unless someone is willing to spend several person-years on developing it.
The second thing is fragmentation on the Wayland side. People are always quick to point out that Wayland is only a protocol, and that’s true, but it doesn’t help if you need an extension which has been implemented by compositor X but not compositor Y. I’ve always called that the Wayland philosophy “It’s someone elses problem now” (as in “we have the extensions, it’s the compositors fault if they don’t implement it”), which is, I agree, derogatory and unfair to those who *really* try to build the future, but is resulting in real problems. As you’ve said, porting applications is already scary, porting it to only *one* compositor because only that one has the needed extensions seems extremely limited.
And as you’ve already pointed out, there *are* parties involved in Wayland that want to push their philosophies through it (CSD/SSD?) and so everyone is worse off.
These aren’t the only things that are broken.
Drag and drop seems like it’s been totally forgotten, near the beginning I was optimistic that being able to drag files from archive manager to where there needed would work soon, but it’s been ten years and there’s no sign of it.
Drag and drop is not “forgotten”, it’s a core part of the Wayland protocol. If it doesn’t work, it’s because your compositor of choice and the application doesn’t support it. I use this feature all of the time on KDE Wayland for years 🙂
Good luck Matthias! It’s super exciting seeing you break into the protocol, even if they aren’t accepted it will definitely push people to keep making steps toward what apps need.
I believe that this situation can be fixed in 3 simple steps:
1. Find a new team to maintain X11. XFree86 and X.Org (apart from Xwayland) are both dead. A successor (i.e., a team that actually wants to maintain the code, not people who claim to be X11 developers and tell everyone to use Wayland instead because that is what they actually develop now) is needed.
2. Port Phosh and Plasma Mobile to X11. X11 is NOT “too heavy” for mobile, as is always claimed. In fact, the most lightweight mobile desktop environment out there (SXMO) uses it. But SXMO is optimized for a usage pattern that does not match my or most other users’ way to use a smartphone, it pretty much expects you to mostly use terminal applications, typically with a physical keyboard (be it the PinePhone keyboard case or some external USB or Bluetooth keyboard). So it proves that it can be done, but it is not the environment that most mobile users will actually want to use. That said, older, long discontinued mobile GNU/Linux environments such as the ones designed for OpenMoko hardware or Nokia’s Maemo environment also used X11 back in the day. So I do not see why we cannot have modern mobile environments on X11.
3. Kill Wayland with fire. All the still missing features after years of development clearly position it as a failed experiment.
Even the so-called “X.Org Developers Conference” has been hijacked for Wayland stuff, so we really need a new X11 team outside of X.Org (basically, XFree86 reloaded, of course with a new name that does not conflict with the existing dead project and preferably does not refer to an obsolete CPU 😉 ).
Wayland doesn’t solve a longstanding problem from X11, and the attitudes around it make a solution unlikely. It’s a shame, really, because the solution is simple. No one cares.
On both Windows and macOS, if you can see a file icon in a folder view, you can drag it somewhere else without having your windows rearrange themselves. On all of the extant X11 and Wayland desktops, trying to drag that icon will raise the window it’s in, likely obscuring the window you meant to drag it to.
The problem is how keyboard input focus is managed. The drag and drop issue is one example.
The solution is simple and has been suggested, for X11, since the release of ICCCM 2.0 in 1994. I tried to get it implemented in 2004. The problem is political, not technical. What exists works well enough for the users who choose to stick around. The people who have a problem with it are “not our users”.
The solution is to switch to applications pulling focus, rather than having it pushed on them. I’ve given details elsewhere.
There are some things i like about Wayland but there are some that i feel simply come down to bad design, poor choices and bad government. I feel that the amount of work needed to implement support is too big and the challenges involved too hard. This still could be justified if the way it would work is to be done once and used across the ecosystem. This is not on how it works as each project must invest the effort and hence the amount of fragmentation and duplication of work involved is just ridiculous. For the last decade and a half all major projects need to invest substantial recurses and effort into thinking on how to crack Wayland and nobody still really resolved that. It’s still WIP and in a lot of areas development still onyl a discussion, on how hard it would be to support something, common on other platforms. Then there is the real issue of fundamentalism, some challenges proved to be too hard and solutions for them simply get avoided, claiming things like this are out of scope or delaying addressing the issues for decade(s). What is happening now is position of power will get abused and transition to Wayland will be forced backed again by the culture of acting like this is not our problem, trying to mask all the failure involved. It’s like the challenges involved are really going away as long as we ignore them. Until this logic changes i feel that Wayland can’t really succeed. Discussions about X11 are hence not even relevant as it’s not X11 fault that Wayland is lacking, it’s Wayland fault and sticking the head in the send won’t change that.