3 ms·

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

by zxzax 5y ago

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.

Cloudef 5y ago
>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 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.
- zxzax 5y ago
  >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.
  - Cloudef 5y ago
    >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.

by zxzax 5y ago

Cloudef 5y ago

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

zxzax 5y ago
>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.
- Cloudef 5y ago
  >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.