GNOME Merge Requests Opened That Would Drop X.Org Session Support

[Weasel]

But you can, but currently this is compositor specific.

But that's not Wayland? Of course a compositor can do whatever it wants "out of spec". It's not part of Wayland protocol and thus Wayland sucks and is a crippled garbage.

Repeating this over and over is quite childish, don't you think?

It's a fitting name since it's crap by design.

I'd suggest writing bug reports for protocol extensions.

I'm sorry but what part of "by design" you don't get? There's several already written by many people, even a recent one (last 2-3 weeks), with very good reasonings and examples of scientific apps that can't be ported because of it.

They won't be accepted anytime soon, if ever. It's a problem by design and the stubborn idiots who designed it. Not a lack of man power. I would never trashtalk a project for lacking manpower. I do trashtalk it if it's doing it and blocking it by design.

Luckily, this is not a proprietary system. If people have an interest in those features, they can implement them (or pay someone to do so).

Until it gets rejected because it doesn't fit their design.

Sure someone can add support to their compositor. But that's not Wayland, it's a "proprietary" extension.

That's like saying you're using a file format but add something on top that it lacks. And the guy who designed the file format refuses to even consider adding it. At this point you aren't using the file format as it is designed by specification, you're using an extension of it. And you're doing that because the file format sucks, by design.

[oleid]

But that's not Wayland? Of course a compositor can do whatever it wants "out of spec". It's not part of Wayland protocol and thus Wayland sucks and is a crippled garbage.It's a fitting name since it's crap by design.

By that logic X also sucks and is crippled garbage. Because not every extension you use in your scripts was available up to a certain point in the past.

examples of scientific apps that can't be ported because of it.

You have a link?

[Weasel]

By that logic X also sucks and is crippled garbage. Because not every extension you use in your scripts was available up to a certain point in the past.

Maybe it sucked in the past, but it was never by design, it was just lacking such features. They weren't intentionally blocked by upstream design devs. Sucking by design is the issue, not sucking by lack of manpower.

You have a link?

I was thinking of: https://gitlab.freedesktop.org/wayla...e_requests/247

There's many others, apparently.

[oiaohm]

Maybe it sucked in the past, but it was never by design, it was just lacking such features. They weren't intentionally blocked by upstream design devs. Sucking by design is the issue, not sucking by lack of manpower.

I was thinking of: https://gitlab.freedesktop.org/wayla...e_requests/247

There's many others, apparently.

The 3 active.related to mandatory positioning.

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/249

There are many dead Weasel with one thing in common. The example application in the dead attempt to absolute position works with in Wayland relative position once the toolkit application used was updated to Wayland. Yes all the operations the application was doing was relative position having to be emulated on absolute position. Yes last 3 years we have finally seen some feature request that may need absolute positions with examples where the feature maybe in fact need.

Yes 249 also says 95% of applications should be able todo just fine with relative positions. This aligns with what the first wayland port attempts of wine find where a 0.0 set to the primary window corner was enough to make most applications work perfectly fine.

Weasel this is the thing before Wayland no one developing output systems really questioned if global absolute position is in fact required.

It is also like how people automating software never questioned how they could fix the race conditions of doing that. Wayland compositor proxy is not a new idea. History of xnest under X11 also had it create as also being for automated testing and automation.

Wayland is a good chance to question many assumes if they are correct. So far for majority of applications the assume that absolute position is required is absolutely false. Heck the idea of single virtual image absolute position may be totally false. There is a second absolute position option being per output absolute position.

Of course there is another problem here. Linux world we have tiling windows managers these absolutely hate any absolute window positioning. Yes Windows and Mac OS don't have these. Yes the tiling windows managers like i3/sway do make the Linux/Posix space a little unique. Yes most of the dead proposals for absolute position can you guess who used their NAK because the contained example was invalid over the years.

Weasel you know the always on top feature how does that apply in a tiling windows manager where you have no top. This is where you start running into problem.

Weasel something else not considered I did provide you with a link to wayland debugging where its wayland proxy compositors. Wayland is in fact designed to be used like vulkan with layers to provide features. Wayland cases it designed that compact wayland proxy compositors can in fact add features without having to implement everything a compositor does.