Hacker News Reader

Comment by _d7dt | Hacker News Reader

Inclusion in wayland-protocols means that it had enough support without opposition. It doesn't mean that all the members are interested in implementing the feature. According to the members list, Weston and Mir are still important enough to have a vote: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/b...

>application have to explicitly ask for compositor to decorate the window.

My reading of the protocol is that even when the application asks for that, the compositor can still reject it, and the application must always provide a fallback to CSD.

View on HN

>My reading of the protocol is that even when the application asks for that, the compositor can still reject it, and the application must always provide a fallback to CSD.

Yes this is correct too. I assume it was mainly put there for GNOME :) I honestly don't fathom why you would want to be CSD only in general purpose compositor aimed for desktop users. It can make sense in specialized cases. But then again I believe GNOME doesn't want normal users, but rather users that will always do what they want them to do, aka the Apple mentality.

This is all made worse with the low-level libraries and programs that don't use the gnome toolkit, end up just drawing some very primitive title bar (sometimes even without any buttons), just so people can drag the window around under gnome compositor. I guess this is the kind of end user experience gnome devs want? Nah, they'll just tell users to use only their apps instead next.

>I believe GNOME doesn't want normal users, but rather users that will always do what they want them to do, aka the Apple mentality.

I would not say this is true, GNOME just handles extensibility differently. If you want to help with this, please consider working on this issue: https://gitlab.gnome.org/GNOME/mutter/-/issues/1053

That would pave the way for GNOME shell extensions to implement window decorations (and other wayland extensions) in a way that doesn't burden upstream maintainers and make them have to support every custom wayland protocol that is only used by a handful of apps.

>I guess this is the kind of end user experience gnome devs want?

I can't speak for them but I think they would suggest that those low level libraries all collaborate on a shared library to implement nice looking CSD, that way there is no code duplication and no dependence on GNOME libraries. Another option would be for them to copy the approach used by firefox, and use dlopen to access gtk functions and draw the CSD that way when it's detected they're running in a GNOME environment. Such functionality could be put in a library and wrapped up in 1-2 function calls, to make it easy to use. SSD might be the approach used by other desktops, but it is not the only way to achieve this functionality, and it may not even be the simplest.

What actually will happen is that those developers either will ignore gnome, force the application to run under xwayland if it detects mutter, or implement a really primitive decoration that will make users open bug reports "why is the decoration so weird?". They'll be taking similar stance as gnome devs and start telling users "it's not our bug", "report it to gnome devs".

https://github.com/mpv-player/mpv/issues/3646

>SSD might be the approach used by other desktops, but it is not the only way to achieve this functionality, and it may not even be the simplest.

Surely zero code in client is the "simplest". It also makes sure the decoration always works and behaves the same way in every application. It also won't stop working if the application freezes. Sure with a magical library that you managed to force on everyone at least the consistency and "not buggy" could be solved. But why is this necessary when others don't need it?

And I surely don't want to see, libkde-decoration.so, libgnome-decoration.so, libwhatever-decoration.so

Here is also very good technical writeup on CSDs from author of yet another display server, that's not wayland nor X11

https://arcan-fe.com/2018/01/27/argumenting-client-side-deco...

>They'll be taking similar stance as gnome devs and start telling users "it's not our bug", "report it to gnome devs".

I'm not sure I understand where that happened, the issue you posted is closed, and mpv has since implemented client side decorations.

>Surely zero code in client is the "simplest".

There aren't any zero code solutions, implementing xdg-decoration in the clients is more than zero lines of code. If you violate the spec and ignore the protocol requirement that the client must provide a CSD fallback then it's not a lot of code but again, you could also provide a library that allows clients to draw a prefab CSD around themselves in a very small amount of code.

>it also makes sure the decoration always works and behaves the same way in every application. It also won't stop working if the application freezes. Sure with a magical library that you managed to force on everyone at least the consistency and "not buggy" could be solved. But why is this necessary when others don't need it?

I've seen other ways those can be achieved without SSD. Implementing a good looking and good behaving SSD that works well with every app is not simple either, and it's always going to be necessary to solve that because the core problem of making good decorations is always the same.

>And I surely don't want to see, libkde-decoration.so, libgnome-decoration.so, libwhatever-decoration.so

The idea I suggested is for the library to load the relevant kde and gtk symbols with dlopen, so there would not need to be multiple libraries. This I believe is how SDL already operates under the hood for some things.

>mpv has since implemented client side decorations.

Yes eventually somebody implemented them, and they look like this: https://github.com/mpv-player/mpv/pull/7186

Needless to say, mpv prefers xdg-decoration if compositor supports it.

>There aren't any zero code solutions

It's zero-code for client if the compositor actually handled the border. And yes, compositor is the more likely component to actually have the foundation to do this kind of task.. I mean it is an _compositor_.

>The idea I suggested is for the library to load the relevant kde and gtk symbols with dlopen, so there would not need to be multiple libraries

Yes and hope those libraries actually implement stable ABI. SDL may do this, but it's actually a maintenance nightmare. If you actually go this way, it's better to have wrapper libraries that link to the actual libraries instead and dlopen those wrapper libraries where you can ensure stable ABI. Though I also aren't really fan of shared libraries, but that's entirely different topic.

I assume that screenshot is a joke, the decorations don't look like that for me, they look small and unobtrusive. I actually prefer them to SSD because they take less space, and they are consistent with the way the mpv decorations work in macOS.

>It's zero-code for client if the compositor actually handled the border.

With respect, it's not. The client still must implement the semantics of the xdg-decoration protocol to tell the compositor that it wants a border.

>Yes and hope those libraries actually implement stable ABI.

Major versions of Qt and GTK are stable, i.e. if you target Qt5 and Gtk3, that won't change.

>I assume that screenshot is a joke, the decorations don't look like that for me, they look small and unobtrusive.

I'm not exactly sure how they look like currently, as I don't use gnome (nor wayland), but that was the latest PR regarding CSD I was able to find.

>With respect, it's not. The client still must implement the semantics of the xdg-decoration protocol to tell the compositor that it wants a border.

Sure in wayland's case. But this is only because both systems needs to be supported. But it could be even more simpler with SSD only.

>Major versions of Qt and GTK are stable, i.e. if you target Qt5 and Gtk3, that won't change.

This is if they actually are. With dlopen/dlsym, you effectively get rid of all type-checking making the code more fragile.

SSD only isn't really an option, from what I have seen, eventually app designers want CSD to reduce clutter and to give their apps a better native look. This is true on all platforms, see for example macOS Big Sur.

>This is if they actually are.

They are, you would see terrible breakage with every app if they weren't. Your dynamic linker is effectively using dlopen/dlsym under the hood, it's not doing any type checking.

>SSD only isn't really an option, from what I have seen, eventually app designers want CSD to reduce clutter and to give their apps a better native look. This is true on all platforms, see for example macOS Big Sur.

This isn't about the look of applications. This is about the needs of users and developers. I personally don't have window decorations at all on my main system, I don't need them and they are useless. There's developers that ask GNOME devs to implement a feature so their app can continue to work with GNOME users. There's users that ask GNOME devs to implement a feature so that app can work in GNOME. That's the point I'm trying to drive in here. GNOME devs feel like they can just break existing behaviors and ecosystems if they feel like it and say the problem is not on their end, while other groups have cooperated and worked on a solution that works for everyone. This is also the reason I don't use wayland nor develop anything for it anymore, too many things just don't work there, and the people that actually are trying to make things work or at least work on replacements gets constantly ignored or told to go away, meanwhile a single person has done a display server, that is not just wayland and xorg compatible, it's also much more flexible and more powerful than wayland ever is going to be. https://arcan-fe.com

>Your dynamic linker is effectively using dlopen/dlsym under the hood, it's not doing any type checking.

What I mean by typechecking is that with typical linkage + header scenario you get compile error if API changed (this won't prevent ABI breakage however). With dlopen/dlsym, if you have typo in your function pointer declarations, that can be hard to debug bug. Sure this can be avoided to make sure you generate such pointers from upstream headers and keep them up-to-date. There's also some other unrelated issues that can rise from this, like package maintainers having trouble to figure out what the real dependencies (or even the optional dependencies) of the application actually are, I've been there.

>This is about the needs of users and developers.

I know, I'm saying that app developers and users want CSD in some form eventually. I've seen this trend everywhere. You may not want them on your system and you're entitled to that opinion, but some app developers do want them.

>That's the point I'm trying to drive in here. GNOME devs feel like they can just break existing behaviors and ecosystems if they feel like it

I don't know what you mean, this feature was never supported in GNOME's Wayland session. It never had that existing behavior, the decorations were a private KDE extension that was picked up by mir and wlroots and then much later put into wayland-protocols. It doesn't make sense for KDE to implement a feature and then declare GNOME to be broken because some others copied that feature but GNOME didn't.

>meanwhile a single person has done a display server, that is not just wayland and xorg compatible, it's also much more flexible and more powerful than wayland ever is going to be

I personally like Arcan but according to the developer it's not trying to solve all the same problems as Wayland or X11 even though it may be compatible with some apps. I don't believe GNOME and KDE are going to rewrite their window manager in Lua for example.

>What I mean by typechecking is that with typical linkage + header scenario you get compile error if API changed (this won't prevent ABI breakage however). With dlopen/dlsym, if you have typo in your function pointer declarations, that can be hard to debug bug. Sure this can be avoided to make sure you generate such pointers from upstream headers and keep them up-to-date.

The API and ABIs for those libraries are stable across major versions, they guarantee that. All Linux distros would see major breakage if they didn't, since they don't necessarily recompile the applications along with library upgrades.

>I know, I'm saying that app developers and users want CSD in some form eventually. I've seen this trend everywhere. You may not want them on your system and you're entitled to that opinion, but some app developers do want them.

It feels like we are just going in circles now. Other compositors give the option for both. GNOME only gives the option for CSD, and tells others to "fix their app". You can use SSD or CSD, I don't care, but I also don't want to hear "this app doesn't work on mutter", or "use libgtk to make this app work on our special compositor".

>I personally like Arcan but according to the developer it's not trying to solve all the same problems as Wayland or X11 even though it may be compatible with some apps. I don't believe GNOME and KDE are going to rewrite their window manager in Lua for example.

Yeah I don't believe KDE or GNOME are ever gonna use arcan either personally. It's users most likely will be power users only. Considering it's reaching soon full Xorg compatibility however, it's probably possible to run X11 WM inside it. That said I'd personally would have no problem with the LUA. The whole arcan philosophy is kind of reverse of wayland, taking care of all the heavy lifting, making the actual development straightforward and less boilerplatey, even more so than X11. Heck, it's even a multimedia server for audio and video. Something jack can only dream of and pipewire trying to do.

>Other compositors give the option for both. GNOME only gives the option for CSD, and tells others to "fix their app". You can use SSD or CSD, I don't care, but I also don't want to hear "this app doesn't work on mutter", or "use libgtk to make this app work on our special compositor".

I'm sorry I'm confused. I was responding to your suggestion earlier about making it SSD only, which I think is much less feasible than having it be CSD only. I believe I've said my position regarding the option already: If the problem is the apps don't want to write their own code for drawing window decorations, there are multiple solutions to that aside from SSD, that would require about the same amount of code in clients as SSD would. So to me it's not really an issue of the app working in mutter or not, or needing to link against gtk, or whatever. It can all be handled transparently with the right solution. Maybe eventually someone could create a version of libwayland that handles decorations transparently, with no changes needed to the apps at all.

Reply on news.ycombinator.com