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

[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.

[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.

[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]

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.

[oiaohm]

Except you can't query absolute positions on Crapland, or do a plethora of other things (Always On Top apparently is missing as well). Doesn't matter how you rewrite your script.

I never said you should use the same scripts, but if something is not possible, then it can't be done.

This is the thing.

https://wayland.freedesktop.org/extras.html

I am really not sure you have really tried. Remember XTEST Extension Protocol was designed for X11 protocol diagnostics. Wayland protocol diagnostics are done with man in middle proxy.

To me you have given up automating programs with Wayland as soon as you find things like absolute positions is missing.

Weasel answer truthfully now can you using absolute position 100 percent promise that that automated button press or text entry in fact goes in the right place on the application with X11 or Windows?

Now the answer is no you cannot if you are being truthful.
1) The user could move the window before application processes the input,
2) The window could close on you resulting in the input going to the wrong program completely
3) so on with all these been different forms of race condition failures resulting in your automation scripts causing things as a user you did not want to happen to happen.

Lets say you use wldbg with wayland to inject input event of course with the applicaiton had to be started with wldbg so it man in middle. The race conditions don't exist because the input was sent to a window itself with relative position. The only way this goes wrong is if the window is resized guess what man in middle proxy can delay the resize event being delivered to the application until after it processed the script input.

Yes different design solution need to script of Wayland applications if it done there is no race conditions.

Wayland design does not allow particular things directly but that does not mean there is not means to either achieve exactly the same result or close to the same result it does not matter with less defects than having those other options would give.

[oleid]

Except you can't query absolute positions

But you can, but currently this is compositor specific.

Crapland,

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

or do a plethora of other things

I'd suggest writing bug reports for protocol extensions.

(Always On Top apparently is missing as well).

I guess this can't be supported in every compositor. Most certainly tiling ones won't

I never said you should use the same scripts, but if something is not possible, then it can't be done.

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).

[Weasel]

Everything will be fine!

Except you can't query absolute positions on Crapland, or do a plethora of other things (Always On Top apparently is missing as well). Doesn't matter how you rewrite your script.

I never said you should use the same scripts, but if something is not possible, then it can't be done.

[oleid]

Such as your own fucking scripts that automate your workflows and Crapland prevents it. .

8343c0.jpg

Everything will be fine!

[Weasel]

Apps draw content on the surface that they're given.

Apps are not some toddlers that need guidance from the parent Crapland. They're literally everything, even the compositor is an "app".

Window manager deals with window management. That way all apps behave the same and share the same feature sets. If the apps are broken, then it's better to fix them. That's what Wayland is doing.

Ever wondered not all apps should behave the same? Some should have higher privileges than others. Such as your own fucking scripts that automate your workflows and Crapland prevents it. Because they want power users to keep working like a mobile slave peasant.

Window manager exists to serve the apps, not the other way around.

[curfew]

How about no? If you don't like your apps then don't fucking use them. I like the things my apps do, including my own scripts.

Hard pass on WM remembering Windows positions. I already hate it that PA mixer remembers the volume I set for a given app, when I just want to lower one stream but then it ends up lowering all further fucking streams from that app (browser) by default. Jesus christ.

Apps draw content on the surface that they're given. Window manager deals with window management. That way all apps behave the same and share the same feature sets. If the apps are broken, then it's better to fix them. That's what Wayland is doing.