A Session Suspension & Restoration Protocol Proposed For Wayland

[starshipeleven]

Works on Gnome. https://help.gnome.org/users/gnome-h...record.html.en

That's ... not a standard way to do it.

[srakitnican]

No sure what you mean... GNOME is a standard desktop, everything else doesn't follow a standard

I would like to know how one can stream from the standard desktop. OBS is out of the question, obviously, since it is not following standards

[Weasel]

Sorry man I was late.

but Wayland is just a protocol!

You know what is a "protocol extension" right?

It's an optional addition to the protocol. But is a standard. It's not a KDE-specific thing.

I think you're misunderstanding people who want MORE FEATURES in the protocol (or features as "protocol extensions"). We don't want KDE-specific thing, or GNOME-specific thing, aka "leave it to the compositor" bullshit which leads to fragmentation.

The protocol itself, whether extensions or not, must have these features, so that a compositor that wants to implement these features does so based on the protocol, NOT ITS OWN WAY, which is why Wayland sucks right now -- the protocol lacks too many "extensions" and delegates them to the compositor. i.e. they do it based on the Wayland "standard".

Obviously a compositor is free to not implement all Wayland features, but then it's not "fully Wayland compliant". Even worse, it can make its own screen capturing or whatever other needed feature its own way, even with Wayland, but then it would be flagged as a bad compositor/DE by the community. So having it in the core protocol ensures all of them implement the feature via the same mechanisms to Wayland-aware apps.

An analogy: It's like in real life, you have protocols for stuff and how to behave, but let's say you leave it to the "community" for things you weren't interested in at the beginning on what language to use. Then you have people use spanish, french, chinese, and god knows what else. Just fucking put english in the protocol already, stop delegating it to others.

[jrch2k8]

What happened with the people whose only reply is "but Wayland is just a protocol" when you ask why it lacks features like this? Funny.

How about adding more useful features to the damn protocol instead of letting the compositor having free reign on them, which sucks incredibly.

So much wrong here, ok lets try:

1.) It is just a protocol, please before running your mouth go and try to figure out what actually is a protocol otherwise is not possible to establish efficient communication

2.) Protocols are extensible by definition as long as such extensibility is not redundantly circular but the fact is that it is just a protocol doesn't equal it lacks anything if the target(hardware/software/application/etc.) can accomplish it without such protocol, in this case nothing stops current compositors to handle this scenario with the current protocol but the main problem is that Linux unlike MacOS/Windows have 3 bazillion different desktops hence if someone doesn't step up and propose some standardization(aka extend the existing Wayland protocol) you will end with 3 bazillion different ways of handling the same scenario, that's it.

3.) By definition the compositor is the enforcer and provider of the protocol hence is not possible to apply a protocol without it because the protocol itself is not executable(this should be obvious after 30sec googling "what is a communication protocol"), you are asking to get 4G LTE internet but removing those pesky cell phone towers because you hate having to much carrier possibilities which make your first requirement impossible since those towers implement such protocol.

4.) they are proposing an extension to the protocol to handle this cases, genius, the article clearly state "A Session Suspension & Restoration Protocol Proposed For Wayland" not for KWIN or Mutter or I3 isn't it?

5.) Why they didn't before? lol, blah blah, other hipster gibberish? because no one got that far into implementing such cases yet and while is very easy to whine about it is a very long road between realizing you will need some extension to handle A and actually reach a technical point where you have all the technical micro know how to have a protocol extension actually written and implemented properly, I mean is easy to say "a plane need wings, duh is easy" and actually have all the engineering done to make a passenger plane.

[schmidtbag]

No sure what you mean... GNOME is a standard desktop, everything else doesn't follow a standard

No, LXDE is a standard desktop. Y'know why? Because I said so.
/s

As much as I like standards, the fact of the matter is, everyone who makes something without deliberate exclusivity is hoping their product/service will be the standard, or at the very least, the most widely adopted.

https://xkcd.com/927/

In other words, calling GNOME a standard is moot.

[Weasel]

1.) It is just a protocol

You guys who keep saying "it's just a protocol".

I don't think that word means what you think it means.

3.) By definition the compositor is the enforcer and provider of the protocol hence is not possible to apply a protocol without it because the protocol itself is not executable(this should be obvious after 30sec googling "what is a communication protocol"), you are asking to get 4G LTE internet but removing those pesky cell phone towers because you hate having to much carrier possibilities which make your first requirement impossible since those towers implement such protocol.

When the fuck did I say anything about an implementation or executable?

All I want is those features to be part of the SPECIFICATION or the protocol. So that any Wayland Compositor will have to implement that and ONLY THAT way to do it, like screen capturing, instead of having to figure it out on its own.

I don't give a shit about any compositor, actually. On the other hand, you do, since you want to leave it to them to implement the features. An implementation is NOT A STANDARD or specification. A specification is distinct. If GNOME implements features that Wayland lacks as part of its protocol, it cannot be a standard, because GNOME is not a specification, it's an implementation. So in fact I want the complete opposite of what you said.

Yes they're proposing an extension, which is exactly why your shitty "it's just a protocol" argument makes no sense. These features ought to be integrated in the protocol, full stop, not left to an implementation.

tl;dr: These extensions and many others should have been part of the CORE PROTOCOL from the BEGINNING. And yet, your argument is "it's just a protocol" to this? You guys fucking parrot words you have no clue of.

[jrch2k8]

You guys who keep saying "it's just a protocol".

I don't think that word means what you think it means.

When the fuck did I say anything about an implementation or executable?

All I want is those features to be part of the SPECIFICATION or the protocol. So that any Wayland Compositor will have to implement that and ONLY THAT way to do it, like screen capturing, instead of having to figure it out on its own.

I don't give a shit about any compositor, actually. On the other hand, you do, since you want to leave it to them to implement the features. An implementation is NOT A STANDARD or specification. A specification is distinct. If GNOME implements features that Wayland lacks as part of its protocol, it cannot be a standard, because GNOME is not a specification, it's an implementation. So in fact I want the complete opposite of what you said.

Yes they're proposing an extension, which is exactly why your shitty "it's just a protocol" argument makes no sense. These features ought to be integrated in the protocol, full stop, not left to an implementation.

tl;dr: These extensions and many others should have been part of the CORE PROTOCOL from the BEGINNING. And yet, your argument is "it's just a protocol" to this? You guys fucking parrot words you have no clue of.

Extensions are part of any protocol by nature and seriously do you even bother reading the posts. here goes again

4.) they are proposing an extension to the protocol to handle this cases, genius, the article clearly state "A Session Suspension & Restoration Protocol Proposed For Wayland" not for KWIN or Mutter or I3 isn't it?

please, explain you logic because unless you completely bypassed "Reading" the post and went anal to post a counter I don't see how I'm supporting per compositor implementations here

And again every protocol and specification are extendable by nature because

1.) is not possible to introduce every possible feature with 100% accuracy at the beginning of the specification.

2.) there is no guarantee that the underlying platform that runs said protocol will remain static in time forever

3.) again, "5.) Why they didn't before? lol, blah blah, other hipster gibberish? because no one got that far into implementing such cases yet and while is very easy to whine about it is a very long road between realizing you will need some extension to handle A and actually reach a technical point where you have all the technical micro know how to have a protocol extension actually written and implemented properly, I mean is easy to say "a plane need wings, duh is easy" and actually have all the engineering done to make a passenger plane."

[Zan Lynx]

This seems pretty silly to me. Instead of this, just write the applications to restart their compositor connection and reset their state. If they were meant to terminate, send them a termination signal instead of closing the compositor handle and expecting them to just exit.

There's zero reason for this to be part of the compositor session.

[Weasel]

@jrch2k8: Facepalm.

I'm not against them adding this, on the contrary, I think features ("extensions") like this should have been there from day 1 of the Wayland protocol.

Do you know why those features had to be there from day 1? Because X11 has them. You want to make a superior protocol (otherwise why bother), then at least look at what's successful about X11, and ditch what's unused or crappy.

Features like screen capture and apps able to scan other apps are essential. Sure maybe they need to be given "permissions" for "pseudo security reasons", but so what? Add it to the FUCKING PROTOCOL with permissions and all so that ALL apps can interface with ANY wayland compositor in the same, standard, wayland-compliant manner.

I don't care if a compositor implements it or not. As long as it's part of the protocol (specification), it's all good. Screen capture isn't about the fucking compositor but about the application that wants to capture contents of another application and it must have a way to do so -- a standard way, not compositor-specific or toolkit-specific. That's fucking retarded.

It's all about how the app can interface with the wayland compositor -- note, it's ALL about the INTERFACE, not the IMPLEMENTATION.

[jrch2k8]

This seems pretty silly to me. Instead of this, just write the applications to restart their compositor connection and reset their state. If they were meant to terminate, send them a termination signal instead of closing the compositor handle and expecting them to just exit.

There's zero reason for this to be part of the compositor session.

I agree but I'm guessing(I haven't actually checked the code yet to have a better understanding) this could be more related to suspension and other session functionality other than simply kill the session, kinda like OS X does where Quartz can handle several session but only actually render the active one while the others only reside offscreen until you switch but yeah if it is only for closing it makes no sense