Follow Upstream more closely-A kernel is an additonal dependency

[fbievan]

This means that this repository should make wayland a kernel to run on its own. This means that <stdio.h> should be written from scratch, and reimplment everything needed to run a desktop and run these protocols.

anyway on a non-trolly note. These protocols will be prohibited by these decisions here, and I feel if we want to create a solution to alot of the protocols that are requested it. This repository should try to be as close as possible to solutions found in the main upstream process, so therefore there wouldnt be too much fragmentation between these protocols and upstream protocols.

[probonopd]

Hi @fbievan, thanks for sharing your thoughts.

The thing with upstream is, it's not like the needs addressed in this projects haven't been mentioned there. It's that they have been blocked and discussed to death.

So the basic idea of this project is to do similar work as upstream does, but only in those areas that upstream doesn't (want to) provide satisfactory solutions for.

If we don't want to end up like upstream (endlessly arguing to the point that almost nothing ever gets merged despite many people needing a solution), we need to give ourselves some different guiding principles than upstream, imho.

[myownfriend]

So the basic idea of this project is to do similar work as upstream does, but only in those areas that upstream doesn't (want to) provide satisfactory solutions for.

So what is unsatisfactory about upstream's solutions?

[probonopd]

So what is unsatisfactory about upstream's solutions?

As written above,

The thing with upstream is, it's not like the needs addressed in this projects haven't been mentioned there. It's that they have been blocked and discussed to death.

The most simple and basic features (like letting an application set absolute pixel coordinates for its windows, and letting applications set icons on their windows) are getting discussed to death. Upstream is often discussing whether things should be possible at all, and how they should be done (often in the most encumbered and complicated way possible), rather than just providing a sane, straightforward API for applications to do what they can do in Windows, macOS, and X11.

[probonopd]

So what is unsatisfactory about upstream's solutions?

This seems to summarize the history (I can't vouch for its accuracy but it seems to be plausible at first sight - emphasis added):

Wayland is the future and it's awesome (especially compared to X11), it's just that the devs did a shitty job because they had a shitty/lazy attitude.
Their initial goal was - no we're not replacing all of X11, only the (image-swapping) part we care about, if you want a paste clipboard, menu location control and many other things X11 does - it's not our (Wayland's) job.
And many people (including myself) didn't agree with it because those other parts won't write themselves, not to mention the hardest part - figuring out a standard for each such "non-wayland" (like clipboard) solution that all main parties would agree with. And it's fine for them not to write the code themselves, the part that actually pissed me off is the attitude that "it's not Wayland's business - you the community figure out all the rest, we did the core stuff". It was clear to me things don't work like that, the open source community who actually write the code and contribute - is like >95% paid corporate devs.

Then the Wayland devs started (very slowly) creating said new standards to actually fully replace X11 because like 10 years later they FINALLY realized things don't decided and write themselves and without these bits Wayland is sitting like a dead duck where it "kinda" works but has too many bugs and shortcomings to actually replace X11.

This attitude is/was Wayland's biggest problem. That's why it took 15 years and we're still not there. If you remember there were even attempts by random people to fork it because back then the Wayland devs even refused to negotiate adding said features (because again, "it's not Wayland's job to do this" was the answer back then).

Source: cl333r at Phoronix

[myownfriend]

I can't vouch for its accuracy but it seems to be plausible at first sight

Why can't you vouch for it's accuracy?

[probonopd]

I haven't studied Wayland's history in detail. But as said, the post sounds plausible to me.

[myownfriend]

I haven't studied Wayland's history in detail. But as said, the post sounds plausible to me.

Why not confirm these things before posting that though?

[Maxwell175]

So the basic idea of this project is to do similar work as upstream does, but only in those areas that upstream doesn't (want to) provide satisfactory solutions for.

So what is unsatisfactory about upstream's solutions?

Upstream is bogged down by an overly opinionated crowd of people who have their own vision of how things "should" work and simply ignore/berate when people try to bring up normal use cases that don't fit into their "vision". I personally have been on this bandwagon for years now. I WANT to be able to just give an app full access to my desktop ALWAYS, but no it needs to ASK permission every time (and many things are not even possible). Wayland needs to know how to get out of my way.

My desktop is not a phone. On my phone it makes sense to containerize apps and lock down their permissions and even there I can install Magisk and allow certain apps much greater control to break through the protections when I need to get things done. It is actually disturbing to me that there might come a time on the Linux desktop that all windows are in their own box with no ability to let them touch everything that is needed to get things done. Do we need a Magisk for Wayland that hooks into a running compositor and exposes APIs to let apps be free?

[probonopd]

@Maxwell175 exactly. Check out the proposed protocols in this repository.

[myownfriend]

Upstream is bogged down by an overly opinionated crowd of people who have their own vision of how things "should" work and simply ignore/berate when people try to bring up normal use cases that don't fit into their "vision". I personally have been on this bandwagon for years now. I WANT to be able to just give an app full access to my desktop ALWAYS, but no it needs to ASK permission every time (and many things are not even possible). Wayland needs to know how to get out of my way.

God forbid that users are informed about what there apps are doing.

My desktop is not a phone. On my phone it makes sense to containerize apps and lock down their permissions and even there I can install Magisk and allow certain apps much greater control to break through the protections when I need to get things done. It is actually disturbing to me that there might come a time on the Linux desktop that all windows are in their own box with no ability to let them touch everything that is needed to get things done. Do we need a Magisk for Wayland that hooks into a running compositor and exposes APIs to let apps be free?

Whether it be a desktop or a phone, it's still a computer running apps.

Also don't get disturbed. Linux isn't moving towards a future where applications can't do anything they want, they just won't able to do everything they want without getting permission to do that first. That's very different.

[Maxwell175]

@myownfriend Being informed is cool and all, but there are apps the I KNOW I WANT to give FULL access to. Wayland is in the way here.

Also don't get disturbed. Linux isn't moving towards a future where applications can't do anything they want, they just won't able to do everything they want without getting permission to do that first. That's very different.

The problem is that there is resistance to adding APIs that give applications the tools they need to break out of their box and access the rest of the desktop. There literally isn't an API to let applications query info about other windows. There literally isn't an API that allows applications to position themselves precisely wherever they want.

[myownfriend]

@myownfriend Being informed is cool and all, but there are apps the I KNOW I WANT to give FULL access to. Wayland is in the way here.

Then give access to them. This doesn't seem like a big issue.

The problem is that there is resistance to adding APIs that give applications the tools they need to break out of their box and access the rest of the desktop.

That's literally what Portals are designed to do.

There literally isn't an API to let applications query info about other windows.

I thought there was discussion about a Portal to do that.

There literally isn't an API that allows applications to position themselves precisely wherever they want.

That's correct. At the moment there is proposal for a protocol to effectively do that.

[Maxwell175]

@myownfriend Good job not addressing the specific examples I gave. The problem with portals is that the deeper, more advanced APIs just aren't there. For those that are there, they don't have the necessary flexibility. I have not been able to get unattended remote control working, because the Portals system requires that applications request the screen capture every time.

[probonopd]

Hence we are proposing protocols that don't need Portals (and also don't need any user interaction).

[myownfriend]

@myownfriend Good job not addressing the specific examples I gave. The problem with portals is that the deeper, more advanced APIs just aren't there. For those that are there, they don't have the necessary flexibility.

I did mention your specific examples.

I have not been able to get unattended remote control working, because the Portals system requires that applications request the screen capture every time.

The screen capture portal doesn't actually require that the prompt be brought up every time. This can be demonstrated by creating a screen capture source in OBS using Pipewire, then close the application, and open it back up. It will not re-prompt you.

When you say unattended remote control though, you're talking about a remote desktop, right? I swore I was able to do it last year without a prompt. The issue at the time was a lack of remote login support. I thought that as being implemented at the time though.

Hence we are proposing protocols that don't need Portals (and also don't need any user interaction).

Well no you aren't. You're proposing vague ideas for protocols but nobody has written a single pull request with a real defined protocol yet. This is effectively an empty repo that being used as a Wayland protest forum. In other words it's your gist with sub-threads.

You're also not making a great case for why portals are bad. Everything is coming from the perspective that someone it bad if it's unlike X11.

[probonopd]

Everything is coming from the perspective that someone it bad if it's unlike X11.

The point of this repo is to propose the protocols that can provide a smooth transition path from X11 to Wayland for those who want to get there with minimal changes. If you don't have that goal, then this repository won't satisfy you.

[myownfriend]

The point of this repo is to propose the protocols that can provide a smooth transition path from X11 to Wayland for those who want to get there with minimal changes. If you don't have that goal, then this repository won't satisfy you.

This repository doesn't have the goal you're stating. You're not trying to transition X11 software to Wayland with minimal changes, you're trying to revert Wayland to X11 regardless of how nonsensical that is.

X11 is awful and people have known that for years. It was something they were just forced to use because of a lack of options and people have been trying to find ways around it as much as possible for over decade. It's been on life support for decades with functionality just being poorly patched onto it. There was even an extension called XFixes.

If you don't have that goal, then this repository won't satisfy you.

I don't have that goal. That should be obvious. I'm for things improving over time and against people dragging back progress.

I full expect this repo to go absolutely no where.

[probonopd]

This repository doesn't have the goal you're stating.

Why are you having this impression? If you look at the proposed protocols, you will actually find things like

wayland-x11-compat-protocols/unstable/window-management-v1.xml

Lines 14 to 21 in 8d6248a

	<request name="set_position">
	<description summary="set the position of a window">
	Set the position of a window. The position is identified by the 'x' and 'y' arguments. Conceptually, this is similar to X11's XMoveWindow().
	</description>
	<arg name="window" type="object" interface="xdg_toplevel"/>
	<arg name="x" type="int"/>
	<arg name="y" type="int"/>
	</request>

where it explicitly states Conceptually, this is similar to X11's XMoveWindow().

That is a prime example of how to "provide a smooth transition path from X11 to Wayland for those who want to get there with minimal changes" for me.