5 ms·

>Does libdecor even support XDG Decoration? It does, that was the first thing added. I wouldn't suggest using xdg-decoration though as it will mostly guarantee

>Does libdecor even support XDG Decoration? It does, that was the first thing added. I wouldn't suggest using xdg-decoration though as it will mostly guarantee that your apps don't match the decorations. >And telling me all Linux apps they should link against GTK would make me angry if it wasn’t so stupid. If you want GTK decorations, then you should link against GTK. Not sure why you would think that's stupid or would make you angry, please elaborate. If you don't want to use compile time linkage then you can use dlopen, that's what libdecor does under the hood. >KDE does not appear to be embodying the CSD initiative This isn't entirely true, some KDE apps have actually started to use client-side decorations. >which is actually Good for GNOME users, since KDE apps will likely feel a ton more native in GNOME as a result I don't think so, KDE apps will never feel native in GNOME as they're built for a different HIG. Using non-matching decorations will actually make it worse because now the application is following two separate and incompatible HIGs. That's a good way to ensure you get conflicting gestures/keybinds, inconsistent theming, and just a general lack of consistency. >what we as app developers really want is one solution that gives us fully native basic window borders everywhere I don't want that when I'm making apps. If I'm making a GTK app then I would expect to get the GTK borders. If I'm making a Qt app then I would expect to get the Qt borders. And so on. >And to do that, we need a solution that starts from the common ground (xdg-decoration) then goes into special cases (GNOME, Weston, etc.) This isn't correct, xdg-decoration is not the common ground. The common ground would be drawing your own decorations because that's the way any Wayland server works by default. Xdg-decoration is an optional extension that even with its presence doesn't guarantee you will get the borders that you want.

h_anna_h 5y ago
> I don't want that when I'm making apps. If I'm making a GTK app then I would expect to get the GTK borders. If I'm making a Qt app then I would expect to get the Qt borders. And so on. Surely the choice should fall on the user. > That's a good way to ensure you get conflicting gestures/keybinds, inconsistent theming, and just a general lack of consistency. Which is why we would like all of these to be configurable. > The common ground would be drawing your own decorations because that's the way any Wayland server works by default What if I, as a user of a tiling wm don't want any decorations? > Xdg-decoration is an optional extension That everything supports it afaik. (except mutter?)
- BrightGlow 5y ago
  >Surely the choice should fall on the user. It does, the user can choose to use GTK or Qt apps. >Which is why we would like all of these to be configurable. So making it all configurable is just guaranteeing that the app is broken out of the box and needs to have all this stuff set up before it even works correctly. Not exactly a user-friendly way to ship a program. >What if I, as a user of a tiling wm don't want any decorations? You may have to accept that some apps are not built to work in a tiling WM. In my experience, you will have a lot of trouble with some apps for various other reasons too, not just the decorations. >That everything supports it afaik. (except mutter?) I'm confused, you said everything supports it, but then immediately listed something that didn't support it.
  - h_anna_h 5y ago
    > It does, the user can choose to use GTK or Qt apps. That's... not what I meant by it. I find this dangerous as it encourages duplicate work for minor differences. I would rather not have to make both a GTK and a Qt version of my program just so my users can have the ability to do some basic customization. > So making it all configurable is just guaranteeing that the app is broken out of the box Not sure why you think that. You just put the existing choices as the defaults. > You may have to accept that some apps are not built to work in a tiling WM What about my apps then? As a programmer I want my programs to be friendly for both tiling and non-tiling WMs. This by itself excludes gtk as an option for me. As for some apps not built to work in tiling WMs, the changes needed to make them work properly are usually extremely minor. To be honest it feels like the GNOME team is going out of their way to degrade the usability of their apps (and apps using gtk) for tiled WMs. > In my experience, you will have a lot of trouble with some apps for various other reasons too Some apps might have some minor issues that can usually be solved without a lot of effort, but even if they are not they don't usually pose any problem. > I'm confused, you said everything supports it, but then immediately listed something that didn't support it. Yes? Everything except mutter supports it as far as I know. Is there something difficult to understand here? Edit: I heard that Enlightenment does not support it either.
    - 5y ago
jchw 5y ago
I absolutely consider xdg-decoration to be the common ground because it gives behavior similar to Windows, X11, macOS, BeOS, and just about every other platform out there. If someone’s X11 WM doesn’t give them window borders, that’s fine: they probably have a lot of apps with no window borders, that’s probably the point of their WM. Sorry, but GTK 3+ apps will look wildly out of place in any tiling WM whereas apps using xdg-decoration will be just fine. Consider the following: any compositor can choose to support xdg-decoration and get automatic support, apparently including for libdecor. It is definitely defacto common ground, because every other compositor becomes a special case. I will grant you that I didn’t know libdecor supported xdg-decoration. I attempted to read the source code once and entirely missed it, possibly because I was focusing too hard on the plugins aspect. Anyways, this is going too far off the deep end now. Yes I understand that Dolphin will never look as native under GNOME as Nautilus. However, it is not even close to how ridiculously non-native Nautilus looks under KDE; it’s simply no contest. It looks like a funny VMWare Unity Mode demo rather than interoperability. I’m also well aware that Wayland is built to not require something like xdg-decoration, but we’re at an impasse because you view that as a feature and I view it as a bug.
- BrightGlow 5y ago
  >I absolutely consider xdg-decoration to be the common ground because it gives behavior similar to Windows, X11, macOS, BeOS, and just about every other platform out there. No, not really. On those other platforms you would link against the toolkit. >If someone’s X11 WM doesn’t give them window borders, that’s fine: they probably have a lot of apps with no window borders, that’s probably the point of their WM. Same thing with Wayland, except typically apps are expected to draw the window borders there. >Sorry, but GTK 3+ apps will look wildly out of place in any tiling WM whereas apps using xdg-decoration will be just fine. Every time I used a tiling WM, almost every single app looked and acted wildly out of place. A tiling WM is simply not an application platform. I've honestly found that tiling WMs are only good for arranging terminal windows, they make most other GUI applications behave badly. >Consider the following: any compositor can choose to support xdg-decoration and get automatic support, apparently including for libdecor. It is definitely defacto common ground, because every other compositor becomes a special case. No, this isn't true, you may be confused as to what xdg-decoration actually is. If you don't implement xdg-decoration and you use libdecor then the behavior is the same as if xdg-decoration turns off the decorations, libdecor will draw its own. >However, it is not even close to how ridiculously non-native Nautilus looks under KDE; it’s simply no contest. It looks like a funny VMWare Unity Mode demo rather than interoperability. Yes, apps that don't follow the KDE HIG will always look non-native. Try to run windows apps in Wine and it will similarly look out-of-place. Try to run some old Motif apps and they'll look weird too. If you want to get an app that looks and acts native in KDE then you would want to use the KDE frameworks. Why complain about this when you're use an app that is intentionally designed for a different platform? >I’m also well aware that Wayland is built to not require something like xdg-decoration, but we’re at an impasse because you view that as a feature and I view it as a bug. So it doesn't really matter if either of us view it as a feature or bug. From the perspective of the window manager, decorations are still an optional thing just as they were in X11.

h_anna_h 5y ago

> I don't want that when I'm making apps. If I'm making a GTK app then I would expect to get the GTK borders. If I'm making a Qt app then I would expect to get the Qt borders. And so on. Surely the choice should fall on the user. > That's a good way to ensure you get conflicting gestures/keybinds, inconsistent theming, and just a general lack of consistency. Which is why we would like all of these to be configurable. > The common ground would be drawing your own decorations because that's the way any Wayland server works by default What if I, as a user of a tiling wm don't want any decorations? > Xdg-decoration is an optional extension That everything supports it afaik. (except mutter?)

BrightGlow 5y ago
>Surely the choice should fall on the user. It does, the user can choose to use GTK or Qt apps. >Which is why we would like all of these to be configurable. So making it all configurable is just guaranteeing that the app is broken out of the box and needs to have all this stuff set up before it even works correctly. Not exactly a user-friendly way to ship a program. >What if I, as a user of a tiling wm don't want any decorations? You may have to accept that some apps are not built to work in a tiling WM. In my experience, you will have a lot of trouble with some apps for various other reasons too, not just the decorations. >That everything supports it afaik. (except mutter?) I'm confused, you said everything supports it, but then immediately listed something that didn't support it.
- h_anna_h 5y ago
  > It does, the user can choose to use GTK or Qt apps. That's... not what I meant by it. I find this dangerous as it encourages duplicate work for minor differences. I would rather not have to make both a GTK and a Qt version of my program just so my users can have the ability to do some basic customization. > So making it all configurable is just guaranteeing that the app is broken out of the box Not sure why you think that. You just put the existing choices as the defaults. > You may have to accept that some apps are not built to work in a tiling WM What about my apps then? As a programmer I want my programs to be friendly for both tiling and non-tiling WMs. This by itself excludes gtk as an option for me. As for some apps not built to work in tiling WMs, the changes needed to make them work properly are usually extremely minor. To be honest it feels like the GNOME team is going out of their way to degrade the usability of their apps (and apps using gtk) for tiled WMs. > In my experience, you will have a lot of trouble with some apps for various other reasons too Some apps might have some minor issues that can usually be solved without a lot of effort, but even if they are not they don't usually pose any problem. > I'm confused, you said everything supports it, but then immediately listed something that didn't support it. Yes? Everything except mutter supports it as far as I know. Is there something difficult to understand here? Edit: I heard that Enlightenment does not support it either.
  - 5y ago

jchw 5y ago

I absolutely consider xdg-decoration to be the common ground because it gives behavior similar to Windows, X11, macOS, BeOS, and just about every other platform out there. If someone’s X11 WM doesn’t give them window borders, that’s fine: they probably have a lot of apps with no window borders, that’s probably the point of their WM. Sorry, but GTK 3+ apps will look wildly out of place in any tiling WM whereas apps using xdg-decoration will be just fine. Consider the following: any compositor can choose to support xdg-decoration and get automatic support, apparently including for libdecor. It is definitely defacto common ground, because every other compositor becomes a special case. I will grant you that I didn’t know libdecor supported xdg-decoration. I attempted to read the source code once and entirely missed it, possibly because I was focusing too hard on the plugins aspect. Anyways, this is going too far off the deep end now. Yes I understand that Dolphin will never look as native under GNOME as Nautilus. However, it is not even close to how ridiculously non-native Nautilus looks under KDE; it’s simply no contest. It looks like a funny VMWare Unity Mode demo rather than interoperability. I’m also well aware that Wayland is built to not require something like xdg-decoration, but we’re at an impasse because you view that as a feature and I view it as a bug.

BrightGlow 5y ago
>I absolutely consider xdg-decoration to be the common ground because it gives behavior similar to Windows, X11, macOS, BeOS, and just about every other platform out there. No, not really. On those other platforms you would link against the toolkit. >If someone’s X11 WM doesn’t give them window borders, that’s fine: they probably have a lot of apps with no window borders, that’s probably the point of their WM. Same thing with Wayland, except typically apps are expected to draw the window borders there. >Sorry, but GTK 3+ apps will look wildly out of place in any tiling WM whereas apps using xdg-decoration will be just fine. Every time I used a tiling WM, almost every single app looked and acted wildly out of place. A tiling WM is simply not an application platform. I've honestly found that tiling WMs are only good for arranging terminal windows, they make most other GUI applications behave badly. >Consider the following: any compositor can choose to support xdg-decoration and get automatic support, apparently including for libdecor. It is definitely defacto common ground, because every other compositor becomes a special case. No, this isn't true, you may be confused as to what xdg-decoration actually is. If you don't implement xdg-decoration and you use libdecor then the behavior is the same as if xdg-decoration turns off the decorations, libdecor will draw its own. >However, it is not even close to how ridiculously non-native Nautilus looks under KDE; it’s simply no contest. It looks like a funny VMWare Unity Mode demo rather than interoperability. Yes, apps that don't follow the KDE HIG will always look non-native. Try to run windows apps in Wine and it will similarly look out-of-place. Try to run some old Motif apps and they'll look weird too. If you want to get an app that looks and acts native in KDE then you would want to use the KDE frameworks. Why complain about this when you're use an app that is intentionally designed for a different platform? >I’m also well aware that Wayland is built to not require something like xdg-decoration, but we’re at an impasse because you view that as a feature and I view it as a bug. So it doesn't really matter if either of us view it as a feature or bug. From the perspective of the window manager, decorations are still an optional thing just as they were in X11.