3 ms·

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

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

by zxzax 5y ago

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.

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