5 ms·

>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 platfor

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

jchw 5y ago
> No, not really. On those other platforms you would link against the toolkit. This is factually incorrect. On Win32, window borders are drawn out-of-process by the OS. You do need to link to CreateWindow in user32, but that’s only vaguely a “UI toolkit” as CreateWindow is closer to a syscall than a library function. macOS internals are harder for me to ascertain, but it seems similar in how responsibility is split between OS and application. Besides that, GTK is not the canonical toolkit of Linux or Wayland. So this is not a reasonable option even if it would be on another system. > 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. They make GTK apps behave badly, but most Qt stuff works pretty reasonably. Anyways, if you dislike tiling WMs that’s fine, but I don’t and I want my apps to act decently, like apps designed to work with tiling WMs tend to work (which is not a huge ask at all, considering they don’t ask for much other than accurate window hints and no custom borders.) > 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. That’s not a good solution. That just means my app will look like crap if the compositor doesn’t support xdg-decoration. > 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. The difference is not whether or not window borders are optional. The difference is whether the app or the compositor handles window borders. And for that, this opinion is literally the crux of the issue.
- BrightGlow 5y ago
  >This is factually incorrect. On Win32, window borders are drawn out-of-process by the OS. You do need to link to CreateWindow in user32, but that’s only vaguely a “UI toolkit” as CreateWindow is closer to a syscall than a library function. You would still need to link against the toolkit. Plus, if it's a syscall, that means the kernel is involved in drawing the decorations, which is probably not going to happen in Linux. Sorry. Not every OS is built the same as Windows. If you like the way Windows is built, you might want to use it and not Linux. >Besides that, GTK is not the canonical toolkit of Linux or Wayland. Right, but that doesn't change it. If you want GTK decorations, you link against GTK. If you want other decorations then you link against another toolkit. If you don't care about the decorations and just want whatever then you could use xdg-decoration or libdecor, but not all app developers will want that. >So this is not a reasonable option even if it would be on another system. I don't understand what you mean reasonable? Both ways work if you're designing a system, you only have to care about them if you're a developer because it's a minor implementation detail. >They make GTK apps behave badly, but most Qt stuff works pretty reasonably. My experience is actually the opposite, Qt apps are even more likely to have odd sizing issues or inconsistent behavior. But I probably used a different set of apps than you did. >considering they don’t ask for much other than accurate window hints and no custom borders Maybe the window manager developers don't ask for anything but the apps are still broken. A lot of desktop apps cannot be placed into 1/6th of the corner of the screen and still work correctly but that's what tiling WMs try to do. Especially on a laptop with a small screen I find this behavior to be completely unusable. The window hints and borders are really not significant compared to all the other issues, so I honestly have no idea why some people seem to be so focused on that. >That just means my app will look like crap if the compositor doesn’t support xdg-decoration. This makes no sense to me. Libdecor will draw the fallback, if your app correctly supports xdg-decoration then it has to draw a fallback. The only thing xdg-decoration does is allow the compositor to draw fallbacks in some circumstances, so if you think the fallbacks all look like crap, then nothing you do there will ever help. There is no possible way to solve your problem. >The difference is not whether or not window borders are optional. The difference is whether the app or the compositor handles window borders. It's the same difference. Just as in X11, some window managers will never handle the window borders. There is nothing you can do about this besides patching all those window managers. But you probably don't care about that because most people don't seem to switch window managers very often.

jchw 5y ago

> No, not really. On those other platforms you would link against the toolkit. This is factually incorrect. On Win32, window borders are drawn out-of-process by the OS. You do need to link to CreateWindow in user32, but that’s only vaguely a “UI toolkit” as CreateWindow is closer to a syscall than a library function. macOS internals are harder for me to ascertain, but it seems similar in how responsibility is split between OS and application. Besides that, GTK is not the canonical toolkit of Linux or Wayland. So this is not a reasonable option even if it would be on another system. > 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. They make GTK apps behave badly, but most Qt stuff works pretty reasonably. Anyways, if you dislike tiling WMs that’s fine, but I don’t and I want my apps to act decently, like apps designed to work with tiling WMs tend to work (which is not a huge ask at all, considering they don’t ask for much other than accurate window hints and no custom borders.) > 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. That’s not a good solution. That just means my app will look like crap if the compositor doesn’t support xdg-decoration. > 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. The difference is not whether or not window borders are optional. The difference is whether the app or the compositor handles window borders. And for that, this opinion is literally the crux of the issue.

BrightGlow 5y ago
>This is factually incorrect. On Win32, window borders are drawn out-of-process by the OS. You do need to link to CreateWindow in user32, but that’s only vaguely a “UI toolkit” as CreateWindow is closer to a syscall than a library function. You would still need to link against the toolkit. Plus, if it's a syscall, that means the kernel is involved in drawing the decorations, which is probably not going to happen in Linux. Sorry. Not every OS is built the same as Windows. If you like the way Windows is built, you might want to use it and not Linux. >Besides that, GTK is not the canonical toolkit of Linux or Wayland. Right, but that doesn't change it. If you want GTK decorations, you link against GTK. If you want other decorations then you link against another toolkit. If you don't care about the decorations and just want whatever then you could use xdg-decoration or libdecor, but not all app developers will want that. >So this is not a reasonable option even if it would be on another system. I don't understand what you mean reasonable? Both ways work if you're designing a system, you only have to care about them if you're a developer because it's a minor implementation detail. >They make GTK apps behave badly, but most Qt stuff works pretty reasonably. My experience is actually the opposite, Qt apps are even more likely to have odd sizing issues or inconsistent behavior. But I probably used a different set of apps than you did. >considering they don’t ask for much other than accurate window hints and no custom borders Maybe the window manager developers don't ask for anything but the apps are still broken. A lot of desktop apps cannot be placed into 1/6th of the corner of the screen and still work correctly but that's what tiling WMs try to do. Especially on a laptop with a small screen I find this behavior to be completely unusable. The window hints and borders are really not significant compared to all the other issues, so I honestly have no idea why some people seem to be so focused on that. >That just means my app will look like crap if the compositor doesn’t support xdg-decoration. This makes no sense to me. Libdecor will draw the fallback, if your app correctly supports xdg-decoration then it has to draw a fallback. The only thing xdg-decoration does is allow the compositor to draw fallbacks in some circumstances, so if you think the fallbacks all look like crap, then nothing you do there will ever help. There is no possible way to solve your problem. >The difference is not whether or not window borders are optional. The difference is whether the app or the compositor handles window borders. It's the same difference. Just as in X11, some window managers will never handle the window borders. There is nothing you can do about this besides patching all those window managers. But you probably don't care about that because most people don't seem to switch window managers very often.