I am betting on wayland long term, though I still have X11 a lot of places.
Certainly you can see the problem with the situation that developers of one project abandon it and start a new project that lacks many of the features of the old and claim that users should use the new one.
It's not an issue of what will win in the long run; it's an issue of a replacement product being pushed for adoption long ere it be ready.
Can you explain what you think these are? In my experience, this is not really the case.
- Take a screenshot, or share a single window
- Screenshot, screenshare, or remote desktop/VNC server without having to use different protocols for different compositors
- Use a third party app to control monitor outputs(resolution, orientation, framerate, layout, etc.) generally, for example arandr or xrandr (wlroots does support this)
- Be able to do something like KeepassXC's "Autotyping", where it fills in a text field with the password from your password manager.
- Have a third party app give a selection of open windows. I think all compositors have some API for this, but they are all different. (for example rofi's window switcher mode).
Generally, I think the problem isn't so much things that can't be done in wayland at all, as the way to do them is different across different compositors, so whereas with X it was pretty straightforward to mix and match apps between different DEs and apps that worked on all of them. In wayland there are more apps that only work on gnome, only work on kde, or only work on wlroots based compositors. And some apps that duplicate parts of the code for all three.
For controlling monitor outputs and open windows, those APIs are different because each compositor has a different set of features for what those mean. Generally you should not be using random applications to configure monitor outputs, only your compositor's configuration tool is going to be reliable there. Applications that need to set custom resolutions can use the viewporter or use fullscreen-shell.
Worst case scenario if you need to duplicate parts of the code for all three, I don't think that's a problem. Just put it in a library if it needs to be re-used, the only alternative there is that upstream maintains the relevant bits of that duplicate code, which I'm sure you can see why they would be reluctant to do that.
This does not allow one to write a screenshot application; this has a protocol that allows Flatpak applications to requæst that the compositor take one and as far as I know it only has support to take on from the entire screen.
Most compositors also have the ability to take such screenshots outside of Flatpak; this simply moves it inside of it.
The “screenshot issue” with Wayland is not that compositors can't take one; it's the lack of an the a.p.i.'s necessary to write software that can take one.
> For generating fake inputs, a library is being worked on called libei, that also should work in X11, Wayland, and within a sandbox.
I could find nothing on this on the internet.
> For controlling monitor outputs and open windows, those APIs are different because each compositor has a different set of features for what those mean. Generally you should not be using random applications to configure monitor outputs, only your compositor's configuration tool is going to be reliable there. Applications that need to set custom resolutions can use the viewporter or use fullscreen-shell.
And that one “should not do this” yet this is supported and used by many on X11 would be one of the missing features that would lead to Wine developers not being interested in a Wayland port.
> Worst case scenario if you need to duplicate parts of the code for all three, I don't think that's a problem. Just put it in a library if it needs to be re-used, the only alternative there is that upstream maintains the relevant bits of that duplicate code, which I'm sure you can see why they would be reluctant to do that.
The problem is that these per compositor a.p.i.'s are unstable.
GNOME extensions and KWIN scripts work by allowing one to directly hack the internals of the compositor in unstable ways; they are much like kernel modules and they break from version to version.
In almost all cases, Wine should viewporter or use fullscreen-shell to set custom resolutions for specific programs, the only reason you would need to allow wine to have access to an xrandr-like API is if you wanted to run your monitor configuration tool from windows, which I strongly doubt people are wanting to do that. If you are using GNOME/KDE, the GNOME/KDE control panel is always going to be the most reliable way to configure that.
Yes you would need to track upstream and keep up with their unstable APIs in order to write such a library that but that's no different than if you asked upstream to do it, they would just be doing that in their tree. (In some cases this is what they do anyway with the xdg-desktop-portal) In any case you would need to be more specific about what it is you want because just saying "implement everything from X11 exactly the way X11 does it" is not useful, that's never going to happen, so let's focus on what actually it is that is needed.
uh, where? From the documentation at https://flatpak.github.io/xdg-desktop-portal/portal-docs.htm...
the supported options are whether it should be interactive, and whether the dialog should be modal. There is no option to indicate what kind of screenshot you want (window, monitor, full screen, rectangle). You can hope that the compositor's implementation lets the user select what they want, but the compositor is free to take the screenshot however it wants, the wlroots xdg-desktop implementation for example, currently just always takes a screenshot of the whole screen. The API is oriented more toward's Gnomes approach of considering the screenshot dialog to be the responsibility of the compositor, and doesn't work well for sway's approach of considering the screenshot dialog to be the application's responsibility.
The Screencast protocol at least allows you to specify if you want to capture a monitor or a window, although not all compositors support both (for example xdg-desktop-wlroots only supports the monitor type). Now hopefully in the not-too distant future most compositors will support it, atm, at least in my compositor of choice, it doesn't work yet.
And in both cases the the xdg-desktop-portal API doesn't really work well with apps like Flameshot or Peek, where you determine what to capture by resizing the window of the app.
As Blikkentrekker said, it isn't sufficiently flexible for making a screenshotting app, it is only useful for requesting that some other (possibly compositor native) application take a screenshot and return it to you. Flameshot for example, evaluated using xdg-desktop-portal and determined it wasn't suitable (seeh ttps://github.com/flameshot-org/flameshot/issues/446#issuecomment-774372329). It is also notably missing a way to request a screenshot/screenshare of a single window or of a region of the screen rather than the whole screen.
> For generating fake inputs, a library is being worked on called libei, that also should work in X11, Wayland, and within a sandbox.
Well that's still a work in progress isn't it? My response is about what currently doesn't work, not what will work in the future.
> Generally you should not be using random applications to configure monitor outputs, only your compositor's configuration tool is going to be reliable there.
1. For minimal compositors such as sway, creating an advanced monitor configuration tool that handles hotplugging outputs, or with a GUI is out of scope for the project. 2. Being able to script changing monitor configuration, and bind those scripts to hotkeys is pretty important to me. Thankfully that is pretty trivial with sway, but isn't really possible if the only way to manage monitors is the "compositor's configuration tool". And even if it is, such a script isn't portable between compositors. 3. Maybe it is different with wayland, but my experience in X11 was that configuring monitors with xrandr or arandr was much more reliable than any of the DE's designated monitor configuration tools. And even if reliability is no longer an issue, users might prefer a different UI.
> Worst case scenario if you need to duplicate parts of the code for all three, I don't think that's a problem. Just put it in a library if it needs to be re-used, the only alternative there is that upstream maintains the relevant bits of that duplicate code, which I'm sure you can see why they would be reluctant to do that.
Maybe libraries would help, although afaik, such libraries don't currently exist. And some compositors don't have public APIs for some of this functionality at all, and don't really want third party apps to have access, although it is frequently possible to use internal APIs if you can deal with it changing in backwards incompatible ways without any notice. I don't really understand your argument about "upstream" maintaining duplicate code. If there were standardized APIs, there wouldn't be any need for duplicate code.
I did neglect to mention before that all of these are to some extent, somewhat privileged operations, and it does make sense from a security perspective to limit what applications can do these things. However, a big missing piece of wayland is a standard way to grant certain application elevated privileges. From what I can tell most compositors either take the approach of not letting third party apps do a privileged action, or letting all third party apps do a privileged action. Granted it's a difficult problem for a variety of reasons, but the "third party apps aren't allowed to do privileged operations" stance obviously breaks things that worked in X.
The result is that on X11 I have a hotkey that automatically normalizes strings to their unicode normal form, something that is not as easily implementable in Wayland, or at all.
A far more basic example is that in order to open new card packs in Hearthstone, to buypass the chore that that involves I can in X11 quite easily send an endless string of space keypreses to an application window without having that window even open or focused. — this is not generally possible in Wayland. Looking it up, a tool ydotool exists to bypass this limitation, which requires root access and directly accesses the input devices to do so.
That's a genuine question — as in, I'm mostly thinking about Windows and how window message handling works with UAC windows. You can send messages to your own windows all day without needing extra permissions, but not other users' windows. I assume that's what you're referring to with the X11 sandbox; is it reasonable to set up Wayland _without_ such a sandbox?
I don't know about you, but I'd prefer my applications not be able to inject and read inputs arbitrarily, though it may be that even stricter sandboxing is needed to make that a reality; Wayland being stricter than X11 is just one step along the way.
It is not a situation of “it may be”; it is a situation of “it is”.
Right now, it is useless as the security boundary on Unix and any other operating system is fundamentally the user and malicious software that runs as one's user can modify every file and process one owns anyway.
I read one comment a while back by a developer that illustrated the fruitlessness of Wayland by saying that it is essentially a lock on a door, that stands in the middle of room, that one can simply walk around, claiming to add security.
There are also ways to sandbox X11, it's a bit harder to do, but you do have some options on how you'd like to do things.
The features of the protocol that are missing are what made Wine developers indefinitely shelf their attempt to port it and as I read it, this port indeed is only a partial port for certain use cases that can't map the entirety of Window's windowing a.p.i. as Wine generally can.
The reason many people aren't using Wayland is not because their favorite application does not support it yet, but because at this stage the protocol on a fundamental level does not allow them to do what they need to.
Just my observation, asking for X11-style sandbox escapes to support Wine is a mistake, it's much better to work with the system so it becomes feasible to run Wine applications within a sandbox. It just doesn't make sense to break Wayland's design because of other insecure legacy designs in the Win32 API.
Edit: AFAIK the only real reason X11 needs special support is because functionality that would normally be provided by an X window manager needs to be provided by the Wayland compositor, most of the heavy lifting translating the X11 protocol is done out-of-process in XWayland. The amount of code needed there on the Wayland server side is actually not particularly large, I don't know enough about all usages of the Win32 API to say how that compares.
I feel this is the misunderstandng.
You're reasoning from a perspective of “applications”.
Most users who are unsatisfied with Wayland's capabilities are reasoning from a perspective of “utilities” and “functionality”.
Wayland indeed repræsents a move towards the “everything is an app” philosophy. The functionality that is left behind that is needed for the workflow of many are the programs that are not applications and in no way manifest a visual user interface but nevertheless are required for many users.
Hi, so let me tell you an example I use, just so you have a broader perspective of how some people use their desktop.
I have eye problems so it is hard for me to read text, so I use different built in tools but I also create my own scripts combining CLI tools using bash or python.
One such script I use to have dialog from different text heavy games read to me, if the game/engine is open I can patch it to read the text directly but if is proprietary I use this following script
1 grab a screenshot of a section of the screen use a CLI program, I do not want a visual tool to be shown when I run it
2 using same CLI tools I apply transformations to the images, like grayscale and other stuff
3 I OCR the screen, image to text
4 I have the text read to me
My script uses cross platform CLI tools, it would work the same in all Linuxes, Windows and maybe OSX (did not check if all those CLI ones work on Mac but I think they work)
It would suck if I would not be able to use this CLI tools n future and have to make a GNOME/KDE or other DE extension 2 run some other transformation
For instance, I run a variety of scripts that automate the placement of windows as I desire it based on hotkeys. These scripts do not have any window of their own; they simply manipulate the placement of other windows or otherwise query their status to do this. — this is not generally possible on Wayland at this moment.
Such programs are also possible under Windows and are utilized by many users to enhance the functionality of their windowing system.
I'm sure Microsoft wants to rewrite their api. There are a lot of issues with it that are obvious with only a little knowledge. Those who know their api better than me can probably propose a better replacement than I can. However a replacement is tricky as Wayland shows, so I can't blame them for not going forward with it (at least not so far )
Yes it's in another API and technically not in the Wayland protocol but the functionality is there. It wouldn't make sense to expose all private state of the display server over the Wayland protocol.
Surely we can agree that being forced to hack the internals of the compositor by way of an unstable a.p.i. is a less than satisfactory solution compared to X11's stable, universal a.p.i.'s that work everywhere?
On X11, what I described can be done in a stable, standardized way; on Wayland, it requires hacking the compositor's internals in semi-supported, unstable ways.
These are the differences in features whereof I spoke that make Wayland and unrealistic platform for many users in it's current state.
The “if” on X11 at this stage is a theoretical obscurity with every modern window manager of note supporting it, with the user being confident that it shall remain stable; on Wayland, the reality is that every single compositor has it's own own, typically unstable ways of doing this, though Sway is the one that is committed to stabilizing it and wants it's way of doing these things to become a standard, but that is of little use when the others are not picking it up.
I would not say that Sway is doing anything special here, what they have done is exactly what I was saying earlier: placed the unstable private APIs in the Wayland protocol, with all the problems that entails. Applications should probably not be consuming those APIs directly, they will likely want to go through an abstraction layer.