3 ms·

> It's not a good enough argument to bring in an unwanted dependency you might not have installed on your device otherwise, especially on a device with limited

by jhasse 9y ago

> It's not a good enough argument to bring in an unwanted dependency you might not have installed on your device otherwise, especially on a device with limited space and memory. Would be interesting to know if Plasma Mobile has Gtk+ installed out-of-the-box. Regarding space: Gtk+ isn't that big that this should matter. Also: You don't need decorations on a mobile phone anyway. > There's no good argument for CSD I and many others disagree.

seba_dos1 9y ago
> You don't need decorations on a mobile phone anyway. For that point to bring anything meaningful into the conversation it would mean that we'd have to write two separate Wayland backends - one for sensible compositors and platforms where decorations aren't needed, and second one with Gtk+ for CSD. Not going to happen. Also, no, it wouldn't be interesting for this matter at all. The library like Allegro or SDL shouldn't bring such dependencies as a complete toolkit with itself for such a tiny stupid (yet essential) thing like window decoration. Just because you don't care about making your stuff lightweight and well designed, it doesn't mean nobody cares. CSD only makes things complicated, both for app developers, who now have to suddenly have to care not only about drawing decos, but also silly things like inactive borders for shadows; and for users, who then get tons of different decos across windows on a single desktop. If you want to make an app with custom decorations, fine, do it, I'm even glad there are now protocols for that - but don't make it mandatory for everyone just because you're too lazy to support decorations in your compositor. And in this whole discussion, you didn't even bring one argument for it, aside of "many disagree" - only an unwanted solution to artificial problem. The proper solution is "support SSD in your compositor". There is a protocol for that too now.
- jhasse 9y ago
  > Just because you don't care about making your stuff lightweight and well designed, it doesn't mean nobody cares. Just because you care, doesn't mean the majority cares. > And in this whole discussion, you didn't even bring one argument for it Yes, because I thought we weren't discussing about CSD vs. SSD, but if using Gtk+ to get window decorations in a CSD-only world is viable. > CSD only makes things complicated No, it makes things easier for the compositor / window manager. But we're drifting off into the general CSD vs. SSD argument, which has been discussed countless times before.
  - seba_dos1 9y ago
    How is any "majority" relevant here? Majority of apps don't care about CSD vs. SSD at all, because why would they? Most use toolkits, most don't care about decorations whatsoever, because they just are there automatically. That's completely missing the point. It's the CSD-stubborness of some projects that make everyone's life worse (now just minority of developers, but increasing number of users as well, since Gtk+ is not the only toolkit out there) and opens the can of pandora that leads to this kind of problems we're discussing here. It's completely unnecessary (you can use CSD on KDE Plasma after all, you're not losing anything!) and brings the whole state of FLOSS a few steps back, holding back the Wayland migration as well. I'm sad that some people are so focused on their own needs that they fail to notice that. It's irresponsible.
    - 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?

by jhasse 9y ago

seba_dos1 9y ago

> You don't need decorations on a mobile phone anyway. For that point to bring anything meaningful into the conversation it would mean that we'd have to write two separate Wayland backends - one for sensible compositors and platforms where decorations aren't needed, and second one with Gtk+ for CSD. Not going to happen. Also, no, it wouldn't be interesting for this matter at all. The library like Allegro or SDL shouldn't bring such dependencies as a complete toolkit with itself for such a tiny stupid (yet essential) thing like window decoration. Just because you don't care about making your stuff lightweight and well designed, it doesn't mean nobody cares. CSD only makes things complicated, both for app developers, who now have to suddenly have to care not only about drawing decos, but also silly things like inactive borders for shadows; and for users, who then get tons of different decos across windows on a single desktop. If you want to make an app with custom decorations, fine, do it, I'm even glad there are now protocols for that - but don't make it mandatory for everyone just because you're too lazy to support decorations in your compositor. And in this whole discussion, you didn't even bring one argument for it, aside of "many disagree" - only an unwanted solution to artificial problem. The proper solution is "support SSD in your compositor". There is a protocol for that too now.

jhasse 9y ago
> Just because you don't care about making your stuff lightweight and well designed, it doesn't mean nobody cares. Just because you care, doesn't mean the majority cares. > And in this whole discussion, you didn't even bring one argument for it Yes, because I thought we weren't discussing about CSD vs. SSD, but if using Gtk+ to get window decorations in a CSD-only world is viable. > CSD only makes things complicated No, it makes things easier for the compositor / window manager. But we're drifting off into the general CSD vs. SSD argument, which has been discussed countless times before.
- seba_dos1 9y ago
  How is any "majority" relevant here? Majority of apps don't care about CSD vs. SSD at all, because why would they? Most use toolkits, most don't care about decorations whatsoever, because they just are there automatically. That's completely missing the point. It's the CSD-stubborness of some projects that make everyone's life worse (now just minority of developers, but increasing number of users as well, since Gtk+ is not the only toolkit out there) and opens the can of pandora that leads to this kind of problems we're discussing here. It's completely unnecessary (you can use CSD on KDE Plasma after all, you're not losing anything!) and brings the whole state of FLOSS a few steps back, holding back the Wayland migration as well. I'm sad that some people are so focused on their own needs that they fail to notice that. It's irresponsible.
  - 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?