Argumenting Client-Side Decorations
arcan-fe.com
arcan-fe.com
So I can support KDE's SSD protocol. Fine, can do it. But... what about other compositors, like GNOME's Mutter? Oh, great, so I'll have to implement full working window decoration by myself, only for this single windowing system on a single platform? How should it look? How should it behave? How should it be configured? Who the hell even thought that would be a good idea?
OK, let's check SDL2 then, it's a quite similar and nowadays more popular library, I wonder how did they do it, as I heard they have Wayland support already done. Oh... window decorations on SDL2/Wayland are not implemented, so there is just no decoration. https://bugzilla.libsdl.org/show_bug.cgi?id=2710
Awesome. I'll probably end up with the same thing, as I'm using KDE Plasma and it will just work fine for me. Whatever.
CSD is an awful idea and whoever came up with it should feel bad. Massive step back.
(in fact, Allegro already has an extension that makes it use Gtk+ on X11 if you want to use native dialogs and menus, but it's a completely optional extension for a reason, as most games don't need them anyway)
Can you give an example?
> Also, it adds a very big dependency to distribute with your game if you want to bundle the deps or link statically, so the binary doesn't break in a few years when distributions will stop packaging Gtk+3.
Since distributions are still shipping Gtk+ 2, I doubt that this will happen "in a few years".
Gtk+2 has some major apps like Gimp that ensure that it's here to stay for a while. Gtk+3's life will sure be shorter, more like Qt4's.
Anyway, it doesn't matter. There is no need for Allegro to link with Gtk+ by default, period. Just like mpv, just like SDL, just like many other apps and libraries that don't need a regular toolkit. For some it might be even hard to integrate the glib's mainloop. "You should use Gtk+" in CSD discussion is just a display of arrogance.
Plasma Mobile officially supports Gtk+.
"Native apps are developed using Qt; it will also support apps written in GTK, Android apps, Ubuntu apps, and many others" https://dot.kde.org/2015/07/25/plasma-mobile-free-mobile-pla...
> Gtk+2 has some major apps like Gimp that ensure that it's here to stay for a while. Gtk+3's life will sure be shorter, more like Qt4's.
Why? Also: GIMP will move to Gtk+ 3 in a few years. Furthermore Gtk+ 3 has even bigger apps: Firefox and Chrome.
> For some it might be even hard to integrate the glib's mainloop.
That's a valid argument.
Why do you need arguments from me anyway? There's no good argument for CSD, and without it there wouldn't be any problem at all ;P
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.
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.
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.
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.
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.
That's just a perfect example of the arrogance holding the whole FLOSS back I was talking about earlier :)
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?
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.
What you would loose is the ability to configure the appearance of the decorations because the WM might do it differently. With CSD this is done by Gtk+ regardless of the WM.
> 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.
A toolkit is still needed for buttons, text, etc.
> I've used bunch of them on my Openmoko and Maemo phones.
Both come with Gtk+.
> Also, to use your own argument - last time I checked, majority of the apps don't customize their window decoration space.
Have a look at Windows and you'll see that most apps will do it if they are able to. All web browsers, the file manager, Office, ...
Also most GNOME apps are already using GtkHeaderBar. And let's not forget the most used applications: Chrome and Firefox (still behind a config flag atm).
> 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.
GNOME Shell uses St for that, not Gtk+.
WM is the place where I want to configure the appearance and behavior of window decorations. So that's expected and positive. Point to me.
> With CSD this is done by Gtk+ regardless of the WM.
No, it's done by every toolkit separately regardless of the WM. You have one WM, and you have many toolkits. This is how the user looses the ability to configure the appearance of window decorations. Point to me.
> A toolkit is still needed for buttons, text, etc.
Some compositors don't need it. But yeah, most do. Point to me anyway.
> Both come with Gtk+.
Yeah, Gtk+2, which doesn't do CSD at all. And in both Openmoko 2008 and Maemo 6, GTK+ apps were already looking out of place, superseded by Qt and/or EFL. I'm not even sure if it was installed by default anymore.
With CSD-only, stuff like Illume in Openmoko wouldn't be possible at all. It was already horrible to make it work well on X, don't make it even harder on Wayland!
> Have a look at Windows and you'll see that most apps will do it if they are able to. All web browsers, the file manager, Office, ...
Taking a look at Windows apps is the best point against CSD :) GNOME is following the example and starts to look awful and inconsistent as well, and let's not even speak about UX. Thankfully, I don't have to use it.
> Chrome and Firefox
Both configurable. For a reason. Even though they are actually in the minority of apps where CSD totally makes sense. Go figure.
Anyway, this discussion went far off topic now. If you want to, use CSD in your app or your toolkit. I don't care. It will look ugly, have bad UX and it will add to the configuration mess, but I don't have to use it, so it will be problem of your users, not me. CSD works under X already, with a few caveats, but under Wayland it's already fixed, there's no issue with it at all.
However, when you make a compositor for the desktop and you make it require CSD from every app out there, that's just evil, mean and creates problems. Don't do it.
The appearance won't match with GtkHeaderBar apps then.
> No, it's done by every toolkit separately regardless of the WM. You have one WM, and you have many toolkits.
You have one WM running at a time, but multiple to choose from. And as I said: The idea is to have only one toolkit: Gtk+.
> But yeah, most do. Point to me anyway.
...
> Taking a look at Windows apps is the best point against CSD :)
That's your opinion, not a fact.
If your app have special needs and has to use CSD, it's up to you to provide (or not) matching appearance for your users, by toolkit or any other means to achieve that. With CSD-only, you're guaranteed to get non-matching appearance. It's way easier to provide all-matching appearance with SSD, since it's only minority of toolkits that decided to go full CSD, so you just have to match your Gtk+ style.
> ...
Let me remind you - the idea that compositor theoretically does not need a toolkit was yours, as an argument for CSD-only compositor. I have showed you that while theoretically it might have some merit, especially on mobile, in practice it doesn't work that way with desktop environments on Wayland - so it can't really be taken as a case in this point.
> The idea is to have only one toolkit: Gtk+.
Wow. Just, no. The only Gtk+3 app I usually run on my desktop is Firefox, and it's not even exactly a Gtk+ app. Let's keep such crazy ideas as science fiction, please.
That might explain some attitudes on this topic (and some others - interoperability was always a somewhat poor side of the GNOME camp) though. Not a happy thought to be honest.
Who defines what's special and what's normal though?
> I have showed you that while theoretically it might have some merit, especially on mobile, in practice it doesn't work that way with desktop environments on Wayland - so it can't really be taken as a case in this point.
Because of Xwayland and interactions with the user?
Typical app does not need to touch its window decoration, only some need. The distinction is natural. Even Gtk+ knows that distinction and lets you disable CSD for apps that don't customize the header bar.
> Because of Xwayland and interactions with the user?
Because it's tightly related to the whole DE, even more than under X, and that DE already has a toolkit for the compositor to use, be it Gtk+, Qt, Evas, St or whatever else. Plus, interactions. Plus, XWayland.
What's "typical" though?
So in order for minimizing windows to work, every app has to use an extension called xdg_shell to create and manage their windows instead, one that's not guaranteed to be present and kept changing in backwards-incompatible ways. (Not just any version either; it has to be xdg_shell v5 or later. Also, apparently versions before v6 can't coexist with each other, trying to use a mismatched version just stops the application from working at all.)
I believe xdg-shell is officially stable as of December, so it'll be a while before it's supported everywhere and we don't yet know what happens if people discover more use cases that have to be added. This happened quite some time after major distros started shipping Wayland by default.
If that was true, why does GNOME include the ability to minimize then? The only thing that was removed was the minmize button. Try Super+H or right click -> Minimize.
Which probably makes OPs opinion on questions such as this worthwhile to consider.
If you refuse to support remote displays, then you can probably get away with not caring about latency. And who wants to support remote displays anyways? Oh, well, right, ssh display forwarding, RDP, -- these exist for a reason: users need remote displays! But if you can't run a browser remotely because the latency is huge, and because every redraw involves sending entire canvasses across the network, then you've clearly lost the war to support remote displays.
(Keep in mind that no one needs a remote display to run an xterm. If the app isn't graphical there's no point. And if the app is graphical then redrawing by resending everything that the server has already seen... is just so much hating your users.)
Now I know everything I needed to know about Wayland. What a wonderful FA.
EDIT: Is Wayland yet another case of NIH? Is Linux the land of the devs who say NIH?
The latency issue is something you'll notice in the same way when working with Windows' remote desktop (which uses RDP).
I'm not saying that Wayland can't have remote displays. I'm saying that if you want them (and we do) then you want low latency.
EDIT: Allow me to quote myself:
> And who wants to support remote displays anyways? Oh, well, right, ssh display forwarding, RDP, -- these exist for a reason: users need remote displays!
Is that not crystal clear? Several remote display technologies (X11, X11 over ssh, RDP) that exist... because users need them.
Keep in mind that the latency is only for changes to the mouse cursor and some window operations. Most of the time you will actually use the content of the window which has the same latency as ssh -X forwarding.
I hope Wayland is not bereft of this concept, and most well-behaved apps will keep delegating windows management to it.