search

probonopd / wayland-x11-compat-protocols

The missing Wayland protocols for features that are available in X11 (but are denied by the official Wayland protocols)
104 stars 3 forks source link

List Microsoft Windows features that are impossible to do with today's Wayland #8

Open probonopd opened 8 months ago

probonopd commented 8 months ago

List Microsoft Windows features that are impossible to do with today's Wayland (without additional software such as Portals, Pipewire, D-Bus, etc.).

Contributions welcome.

tildearrow commented 8 months ago

The list is so long since windowing is a natural part of the OS. I am going to list a few of these:

I am not going to include GUI, drawing, sound and similar functions, even if they're part of the Windows API, since these are out of scope.

lnee94 commented 8 months ago

I think a better target is stuff that is needed not what windows or mac has so list use cases that are unable to work in wayland. Thing is you can have all the fectures but if no one uses them your time is waisted.

probonopd commented 8 months ago

Hello @lnee94, thanks for sharing your thoughts.

I think a better target is stuff that is needed not what windows or mac has

Don't quite understand what you are saying.

Can we agree that Wayland needs at least the features that X11, Windows, and Mac (and probably every other halfway decent desktop operating system) have in common?

so list use cases that are unable to work in wayland.

See README.md in this repo.

Thing is you can have all the fectures but if no one uses them your time is waisted.

People need the features listed in the README.md but so far Wayland doesn't have them, and given the age of Wayland and its governance I doubt it's likely that they will be accepted there anytime soon. Hence this project to point out what is missing and - work still to be done - how it could be fixed.

lo2dev commented 8 months ago

For the sake of making this list sound valid I will exclude important software that makes a Linux computer run normally (Kernel, boot manager, network manager, etc.)

Wayland can't:

For a (apparently) monolith, Wayland does a bad job. Our best et would be to get rid of all these components and let Wayland do the work.

a-weasel commented 8 months ago

I think a better target is stuff that is needed not what windows or mac has so list use cases that are unable to work in wayland. Thing is you can have all the fectures but if no one uses them your time is waisted.

Who defines what "no one uses"? Did you ask everyone who uses Windows, every power user who writes their own scripts to automate their workflows? Stop acting like you're in charge of other people's workflows.

a-weasel commented 8 months ago

Anyway @probonopd thanks so much for this repo, at least it's an eye opener for many. God bless.

I think a good chunk that Windows can do, and a lot of power users use (even people who aren't typical software/app devs), is exposed through AutoHotkey. Stuff like querying Windows positions are very basic and essential when automating your workflow with such scripts written by yourself (or downloaded from others).

People also use it a lot to inspect other Window contents (pixels for example, or their controls/children windows) and act accordingly, especially when automating things.

Of course I'm not even talking about it registering hotkeys without having to mess with the system or user session, which is essential when you want to share scripts or move them across systems (for personal use).

And it can even be used with Wine on Linux (and yes it works), but of course not on Wayland since it will lack a ton of functionality. Wayland also has issues with Wine btw, even if the Wayland driver is in its infancy on Wine side, it will simply be unable to do some things like the window positioning mentioned earlier. It's a known issue even for Wine devs.

myownfriend commented 8 months ago

As lo-kiss was getting at: why are you we comparing Wayland to an entire operating system?

  • Disable compositing, at least before Windows 8

Wayland is a compositing protocol...

...also Wayland compositors already selectively disable compositing by using direct scan out.

  • Tearing. Can't do so on Wayland unless your compositor, kernel, graphics card, driver and software (!!!) supports it.

Wayland has a tearing protocol. What is Wayland supposed to do about the kernel, graphics card, driver, and software?

  • Data query. Get cursor position, cursor type, cursor image, keystrokes, list of windows, get their icons, positions, sizes... you name it.

  • Capture and alter keyboard/mouse inputs

  • Move the cursor, send mouse inputs, send keyboard inputs...

  • Window capture

  • Screen capture

If Windows 12 flipped the security model to be more like Wayland and required permissions to do all of these things, would Wayland be vindicated or would it still be an issue because Wayland itself doesn't provide the permissions?

The problem with comparing Wayland to an entire operating system is that Windows 12 could work identically to Wayland with something like Portals used to provide permissions but it wouldn't matter because you don't have the option to complain about it's use of something Portal like anyway and it would always be available.

probonopd commented 8 months ago

If Windows 12 flipped the security model to be more like Wayland and required permissions to do all of these things

That would be a valid choice for Windows, because as an operating system and as a desktop environment, Windows can be opinionated about how their user experience should be. Some people might like it, others wouldn't.

(My personal 2 cents, but not really essential for this discussion: When I compare Windows 11 to Windows 2000, I would prefer to use Windows 2000 from a user experience standpoint at any time without hesitation. Mainly because Windows 2000 did not have annoying popups, warnings, nag screens, confirmation dialogs, notifications. These things are extremely annoying for me and I am always trying to disable all of them.)

For Wayland, the situation is very different: It is supposed to run on many different operating systems and be used by many different desktop environments, none of which are designed by the same people, for the same use cases, or even share a common user experience vision. Unfortunately it seems like the people designing Wayland are often thinking of Gnome, but the truth is that not everything wants to nor should work like Gnome. (We are entering the realm of personal preferences here, and different people have different needs and preferences. The gold standard when it comes to the desktop, for me anyway, is still the the Macintosh human interface guidelines from the early 90s, based on the seminal work done at Xeroc PARC.)

The problem with comparing Wayland to an entire operating system is that Windows 12 could work identically to Wayland with something like Portals used to provide permissions but it wouldn't matter because you don't have the option to complain about it's use of something Portal like anyway and it would always be available.

Exactly my point. Since Wayland is just the thing that renders pixels to the screen, it must not make any assumptions about how the user experience of the operating system, window manager, desktop environment, and applications will be. It just needs to provide them all they need to do whatever they want. In other words, unlike an operating system, Wayland's design must not be "opinionated".

ssokolow commented 8 months ago

The gold standard when it comes to the desktop, for me anyway, is still the the Macintosh human interface guidelines from the early 90s, based on the seminal work done at Xeroc PARC.)

If anyone wants to give it a read, it's in the Internet Archive's lending library as well in offline-usable digital form in many of the countless monthly "Apple Developer CD Reference Library" discs that got shipped out over the years in Apple's equivalent to MSDN subscriptions. (They rolled it into the digital editions of Inside Macintosh.)

myownfriend commented 8 months ago

That would be a valid choice for Windows, because as an operating system and as a desktop environment, Windows can be opinionated about how their user experience should be. Some people might like it, others wouldn't.

It's valid for Wayland, too, because it just makes sense.

(My personal 2 cents, but not really essential for this discussion: When I compare Windows 11 to Windows 2000, I would prefer to use Windows 2000 from a user experience standpoint at any time without hesitation. Mainly because Windows 2000 did not have annoying popups, warnings, nag screens, confirmation dialogs, notifications. These things are extremely annoying for me and I am always trying to disable all of them.)

I could have guessed that. You definitely have a thing for older designs. Older Windows, older OSX, X11, etc.

I'm not sure how your criticisms of Windows 11 apply to Wayland though.

For Wayland, the situation is very different: It is supposed to run on many different operating systems and be used by many different desktop environments, none of which are designed by the same people, for the same use cases, or even share a common user experience vision.

And?

Unfortunately it seems like the people designing Wayland are often thinking of Gnome, but the truth is that not everything wants to nor should work like Gnome.

Okay. Stop. You and I both know that you don't know enough about Wayland or followed it's development well enough to make that claim. You know that it was started by a guy at Redhat, you associate Redhat with Gnome, and thus you think it's a Gnome invention.

Gnome, KDE, Sway, Enlightenment, Collabora, Samsung, and other have all had a part in developing Wayland. The first 14 releases were developed by Kristian when he was working at Intel, not Redhat.

Wayland's core protocol is minimal so that it can be useful to different desktop environments. It's original use-case was actually embedded systems and that seems to be working. Gnome, KDE, Enlightment, Sway, Wayfire, and Hypraland all use Wayland and work very differently from each other. XFCE, LXQT, and Cinnamon have all started transitioning to Wayland. Cinnamon's recent release already has experimental support for it.

What about the protocol is Gnome-centric in your opinion?

(We are entering the realm of personal preferences here, and different people have different needs and preferences. The gold standard when it comes to the desktop, for me anyway, is still the the Macintosh human interface guidelines from the early 90s, based on the seminal work done at Xeroc PARC.)

Yea, I know that. I've seen your takes on Gnome not being designed for desktops for example. I'm not gonna disagree that Xerox PARC came up with excellent ideas that aged well, but acting like things that depart from it aren't well-suited to keyboard and mouse control is just closed-minded and lack creativity.

Exactly my point. Since Wayland is just the thing that renders pixels to the screen, it must not make any assumptions about how the user experience of the operating system, window manager, desktop environment, and applications will be. It just needs to provide them all they need to do whatever they want. In other words, unlike an operating system, Wayland's design must not be "opinionated".

How it making any more assumptions about how the OS, window manager, DE, and applications will be than Xorg? Is it because it expects the compositor to use Portals? Would it make you feel any better if Portals and Pipewire were just part of something called Wayland?

probonopd commented 8 months ago

What about the protocol is Gnome-centric in your opinion?

E.g., the idea that users run untrusted applications on their system (the whole SELinux, Flatpak, Bubblewrap, Portals,... kind of thinking). The idea that it is acceptable to have GLib, D-Bus, etc., as dependencies.

Would it make you feel any better if Portals and Pipewire were just part of something called Wayland?

I would feel better if Portals and Pipewire were not forced upon everyone who has to use Wayland, just like with X11.

probonopd commented 8 months ago

In https://www.youtube.com/watch?v=relxcJiHBnA&t=1230s @afrantzis explains how Windows is "prescriptive" whereas Wayland is "descriptive". The WINE developers have to go through many "a bit hacky" hoops to make WINE work properly under Wayland, just because the fundamental philosophy in Wayland is incompatible.

So what is missing in Wayland is to allow applications to be "prescriptive", with no second-guessing from the compositor.

Window icons, window positioning, drag-and-drop,... the WINE developers will likely run into all the complicated Wayland issues that need to be resolved one way or the other.

Really appreciating the work @ivyl and other WINE developers are doing; the amount of suffering they are taking must be enormous.

myownfriend commented 8 months ago

E.g., the idea that users run untrusted applications on their system (the whole SELinux, Flatpak, Bubblewrap, Portals,... kind of thinking).

They do. Not intentionally, but they do.

The idea that it is acceptable to have GLib, D-Bus, etc., as dependencies.

Why not? Also...

I would feel better if Portals and Pipewire were not forced upon everyone who has to use Wayland, just like with X11.

...Wayland isn't dependent on Portals. Wayland is a protocol. Portals are just a safe way for applications to do things certain things that Wayland intentionally doesn't do. As I've said before, while Portals and Pipewire compliment Wayland's functionality, they can be used on X11, too. De-coupling the features provided by Portals and Pipewire means that it can provide that functionality across display server protocols. If a protocol called Probono replaced Wayland then and Wayland clients needed to run in a compatibility layer called Waybono, then clients like OBS would still maintain their functionality.

The alternative is true, too. Replacements to Pipewire and Portals can be made and OBS wouldn't need to port to a whole other display server protocol in order to use it, it could just add support for the replacements.

The WINE developers have to go through many "a bit hacky" hoops to make WINE work properly under Wayland, just because the fundamental philosophy in Wayland is incompatible. So what is missing in Wayland is to allow applications to be "prescriptive", with no second-guessing from the compositor. You took the wrong lesson from that. He's not suggesting that either is right or wrong. Also suggesting that Wayland should just do as Windows does because Windows does it would be dumb.

Window icons, window positioning, drag-and-drop,... the WINE developers will likely run into all the complicated Wayland issues that need to be resolved one way or the other.

You're aware that the Wine Wayland driver is currently being up-streamed and it supports drag and drop already, right? It's not something they just started working on. Over 20 patches have been merged already.

https://gitlab.winehq.org/wine/wine/-/merge_requests?scope=all&state=opened&search=wayland

probonopd commented 8 months ago

You're aware that the Wine Wayland driver is currently being up-streamed and it supports drag and drop already, right?

I haven't tested it yet, but from the description of it it seems to me that its developers have to go through a lot of pain just to get the functionality that's needed. I applaud them for the effort, actually I am surprised that someone voluntarily puts in this much time to work around what is arguably a hostile environment (Wayland) designed to make it as hard as possible to do what you want to do.

myownfriend commented 8 months ago

I am surprised that someone voluntarily puts in this much time to work around what is arguably a hostile environment

For the past few years you've been one of the most voices in opposition to something that you admitted didn't know anything about when you started your crusade. Literally anything that asks you to do something even a little differently than the way you've accustomed to do things has received push back from you. Even in your original gist you have refused to correct things in the first post that you were corrected on years ago.

probonopd commented 8 months ago

Exactly. I don't want to develop on moving targets. And I don't want others to dictate how my desktop has to work.

myownfriend commented 8 months ago

Exactly. I don't want to develop on moving targets. And I don't want others to dictate how my desktop has to work.

If that's the case then keep using X11. It's dead. Can't get a more un-moving target than that.

probonopd commented 8 months ago

That's probably a big part of why I like it - the last decade or so it was a stable platform you could rely on not changing in unexpected ways anymore. That's when software is imho mature, and is best. Companies call this "LTS" and pay lots of money for it.

myownfriend commented 8 months ago

That's probably a big part of why I like it - the last decade or so it was a stable platform you could rely on not changing in unexpected ways anymore. That's when software is imho mature, and is best. Companies call this "LTS" and pay lots of money for it.

Protocols don't change in the way you're thinking. Additions to the protocol aren't supposed to break other protocols. You might gain additional functionality through extensions as the protocol progresses but the stuff you're using already doesn't start doing other things.

probonopd commented 8 months ago

At least that's how it should be @myownfriend.

myownfriend commented 8 months ago

At least that's how it should be @myownfriend.

That's how it is. It's exactly why Wayland was created. Many aspects of X11 were impossible to fix without breaking the core protocol. Obviously if you're going to make breaking changes then you need to at least bump the major version number. That's basically what they did, but instead of calling it X12 they called Wayland.

Right now Wayland does have unstable protocols for testing purposes but they're clearly marked that. Once they get moved into staging, there is no backwards incompatible changes that can be made but they can be completely replaced in a new major version of the extension or with a completely different extension. Once it's in stable, it doesn't change.