4 ms·

> 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

by jhasse 9y ago

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

seba_dos1 9y ago
> What you would loose is the ability to configure the appearance of the decorations because the WM might do it differently. 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.
- jhasse 9y ago
  > 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. 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.
  - seba_dos1 9y ago
    > The appearance won't match with GtkHeaderBar apps then. 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.
    - jhasse 9y ago
      > If your app have special needs and has to use CSD, [...] 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?

by jhasse 9y ago

seba_dos1 9y ago

> What you would loose is the ability to configure the appearance of the decorations because the WM might do it differently. 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.

jhasse 9y ago
> 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. 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.
- seba_dos1 9y ago
  > The appearance won't match with GtkHeaderBar apps then. 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.
  - jhasse 9y ago
    > If your app have special needs and has to use CSD, [...] 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?