Open Quackdoc opened 8 months ago
What exactly is the goal of this repo.
This repo shall give a home to the missing protocols that are unlikely to get accepted by wayland-protocols upstream.
https://github.com/probonopd/wayland-x11-compat-protocols?#what-is-this
Doing things upstream is preferred, but since Wayland has been around for so long and still can't do what X11 can do natively gives me little hope that upstream will want to fix this (otherwise they'd already have done that).
Keeping security in mind, but with a feature first mentality is what will help this project succeed.
Well said. Let's not "disregard" security, but let's not use it as an excuse for missing functionality. Let's make things work first and foremost.
So, what to do with this repository?
Well said. Let's not "disregard" security, but let's not use it as an excuse for missing functionality. Let's make things work first...
That's disregarding security already. Security isn't something you should just figure out after the fact.
1. Write XML protocols that describe the functionality that is available in X11/Windows/macOS but is so far missing from Wayland (ideally in the most X11 compatible way possible in terms of logic)
Why? Why any of this? Why are you comparing X11 and Wayland to whole operating systems like Windows or macOS? There's tons of things that operating systems do that X11 and Wayland should never do.
And why should these Wayland protocols be done in the most X11 compatible way possible? Do you have any complaints at all about how X11 works or is it the only way that you've ever known or could imagine a display server/compositing protocol to work? Is there any intention on improving on X11 or do you just want to preserve it under a new name?
2. _Some_ compositor (library) will eventually pick them up, hopefully
That's very unlikely especially when you're not very familiar with how Wayland works to begin with. No Wayland compositor is going to implement a protocol that breaks compatibility with other Wayland protocols for example.
3. Users will flock to that compositor (library), because stuff "just works" there
That's also unlikely because things won't "just work". There's no reason that they would "just work". I really feel like you have a lot of built-in naivety about how this stuff works because, as far as you know, X11 has just always been there. It's the default and every other way to implement X11-like functionality is hacky. You made that clear in your Gist when you said that Qt needs a plugin to support Wayland... and completely ignored that you need one to support X11, too.
Honestly before you ever started that gist or this repo you really should have made some attempt to understand how support for X11 and Wayland work.
If you have confidence that the protocols that you create here would be so amazing that compositors will implement it and flock to it, you don't like Wayland at all, and want it to work like X11 then why not just create extensions to X11? Or better yet, why not create X12?
Why? Why any of this? Why are you comparing X11 and Wayland to whole operating systems like Windows or macOS? There's tons of things that operating systems do that X11 and Wayland should never do.
because some people have different needs then you, I myself would quite like it if the apps I require can be ported to wayland. Especially if we are going to migrate to it. On the contrary, I don't see why people are so hellbent on refusing to pick up the good things from x11, osx, or windows. Why let disdain for other platforms bar wayland from being the best it possibly can be? I don't see why "Wayland supporters" are so focused on preventing wayland progress
And why should these Wayland protocols be done in the most X11 compatible way possible?
Is not better to simply porting for developers? when possible it would be really nice not to use a bunch of ifdefs
Is there any intention on improving on X11
Your previous statements indicate this is exactly what you want to prevent
That's very unlikely especially when you're not very familiar with how Wayland works to begin with. No Wayland compositor is going to implement a protocol that breaks compatibility with other Wayland protocols for example.
If the protocols are good and useful, I don't see why people wouldnt be willing to put effort into using them.
That's also unlikely because things won't "just work". There's no reason that they would "just work".
I'm not sure you understand, This wasn't about developers, this was about users, Users will go to the platform where the apps they want/need actually work, If a developer puts the time
If you have confidence that the protocols that you create here would be so amazing that compositors will implement it and flock to it, you don't like Wayland at all, and want it to work like X11 then why not just create extensions to X11? Or better yet, why not create X12?
This is just a dumb statement, wlroots implements their own protocols that other compositors implement, do they not like wayland too?
Security isn't something you should just figure out after the fact.
Imho making something work at all comes first, before you add restrictions (that some people think make it more secure). The Internet works the same way. HTTP first, HTTPS second. And so on. Wayland feels to me like people are thinking about two factor authentication already before they have even figured out basic HTTP (that's a metaphor; in reality Wayland hasn't even figured out the most basic window management tasks like pixel-exact positioning of windows on the screen).
Why? Why any of this? Why are you comparing X11 and Wayland to whole operating systems like Windows or macOS? There's tons of things that operating systems do that X11 and Wayland should never do.
Because the job of an operating system and a display server (I call Wayland compositors that) is to allow applications to do what applications need to do. And that is determined by the functionality given in the main desktop operating systems, which are Windows, macOS, and (X11 based) "Desktop Linux". Most real-world applications are cross-platform and run on all of these, and I expect them to have full functionality on all of these. To be useful on the desktop, as a bare minimum, Wayland needs to provide the least common denominator in terms of functionality between Windows, macOS, and (X11 based) "Desktop Linux". Only then it is suitable for creating cross-platform applications that work on Wayland just as well as everywhere else. Today, Wayland artificially restricts what applications can do in ways the other platforms don't.
And why should these Wayland protocols be done in the most X11 compatible way possible?
To provide a smooth transition path to developers of applications and desktop environments who don't appreciate to spend time re-architecting the whole logic. We'd like to just replace X11 function calls with the corresponding Wayland function calls and be done with it as fast as possible. We haven't asked anyone to force us to spend much time on this.
Is there any intention on improving on X11 or do you just want to preserve it under a new name?
Anything that is promoted to eventually replace X11 needs to at least provide what X11 provides. Once that is done, one can think about adding other stuff and making further improvements. But before even the most basic stuff works, thinking about all those wonderful improvements isn't useful because Wayland as such isn't an option yet.
No Wayland compositor is going to implement a protocol that breaks compatibility with other Wayland protocols for example.
It would probably need to be done in was that don't break other protocols then.
as far as you know, X11 has just always been there
Exactly. For all intents and purposes, by now X11 is so well-established that it "just works". A very high bar to be measured against.
Honestly before you ever started that gist or this repo you really should have made some attempt to understand how support for X11 and Wayland work.
Stuff just worked. One day, I ran a Fedora Live ISO and I noticed that even the most basic stuff wasn't working properly anymore. I researched why that was, and the answer was "Wayland". Ever since, I have been collecting issues I've encountered when running Wayland, in the hope that the people who are trying to shove Wayland down our throats will see and fix the issues. Well, time has passed and the stuff still isn't fixed. So it's time to go from merely collecting stuff that's broken to describing what's needed to un-break stuff.
If you have confidence that the protocols that you create here would be so amazing that compositors will implement it and flock to it, you don't like Wayland at all, and want it to work like X11 then why not just create extensions to X11? Or better yet, why not create X12?
My assumption is that application developers and end users are forced to use whatever "display server" protocol is the default, and it looks like that ship has sailed once Canonical stopped working on the original Mir. So at this point, the only realistic change is to fix the obvious glaring gaps in the Wayland protocols.
Imho making something work at all comes first, before you add restrictions (that some people think make it more secure).
Unfortunately, Java Applets were designed on the "make it work, then sandbox it" model and they were a never-ending parade of security exploits.
Things which learned from that experience, like WebAssembly, apply capability-based security... basically, an extension of how protected memory works by only mapping memory into the process's address space if it's supposed to have access to it in the first place.
(i.e. WASI doesn't work by specifying absolute filesystem paths. All paths are rooted in one of the handles passed in by the runtime environment... sort of like a Windows program where C:\
and D:\
are chrooted and all other syntaxes for absolute paths are disallowed at the kernel level, despite the NT kernel actually using a POSIX-esque singly-rooted virtual filesystem internally.)
Similarly, history is proving the decision to make mutability default in C and C++ and have a const
keyword to have been wrong. Human programmers and administrators just don't have the attention to reliably get all these things right when you only need the attacker to get lucky once.
Today, Wayland artificially restricts what applications can do in ways the other platforms don't.
How else do you propose to reliably mitigate the confused deputy problem, where an X11 application in a sandbox can simply remote-control another application that's not in the sandbox because things like Chrome/Chromium have normalized "WONTFIX: Running with the X11 security extension is an unsupported configuration. Put your X server back into the default configuration."
Anything that is promoted to eventually replace X11 needs to at least provide what X11 provides.
Yes, but not necessarily using the same low-level APIs to achieve those same high-level goals. That's why there's so much bikeshedding in the Wayland protocol repos.
As summarized here, not everyone is buying into the notion of running "untrusted", "evil" applications and hence encumbering everything to death. This mindset doesn't reflect the advantages of a friendly, collaborative environment that is open source in the first place.
Software is written by humans. Humans are inherently incompetent. That's why "defense in depth" is a standard baseline for proper security.
Imho making something work at all comes first, before you add restrictions (that some people think make it more secure).
That doesn't work well. That's exactly why XACE would break X applications. Applications were built with certain assumptions that were broken by XACE.
The Internet works the same way. HTTP first, HTTPS second.
How is this anything like HTTP and HTTPS? HTTPS just encrypts the packets. Provide for me an example of how that would apply to a display server?
Wayland feels to me like people are thinking about two factor authentication already before they have even figured out basic HTTP
I mean it's not anything like that but again, you seem to be allergic to learning anything about Wayland.
(that's a metaphor; in reality Wayland hasn't even figured out the most basic window management tasks like pixel-exact positioning of windows on the screen).
What's to "figure out"?
Because the job of an operating system and a display server (I call Wayland compositors that) is to allow applications to do what applications need to do. And that is determined by the functionality given in the main desktop operating systems, which are Windows, macOS, and (X11 based) "Desktop Linux". Most real-world applications are cross-platform and run on all of these, and I expect them to have full functionality on all of these. To be useful on the desktop, as a bare minimum, Wayland needs to provide the least common denominator in terms of functionality between Windows, macOS, and (X11 based) "Desktop Linux". Only then it is suitable for creating cross-platform applications that work on Wayland just as well as everywhere else. Today, Wayland artificially restricts what applications can do in ways the other platforms don't.
This is stupid and nonsensical. You just said that, because an OS and display server is supposed to allow an application to do everything it needs to do, Wayland's job is to provide the least common denominator in terms of functionality between the big three OS's.
Why? Comparing X11 or Wayland to whole OSs just doesn't work. You're ultimately just taking the long way to saying that you feel Wayland should do all the same stuff as X11.
Can you name what the Windows equivalent to X11 or Wayland is? Is there one? If it there is, is it the same thing that allows an application to do screen or input capture? If its not then why is that the case? What if having different things provide those functionalities is just a smart idea with a bunch of advantages? Should a Linux-based OS go with the inferior solution just because they were traditionally done by X11?
To provide a smooth transition path to developers of applications and desktop environments who don't appreciate to spend time re-architecting the whole logic. We'd like to just replace X11 function calls with the corresponding Wayland function calls and be done with it as fast as possible. We haven't asked anyone to force us to spend much time on this.
That would be nice and all but the only way to do that is if the new protocol worked identically to the old one. If that were the case then it wouldn't be improving on the old thing at all then would it? Hell, if that were the case then an X11 application wouldn't even need to be updated at all.
Anything that is promoted to eventually replace X11 needs to at least provide what X11 provides. Once that is done, one can think about adding other stuff and making further improvements. But before even the most basic stuff works, thinking about all those wonderful improvements isn't useful because Wayland as such isn't an option yet.
Wayland is certainly an option, it just doesn't work like X11 so it's confusing to you. Now answer the question: what would you improve over X11? I'm not talking about additions, I'm talking about improvements.
It would probably need to be done in was that don't break other protocols then. "Probably". No it would need to be done in a way that doesn't break other protocols. The entire reason why work on X11 was abandoned was because it wouldn't be possible to fix it's issues without breaking the core protocol and you really can't have a protocol that breaks itself.
Once is was decided to break compatibility with X11, there ceased to be a reason to needlessly make the protocol similar to the protocol that people were trying to get away from to begin with.
Exactly. For all intents and purposes, by now X11 is so well-established that it "just works". A very high bar to be measured against.
That's because whole ecosystems were built around X11. It didn't always "just work", applications needed to add support for it. X11 still doesn't "just work" either, or rather it entirely depends on your use-case. I've said before that I couldn't stand the constant tearing and the lack of proper multi-monitor support in X11 so Wayland works significantly better for me.
Stuff just worked. One day, I ran a Fedora Live ISO and I noticed that even the most basic stuff wasn't working properly anymore. I researched why that was, and the answer was "Wayland". Ever since, I have been collecting issues I've encountered when running Wayland, in the hope that the people who are trying to shove Wayland down our throats will see and fix the issues. Well, time has passed and the stuff still isn't fixed. So it's time to go from merely collecting stuff that's broken to describing what's needed to un-break stuff.
This is so stupid. First off, what basic things did you try to do that didn't work? And why was your first thought to collect a list of issues (some of which were already outdated when you posted) and complain about Wayland instead of first learning what this new things was and how it worked? Over a year into that thread you were figuring out stuff that you should have known after a few days of learning about Wayland. How are you going to un-break something that you don't understand? When say that Wayland "breaks" an application that doesn't support Wayland then you fundamentally don't know what's going on. It's like saying Linux breaks Photoshop because Photoshop isn't designed to run on Linux.
Nobody is trying to "shove Wayland down your throat". That's the most frequent claim that techy conservatives make about any all new technologies. X11 is from 1987. It has a lot of issues, it's needed replacing for decades and it wasn't happening which made the migration to something new waaaay more difficult.
My assumption is that application developers and end users are forced to use whatever "display server" protocol is the default, and it looks like that ship has sailed once Canonical stopped working on the original Mir. So at this point, the only realistic change is to fix the obvious glaring gaps in the Wayland protocols.
How? So far one of the suggestions you've brought up is to change Wayland security model completely so it works like the broken one that X11 had.
How is this anything like HTTP and HTTPS? HTTPS just encrypts the packets. Provide for me an example of how that would apply to a display server?
HTTP made it possible to send information from A to B by assuming a trusted network. (Much) later, the security aspect was added for those who need and want it. In some applications, the security overhead is not needed - this is where HTTP is still in use today.
What's to "figure out"?
Provide a straightforward way to let applications do exactly what they want to do without second-guessing it.
Comparing X11 or Wayland to whole OSs just doesn't work.
Partially agree with you there. So we need to be more precise: An operating system which uses Wayland must be able to achieve what the other desktop OSes achieve. Unfortunately, today's Wayland developers seem to have the mindset that they don't want to allow everything that is possible on the other desktop OSes. Example: Wayland developers think that applications should not be able to set window icons to anything else than what is defined in desktop files. This is a totally arbitrary worldview not known from Windows or the Mac. And this "dictatorship" mentality is what holds back Wayland big time.
Can you name what the Windows equivalent to X11 or Wayland is?
No. But that is because I never have looked into Windows architecture. All I can say is that the stuff works on Windows.
Now answer the question: what would you improve over X11
Well, my point is: The whole "improving stuff over X11" topic should only become relevant once Wayland has parity with X11. Only then I would begin to think about improving it. Parity first (must have), everything else second (nice to have). Reason: Taking away something from people is much, much more hurtful than not having something in the first place.
If someone takes away the pillow from your bed it will annoy you much more than if no one adds an electric heater under your mattress.
This is so stupid. First off, what basic things did you try to do that didn't work?
Back in the time? E.g., clicked the applications button in Gnome, saw the icon animations stutter on my "big" Nvidia GPU. Tried to record the screen with voice. The list doesn't end there, I've collected the breakages in a whole gist. ut heck, many of these things still don't work today - especially outside of Gnome and KDE.
Once is was decided to break compatibility with X11, there ceased to be a reason to needlessly make the protocol similar to the protocol that people were trying to get away from to begin with.
And this a lot of unnecessary and frustrating work was created for application developers and desktop environment developers who hadn't asked for Wayland to be a thing in the first place. I won't even start to seriously think about porting my software to Wayland as long as it feels like a "hostile environment" to me as a developer, taking away my freedoms.
That's because whole ecosystems were built around X11.
Exactly. And Wayland breaks those. Which is a giant waste of invested time and money. It is throwing back "Linux on the Desktop" for at least one to two decades. Imagine Microsoft would introduce a radically new paradigm for Windows. Hell would break loose. There is a reason they haven't really done this. Think of the disaster that was Windows 8, and those were only superficial UX changes.
When say that Wayland "breaks" an application that doesn't support Wayland then you fundamentally don't know what's going on.
Been running "Desktop Linux" since around 2000, so for almost a quarter century. Since Wayland is here, it produces trouble. It results in things not working anymore that have worked nicely before. It's a fact. When Wayland entered the scene, its developers apparently thought that everyone would be happy to abandon or rewrite existing applications, window managers, desktop environments, and so on. And that everyone would be happy to change paradigms. But this is not true. There is a significant developer base and user base who just wants to continue stuff to work like it has until Wayland came into the picture.
How is this anything like HTTP and HTTPS? HTTPS just encrypts the packets. Provide for me an example of how that would apply to a display server?
HTTP made it possible to send information from A to B by assuming a trusted network. (Much) later, the security aspect was added for those who need and want it. In some applications, the security overhead is not needed - this is where HTTP is still in use today.
I repeat: how is this similar?
Provide a straightforward way to let applications do exactly what they want to do without second-guessing it.
There's nothing to figure out. The whole point is to not let applications do everything I want to do but to instead give the app user control.
This isn't a matter of Wayland's developers just not understanding how to give clients unfettered control over everything. That's easy and that's what X11 does. The point is to make something better and not something identical to what people came up with in 1987.
Partially agree with you there. So we need to be more precise: An operating system which uses Wayland must be able to achieve what the other desktop OSes achieve.
That's a much fairer question. There's a lot of things that an operating system using Wayland can do. Like I said, Wayland protocols alone can already handle a large amount of applications. If the operating system uses Portals too then it can do even more. There's no reason that Wayland alone needs to provide the operating system with all of the same capabilities that X11 does just because X11 decided that all these things should be part of the display server protocol. An operating system is many parts and an application doesn't just communicate with a display server protocol.
There was many things that Windows, macOS, and Linux do that provides the same functionality to applications but it doesn't require that the software stack be grouped in the same ways.
Unfortunately, today's Wayland developers seem to have the mindset that they don't want to allow everything that is possible on the other desktop OSes.
That's not true remotely. They just don't feel that Wayland needs to be the sole provider of any and all functionality that an application uses. Wayland could include a drawing API, an alternative to EGL, a print server, etc. just like X11 used to but why do that why do that when it would make sense to have those things be separate?
Example: Wayland developers think that applications should not be able to set window icons to anything else than what is defined in desktop files.
I'll say it again. There is currently a proposal to provide per window icons. https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/269
Please stop acting like I didn't say or post something just because it's not currently on your screen anymore.
This is a totally arbitrary worldview not known from Windows or the Mac. And this "dictatorship" mentality is what holds back Wayland big time.
Literally nothing dictatorial about some people in the discussion making a case for an alternative. Do you intend to accept any protocol that someone suggests as soon as it's proposed?
No. But that is because I never have looked into Windows architecture. All I can say is that the stuff works on Windows.
And you don't think that's relevant when comparing how Windows handles stuff vs how a Wayland desktop would approach things? If you like that it "just works" then why not look into why? Maybe it works well because separate things out like Wayland and Portals do and the app adoption has just been better.
I can tell you that windows doesn't really have an anything that's a direct analog to X11 or Wayland. I can tell you that Windows 10 and up also offer a Screen Capture API that brings up a built-in prompt that allows you to select a screen just like Portals do.
Well, my point is: The whole "improving stuff over X11" topic should only become relevant once Wayland has parity with X11. Only then I would begin to think about improving it. Parity first (must have), everything else second (nice to have). Reason: Taking away something from people is much, much more hurtful than not having something in the first place.
X11 already has feature parity with X11. How would you improve X11 or what would be different about in an X12 if you were creating it?
If someone takes away the pillow from your bed it will annoy you much more than if no one adds an electric heater under your mattress.
That doesn't really apply. It seems like most of the argument is that you feel the pillow and sheets should come with the mattress and they should only be used with each other. I'm saying it's fine to get those things separately and use them together.
Back in the time? E.g., clicked the applications button in Gnome, saw the icon animations stutter on my "big" Nvidia GPU. Tried to record the screen with voice.
When was this and why was their stuttering?
The list doesn't end there, I've collected the breakages in a whole gist.
Don't link me to a gist that you know I'm aware of. Anything that lists issues like "Wayland breaks xclip" isn't something that should be taken seriously.
but heck, many of these things still don't work today - especially outside of Gnome and KDE.
Like?
And this a lot of unnecessary and frustrating work was created for application developers and desktop environment developers who hadn't asked for Wayland to be a thing in the first place.
Who are you speaking for? If these desktop environment developers didn't ask for it in the first place then why are they implementing it. Just because you would perfectly happy eternally living in 2002 doesn't mean that everyone wants to live in their nostalgia to the same degree.
I won't even start to seriously think about porting my software to Wayland as long as it feels like a "hostile environment" to me as a developer, taking away my freedoms.
Forget about porting anything when you haven't made much of an effort to learn about what you're doing.
MUH FREEDUM
Exactly. And Wayland breaks those. Which is a giant waste of invested time and money. It is throwing back "Linux on the Desktop" for at least one to two decades.
Wow that's a stupid take. Are you aware of how many people use multiple monitors that are mismatched today? X11's lack of real multiple monitor support alone would disqualify it for daily use by most people. Add the constant tearing on top of that and it's it becomes a super hard sell.
When I first started using Linux, I was shocked at how well it worked out of the box on my dual monitor setup. Things just worked. Then I found out I was on Nvidia's open source driver and I didn't know it at the time but I was using Wayland. Once I switched to the proprietary one I got switched back to Xorg and I had no idea why things suddenly stopped working well.
It made it feel like Linux's graphics stack was 15 years behind Windows and I was thinking I'd have to switch back. Then I saw that Nvidia was finally planning to support dma-buf which would give XWayland apps hardware acceleration. I didn't know what the was but I decided to do what I needed to do to try it out to see if it would fix any of the issues I was having. Even with XWayland apps using llvmpipe, I preferred using Wayland over Xorg and I used it as much as I could. After Nvidia started supporting GBM, I've had to no reason to go back to Xorg.
Imagine Microsoft would introduce a radically new paradigm for Windows. Hell would break loose. There is a reason they haven't really done this. Think of the disaster that was Windows 8, and those were only superficial UX changes.
There's a lot that Windows 8 did wrong but its also over-hated.
Been running "Desktop Linux" since around 2000, so for almost a quarter century. Since Wayland is here, it produces trouble.
Bruh, if you've been using Xorg for 23 years and didn't have any issues with then you're stoned. Some of the earlier articles I could find calling for X11 to be replaced literally started around then.
This article is 23 years old... https://lwn.net/Articles/26608/
...and here's a few quotes from it
"Since the early days, X has been the target of severe criticism. Attackers claim that it is over-engineered and bloated"
"Its absolute refusal to dictate policy (or even provide a standard window manager) has led to wildly incompatible interfaces on the same desktop" - this is actually a thing I've heard X loyalists say about Wayland.
"The network-based client/server protocol is slow and has led to security problems"
"X, it is said, is "vacuumware," it sucks, but succeeded because there was nothing else out there."
At the time Debian shipped with a "fortune" file that just included six diatribes about how X11 sucks. https://lwn.net/Articles/26612/
Here's some quotes from that...
"The windowing system preferred by masochists 3 to 1." "The ultimate bottleneck. Flawed beyond belief." "If it works, it isn't X windows." "Elevating brain damage to an art form. X windows." "There ARE no rules. You'll wish we were kidding. Everything you never wanted in a window system. And more. Dissatisfaction guaranteed."
Here's a more recent article from 2010 discussing it's flaws
It results in things not working anymore that have worked nicely before.
Again, it doesn't. If an applications doesn't support Wayland and it runs fine in an X11 session, then it didn't break.
It's a fact. It's not.
When Wayland entered the scene, its developers apparently thought that everyone would be happy to abandon or rewrite existing applications, window managers, desktop environments, and so on. And that everyone would be happy to change paradigms.
Wayland's developers were just tired trying to work around X11's issues. You can't add extension to fix things that are broken with the core protocol.
But this is not true.
Yea, they didn't account for Probonopd not liking it.
There is a significant developer base and user base who just wants to continue stuff to work like it has until Wayland came into the picture.
Wrong. They want things to work better than X11.
Wrong. They want things to work better than X11.
True... for example, I was looking forward to finally removing the ability for games to jumble up my desktop icons and windows by using XRandR to fullscreen themselves... but not at the expense of breaking my current workflows.
(Which mainly means "I'll stay on my LTS distro X11 until KWin Wayland's patches for crash recovery have made it into releases of the various toolkits and I've had time to verify that KWin scripts can be used to replicate everything I do with wmctrl and xdotool that ydotool can't".)
There's nothing to figure out. The whole point is to not let applications do everything I want to do but to instead give the app user control.
The point of whom? And who are they to dictate that all systems must work their way?
Some people want to let applications do everything without nagging the user. It's open source, so if it isn't there yet, we make it.
This isn't a matter of Wayland's developers just not understanding how to give clients unfettered control over everything. That's easy and that's what X11 does. The point is to make something better and not something identical to what people came up with in 1987.
Then let's make that, because that's exactly what we want here. We have not asked anyone to make Wayland complicated and encumbered as hell, to the point that even the simplest things that have been working for decades either don't work anymore, or require confusing user interaction/confirmation, or are unnecessarily more complicated than before.
Apparently it is hard to understand for you, but there are scenarios where only trusted software runs on the computer and the end user expects stuff to just work.
There's no reason that Wayland alone needs to provide the operating system with all of the same capabilities that X11 does just because X11 decided that all these things should be part of the display server protocol.
If you design an operating system from scratch and there are no existing applications and no existing window managers and no existing desktop environments. But that's not the case here. Lots of software has been built up over the decades, and we want to bring that software into the Wayland age with minimal changes in the logic of how it operates. (It's already bad enough that Wayland doesn't provide binary or source code compatibility, so we do need to make some changes in the applications, window managers, and desktop environments - but at least those changes should be as easy as replacing an X11 call with the corresponding Wayland replacement most of the time - this is what this project is all about.)
Who are you speaking for? If these desktop environment developers didn't ask for it in the first place then why are they implementing it
Because large Linux distributions have been threatening to remove Xorg for quite some while now. First, they don't make it the default anymore. Then, they don't ship it by default anymore. One day, you won't be able to get it from the official repos anymore and there will be no more support from them. Also, applications will come out that won't run on Xorg anymore. So in the future, it will be increasingly hard to avoid Wayland. Hence we need a way to bring the existing software (and its working principles) over to Wayland. If you don't like that, well, don't use it. But there is clearly a need for it.
Bruh, if you've been using Xorg for 23 years and didn't have any issues with then you're stoned.
If you use anything for a quarter century then you know your way around its weak points. But certainly you won't settle for something else that takes away (what you consider) essential functionality from it.
Again, it doesn't. If an applications doesn't support Wayland and it runs fine in an X11 session, then it didn't break.
That's your definition. Mine is different: It's not that applications should have to support Wayland, it's that Wayland should support all the existing software base out there (ideally without recompilation, more realistically with recompilation but no code changes, even more realistically with minor code changes but without logic changes -- but not by assuming that everyone is happy to change the way everything works just because the display server guys thought they want to rearchitect how everything is done). This is one thing that Windows gets very, very well (despite all the valid criticism). There is a reason why it still dominates the desktop.
The point of whom? And who are they to dictate that all systems must work their way? Some people want to let applications do everything without nagging the user. It's open source, so if it isn't there yet, we make it.
Most people don't want applications to do things without their permission. You're in the minority there.
Also it's not nagging, they're just permissions. It's not like you aren't familiar with using permissions. When you set read/write/execute permissions on a file or directory, does it "nag" you every time if you want to read, write, or execute? No, it just follows the permissions.
In the case of the screen sharing, when an application like Discord or OBS implements screen/window capturing then it's going to provide a prompt that asks you which window or screen you want to capture. They do this on X11, Windows, or macOS because it won't know which screen or window you want to share until you tell it. All that the screen sharing xdg-portal does is trigger a system-provided prompt that does exactly what the application would have asked with it's own provided prompt. The only difference is that the application can't capture anything without the asking the user first. Windows has an API that does the exact same thing.
The other alternative, safe way to do it is the macOS way which works like permissions on Flatpaks. After you enable the screen sharing permission for the app, the permission stays until you disable it. This means the application needs to provide it's own prompt but and it has the added step of asking you for screen sharing permissions the first time it tries to capture the screen.
Just try it out. Install Ubuntu or Fedora or something in a VM. Pick the Xorg session and launch OBS. Add a screen source with XSHM and with Pipewire and see how much more "naggy" one is than the other. You can even close OBS and open it again it won't ask you to pick the source again.
Then let's make that, because that's exactly what we want here. We have not asked anyone to make Wayland complicated and encumbered as hell, to the point that even the simplest things that have been working for decades either don't work anymore, or require confusing user interaction/confirmation, or are unnecessarily more complicated than before.
It's not a "confusing user interaction/confirmation" unless you're a complete idiot. Like I just described, the screen capture portal doesn't add any additional prompts that screen capture software wouldn't already provide itself.
Portals also have a similarity with server-side decorations in that they provide a way to have an additional amount of a unified look between applications. If you have a Qt-based desktop then applications that use the file picker portal will use a Qt file picker instead of the file picker for the application's toolkit. There's no additional steps added to the process.
Apparently it is hard to understand for you, but there are scenarios where only trusted software runs on the computer and the end user expects stuff to just work.
First off, that's the exception and not the rule. If these things are ever going to be used by the average person then you can't build everything around the assumption that it's only going to be used by the 100 people worldwide who won't install closed source software and apparently comb through the code of every FOSS software they use to see if they're safe.
Also the expectation is never that someone knowingly put untrusted software on their computer. The assumption that it somehow got there and is doing something without your knowledge. It could even be unsafe software disguising itself as known safe FOSS software.
If you design an operating system from scratch and there are no existing applications and no existing window managers and no existing desktop environments. But that's not the case here. Lots of software has been built up over the decades, and we want to bring that software into the Wayland age with minimal changes in the logic of how it operates. (It's already bad enough that Wayland doesn't provide binary or source code compatibility, so we do need to make some changes in the applications, window managers, and desktop environments - but at least those changes should be as easy as replacing an X11 call with the corresponding Wayland replacement most of the time - this is what this project is all about.)
It was never ever going to be possible to make something that improves on all the faults of a 36 year old protocol while providing binary backwards compatibility. X11 didn't even provide binary backwards compatibility with X10 and there was only like a year between both releases.
Hell if we want to make it really easy to port Windows software to Linux and binary backwards compatible is desirable then why make Linux or Unix software? Lets just put all our efforts behind Wine and run Windows software.
You've been told this before: your expectation that a new protocol was going to come along and old software would just use it without any changes is a compete pipe dream. It doesn't happen and has never happened.
Because large Linux distributions have been threatening to remove Xorg for quite some while now. First, they don't make it the default anymore. Then, they don't ship it by default anymore. One day, you won't be able to get it from the official repos anymore and there will be no more support from them. Also, applications will come out that won't run on Xorg anymore. So in the future, it will be increasingly hard to avoid Wayland. Hence we need a way to bring the existing software (and its working principles) over to Wayland. If you don't like that, well, don't use it. But there is clearly a need for it.
Well they're not threatening. That's the plan based on the state of Wayland and XWayland. Why do you think X11 software will go away if there's something preventing them from being ported to Wayland? And why would you think Wayland devs are trying to prevent certain software from being ported to Wayland? That makes no sense.
If you use anything for a quarter century then you know your way around its weak points. But certainly you won't settle for something else that takes away (what you consider) essential functionality from it.
Your issue isn't necessarily that you're missing essential functionality under Wayland, it's that you don't like how that functionality is implemented. Making a shell on top of a compositor is dumb to you but faking a shell out of a few clients that can do anything seems like a good idea. Makes no sense.
That's your definition. Mine is different: It's not that applications should have to support Wayland, it's that Wayland should support all the existing software base out there (ideally without recompilation, more realistically with recompilation but no code changes, even more realistically with minor code changes but without logic changes -- but not by assuming that everyone is happy to change the way everything works just because the display server guys thought they want to rearchitect how everything is done).
That's incredibly dumb. You know there's no graphic editing software on Linux that competes with Photoshop and people have been asking Adobe for years to support Linux. Now I know that we all been looking at it backwards. Apparently Linux just doesn't support Photoshop. I guess all of us are the dumbasses and you're the genius. I guess if you were a graphic designer as well as a programmer then Photoshop would be running on Linux/Unix whether Adobe wanted it to or not.
This is one thing that Windows gets very, very well (despite all the valid criticism). There is a reason why it still dominates the desktop.
It could literally be doing all the same stuff that the Wayland, XWayland, and Portals devs are doing but you wouldn't know because you're unfamiliar with how Windows works anyway.
What exactly is the goal of this repo. I don't believe the end game for protocols added here should be for this repo to become a hard alternative to wayland-protocols and wlr-protocols. I believe protocols should be handled as something that would eventually try for inclusion in upstream wayland protocols. I realize this will be contrary to a lot of hopes for some people, but the goal shouldn't be to reimplement x11 but rather improve upon it that still aligns with the core wayland philosophy of security and modularity, without compromising the flexibility x11 offers.
I think disregarding security is a losing battle. I don't think a lot of compositors will implement the protocols in question if they have no regard to security, However I believe that the idea that we need to disregard security to get the flexibility of x11 is fundamentally flawed. Keeping security in mind, but with a feature first mentality is what will help this project succeed.