Wayland 1.19 Released With Small Protocol Updates, Fixes

[CochainComplex]

rack of helles and celebrate.

this!

[ciupenhauer]

No, no, no, that's impossible. Wayland is bug-free and the best thing since sliced bread, so stuttering is impossible. I mean... right, Wayland fans?

Joking aside, while I can't remember any stuttering, I also feel like Wayland isn't exactly smooth yet.

Which wayland isn't exactly smooth yet? The Pink one or the yellow one?
Wayland is just an idea, like the Avengers. You mean Gnome Wayland isn't exactly smooth maybe? Because that's 100% gnome's fault, and a well known issue that's still being worked on, has nothing to do with wayland but Shell's frame scheduler

[f0rmat]

this!

I now have had four from the rack...I love German beer! Especially when my corporate responsibilities on business trips end.

For those of you who do not know, a rack is 20 half liter bottles (around 18 ounces for you all all imperial units). In Germany, I can get some high quality racks for less than 20 euros - in other words, 10 liters (or about 2.25 gallons) for less than $22 USD. The vast amjority of the time, less than 20 USD. In Germany, soft drinks and bottled wasser (water) cost more than bier - a great place to live.

If you are in the Bundesrepublick Deutschland, PM me with a place wherever you want and I will meet you (corporate world willing) and I will buy you a bier (or zwei or drei - depending on how far I am from the hotel) if I happen to be anywhere near that that place. Consider it a German redneck to an American redneck - you Rhineland-Pfaltz redneck.

[JackLilhammers]

So, it works for you (and your use case).

But it does not mean it will work for other people.

Are you serious? I was being sarcastic, but I meant the exact same thing

[jacob]

Nope, it has never been, and it's not suitable for all the small projects which do not want to bring Gnome dependencies.

IOW you've proven me right, thanks.

So all these small projects need to implement what they want the way the want. I don't understand your point: whaaaawhaaa implementing something is too hard and takes too much work; GNOME provides a working implementation but whaawhaawhaaa I don't want to use it; whaaawahhhaaa now that I'm not using it I can't use its features.

So once again: how exactly should "wayland" provide support for screencasting that would magically work for any compositor, given (among other things) that "wayland" consists of precisely ZERO lines of code? And assuming it was possible, what exactly do the upstream devs owe to Joe Hobbyist to do the hard work in his place?

[jacob]

After all these years I still have no reason to switch to wayland. Xorg works fine for me and has all features that I need. Using wayland compositors in current state is a regression for me. Even Gnome doesn't support server-side decorations, so you can't easily move or minimize some windows. Also some reasonable window managers/DEs like Openbox or XFCE don't have wayland support.

And don't tell me that wayland is just a protocol and all DEs, libraries like SDL2, applications have to reinvent the wheel and write a lot of code to support some basic features. Why i.e. it's not possible to create official "libdecoration" library, so that all application could easily use it instead of creating their own "ugly but functional" decorations? Why as an application developer should I care about stupid decorations at all?

Technically there is nothing preventing the creation of an official libdecoration library. In practice it's next to impossible and this discussion is a good example of why: there is still a pervasive ideology that resists the idea of having anything official. If an upstream project pushes such a lib, some will immediately start whinging that they don't want to use it because reasons, others because they don't want to pull in dependencies (because reasons) and others still because they immediately wrote their own barely functional alternative and they DEMAND that upstream goes out of its way to support it and that people actually use it.

[deve]

Funny you should mention that. Looks like it is possible to do just that[1].

[1] https://gitlab.gnome.org/jadahl/libdecoration

I think it's good idea and assuming it doesn't have no too many hard linked dependencies I would probably use it for my projects. But last time that I checked, there were just simple borders around the window.

Technically there is nothing preventing the creation of an official libdecoration library. In practice it's next to impossible and this discussion is a good example of why: there is still a pervasive ideology that resists the idea of having anything official. If an upstream project pushes such a lib, some will immediately start whinging that they don't want to use it because reasons, others because they don't want to pull in dependencies (because reasons) and others still because they immediately wrote their own barely functional alternative and they DEMAND that upstream goes out of its way to support it and that people actually use it.

If someone wants to draw their own decorations and thinks that he can do it better, then it's always possible to create a window without decorations. If someone doesn't like how official decorations look, then he can change the skin in options. Simple, can be just single line in code and users have unified look in ther systems.

Of course it's possible to create a window using GUI toolkits, but tell SDL2 people that they should create a window using GTK...

[jacob]

I think it's good idea and assuming it doesn't have no too many hard linked dependencies I would probably use it for my projects. But last time that I checked, there were just simple borders around the window.



If someone wants to draw their own decorations and thinks that he can do it better, then it's always possible to create a window without decorations. If someone doesn't like how official decorations look, then he can change the skin in options. Simple, can be just single line in code and users have unified look in ther systems.

Of course it's possible to create a window using GUI toolkits, but tell SDL2 people that they should create a window using GTK...

SDL2-based apps shouldn't have to use GTK. It is true that as of today a SDL2 app running under Wayland will have no window decorations. But that is a problem with SDL2's Wayland support. CSD is a fundamental concept in the Wayland world and a framework that claims to be Wayland-compatible must implement them. There is some work in progress on that front: https://bugzilla.libsdl.org/show_bug.cgi?id=5194. Once it's done and merged in, SDL2-based software will work as it should without requiring to use GTK or to write any extra application code to support decorations.

[oiaohm]

SDL2-based apps shouldn't have to use GTK. It is true that as of today a SDL2 app running under Wayland will have no window decorations. But that is a problem with SDL2's Wayland support. CSD is a fundamental concept in the Wayland world and a framework that claims to be Wayland-compatible must implement them. There is some work in progress on that front: https://bugzilla.libsdl.org/show_bug.cgi?id=5194. Once it's done and merged in, SDL2-based software will work as it should without requiring to use GTK or to write any extra application code to support decorations.

There is something missed here. Take gamescope from valve it demos compositor stacking that by design Wayland supports. So Server side decorations for items like SDL2 applications on Wayland could be implemented as a compositor that you run before the application to put on the decorations.

Remember if you are supporting KDE with wayland server side decorations the functionality to support this should be there as well.

There is more than 1 way to skin this problem. Most likely its writing a proxy wayland compositor perform server side decorations as KDE defined on applications missing decorations.

Host wayland compositor-> proxy wayland compositor->application is a valid Wayland stack. Proxy can be like gamescope fibing to application what screen resultion is and doing scaling or it could be putting on window decorations and telling applications I am doing server side decorations. Yes multi proxy wayland compositors is supported by wayland protocol design.

[jacob]

There is something missed here. Take gamescope from valve it demos compositor stacking that by design Wayland supports. So Server side decorations for items like SDL2 applications on Wayland could be implemented as a compositor that you run before the application to put on the decorations.

Remember if you are supporting KDE with wayland server side decorations the functionality to support this should be there as well.

There is more than 1 way to skin this problem. Most likely its writing a proxy wayland compositor perform server side decorations as KDE defined on applications missing decorations.

Host wayland compositor-> proxy wayland compositor->application is a valid Wayland stack. Proxy can be like gamescope fibing to application what screen resultion is and doing scaling or it could be putting on window decorations and telling applications I am doing server side decorations. Yes multi proxy wayland compositors is supported by wayland protocol design.

Yes, I guess that is a possible approach too. I'm not sufficiently familiar with the details to be able to tell how it compares in terms of overhead and performance. I didn't mean to say that having CSD support and management hardcoded into SDL2 is the only solution, my point was simply that the substandard behaviour of SDL2 apps is not something to blame on wayland, it's because SDL2's wayland support is incomplete (one way or another).