5 ms·

> How is any "majority" relevant here? Because if the majority of users use a CSD-only DE and the majority of users don't care about keeping the depencies low,

by jhasse 9y ago

> How is any "majority" relevant here? Because if the majority of users use a CSD-only DE and the majority of users don't care about keeping the depencies low, a Allegro version using Gtk+ to get decorations will "win". > It's the CSD-stubborness of some projects that make everyone's life worse I already gave you an example of someone who's life is easier with CSDs: compositor / WM devs. So "everyone" is technically false.

seba_dos1 9y ago
Sure, we can make others do compositor's job, so compositor doesn't have to, but that's pretty ridiculous if you ask me. Why don't we do kernel's job in every userspace app then, say, for filesystems? This will make kernel devs' life easier after all. That's just a perfect example of the arrogance holding the whole FLOSS back I was talking about earlier :)
- jhasse 9y ago
  > Sure, we can make others do compositor's job, so compositor doesn't have to, but that's pretty ridiculous if you ask me. The difference is that the compositor doesn't necessarely have a toolkit for buttons and stuff like that at hand, while (most) applications already have. Also applications which actually use the space (i.e. GtkHeaderBar, Chrome, stuff like that) need to implement those window management functions anyway, so it would be duplicated work. Also: Theme development is easier if you don't have to write a window manager theme, too. Yes, CSD result in other duplicated work: Qt vs. Gtk+. And they come with lots of other disadvantages, e.g. as you've pointed out that it's hard to integrate Gtk+'s main loop and the difference of appearance between different toolkits. Regarding arrogance: You said that your solution is "proper". You called the pro-CSD folks "stubborn" and "irresponsible". You are the one dismissing all pro-CSD arguments. > Why don't we do kernel's job in every userspace app then, say, for filesystems? This will make kernel devs' life easier after all. Have you heard of FUSE?
  - seba_dos1 9y ago
    No, the reality is that on desktop, where window decorations should be drawn, the compositor usually has a toolkit for buttons and stuff at hand, since it's closely related to the whole DE being used - like in GNOME, Plasma or Enlightenment. What's more, this relation in Wayland world is even tighter than it was in X11, since under X you could easily replace the window manager and still be able to configure stuff like screens and input with tools from your DE. With Wayland, unless DEs agree on standard way to configure their compositors (there's no sign of it yet), you can't and that's by design. Those compositors who don't have a toolkit at hand usually aren't targeted for desktop at all. On mobile, embedded, automobile etc. you don't usually need a toolkit, cause you won't draw decorations anyway. Wayland is supposed to go deeper than desktop, you know, and now with popular compositor being CSD-only you need to adjust all the toolkits and apps to not draw them if you want to launch them there, instead of doing it once in the compositor. And yes, while for majority of them it doesn't make sense, there are plenty of desktop apps or games that can run just fine on mobile without any modification, I've used bunch of them on my Openmoko and Maemo phones. FUSE is exactly the situation like it is now on KDE Plasma, which I fully support - the compositor provides decorations for any app to use, but if the app is interested in doing them itself, it's free to. Just like the kernel which provides the filesystem support, but if you want to implement some fs by yourself in userspace, you're free to - there's little point in doing sshfs in kernel, after all, just like there's little point in doing browser tabs in compositor. What GNOME is doing, however, is putting all filesystems into FUSE - no, it doesn't even provide common API to access them - and that's just a terrible idea. Also, to use your own argument - last time I checked, majority of the apps don't customize their window decoration space. Sorry, I've heard those pro-CSD-only arguments multiple times already, they just don't provide enough merit to be taken seriously (they're also often mixed with just pro-CSD, which I have absolutely nothing against). At times it starts to look like it's a conscious sabotage of the Linux desktop, but more realistically (I hope!) it's probably just bunch of influential people not having wide enough perspective to put things into proper context. I still fully stand behind my words on being irresponsible. [edit] Oh, just thought about it - on desktop, you probably need a toolkit in the compositor anyway if you want to provide good UX, cause when some app freezes, you need to have some way to signalize that to the user and give them a way to choose between closing the app, waiting for it to unfreeze, moving it away etc. Plus, there's XWayland which won't go away anytime soon, where you obviously still need to draw decorations.

by jhasse 9y ago

seba_dos1 9y ago

Sure, we can make others do compositor's job, so compositor doesn't have to, but that's pretty ridiculous if you ask me. Why don't we do kernel's job in every userspace app then, say, for filesystems? This will make kernel devs' life easier after all. That's just a perfect example of the arrogance holding the whole FLOSS back I was talking about earlier :)

jhasse 9y ago
> Sure, we can make others do compositor's job, so compositor doesn't have to, but that's pretty ridiculous if you ask me. The difference is that the compositor doesn't necessarely have a toolkit for buttons and stuff like that at hand, while (most) applications already have. Also applications which actually use the space (i.e. GtkHeaderBar, Chrome, stuff like that) need to implement those window management functions anyway, so it would be duplicated work. Also: Theme development is easier if you don't have to write a window manager theme, too. Yes, CSD result in other duplicated work: Qt vs. Gtk+. And they come with lots of other disadvantages, e.g. as you've pointed out that it's hard to integrate Gtk+'s main loop and the difference of appearance between different toolkits. Regarding arrogance: You said that your solution is "proper". You called the pro-CSD folks "stubborn" and "irresponsible". You are the one dismissing all pro-CSD arguments. > Why don't we do kernel's job in every userspace app then, say, for filesystems? This will make kernel devs' life easier after all. Have you heard of FUSE?
- seba_dos1 9y ago
  No, the reality is that on desktop, where window decorations should be drawn, the compositor usually has a toolkit for buttons and stuff at hand, since it's closely related to the whole DE being used - like in GNOME, Plasma or Enlightenment. What's more, this relation in Wayland world is even tighter than it was in X11, since under X you could easily replace the window manager and still be able to configure stuff like screens and input with tools from your DE. With Wayland, unless DEs agree on standard way to configure their compositors (there's no sign of it yet), you can't and that's by design. Those compositors who don't have a toolkit at hand usually aren't targeted for desktop at all. On mobile, embedded, automobile etc. you don't usually need a toolkit, cause you won't draw decorations anyway. Wayland is supposed to go deeper than desktop, you know, and now with popular compositor being CSD-only you need to adjust all the toolkits and apps to not draw them if you want to launch them there, instead of doing it once in the compositor. And yes, while for majority of them it doesn't make sense, there are plenty of desktop apps or games that can run just fine on mobile without any modification, I've used bunch of them on my Openmoko and Maemo phones. FUSE is exactly the situation like it is now on KDE Plasma, which I fully support - the compositor provides decorations for any app to use, but if the app is interested in doing them itself, it's free to. Just like the kernel which provides the filesystem support, but if you want to implement some fs by yourself in userspace, you're free to - there's little point in doing sshfs in kernel, after all, just like there's little point in doing browser tabs in compositor. What GNOME is doing, however, is putting all filesystems into FUSE - no, it doesn't even provide common API to access them - and that's just a terrible idea. Also, to use your own argument - last time I checked, majority of the apps don't customize their window decoration space. Sorry, I've heard those pro-CSD-only arguments multiple times already, they just don't provide enough merit to be taken seriously (they're also often mixed with just pro-CSD, which I have absolutely nothing against). At times it starts to look like it's a conscious sabotage of the Linux desktop, but more realistically (I hope!) it's probably just bunch of influential people not having wide enough perspective to put things into proper context. I still fully stand behind my words on being irresponsible. [edit] Oh, just thought about it - on desktop, you probably need a toolkit in the compositor anyway if you want to provide good UX, cause when some app freezes, you need to have some way to signalize that to the user and give them a way to choose between closing the app, waiting for it to unfreeze, moving it away etc. Plus, there's XWayland which won't go away anytime soon, where you obviously still need to draw decorations.