SDL2 Picks Up Support For KDE Server-Side Decorations

[R41N3R]

Heh, I haven't seen that one, since I'm not using Gnome. Developers are really being too stubborn there for no good reason.

Yes, arguments do not matter for these Gnome developers. I really like the consistent look of all my applications. As Gnome/Gtk behaves terrible in this regard I had to replace most of them. For somebody following these discussions for years I still cannot understand why they cannot support something simple like SSD. I consider it quite hostile if Gnome/Gtk apps try to enforce these inconsistent window decorations on my system.

[ssokolow]

Arcan sounds interesting. Is it supposed to work with existing DEs or it's aimed at some custom DE itelf?

"sounds interesting" is an understatement. It sometimes feels like Björn Ståhl has said more about the design and architecture of Arcan and Durden than the entire rest of the ecosystem has about Wayland. (Plus, it's got experimental EGLStreams support that I'm planning to try out... though I've decided to wait until I can find time to upgrade off Kubuntu 14.04 LTS first.)

As to your question, it's got a shell named Durden which is comparable to AwesomeWM in many ways, plus two experimental shells, Prio and Safespaces.

[Khrundel]

Yes, arguments do not matter for these Gnome developers. I really like the consistent look of all my applications. As Gnome/Gtk behaves terrible in this regard I had to replace most of them. For somebody following these discussions for years I still cannot understand why they cannot support something simple like SSD. I consider it quite hostile if Gnome/Gtk apps try to enforce these inconsistent window decorations on my system.

Gnome developers are 100% right. You can't get "consistent look" anyway: now when half of UI, you are interacting with is either UI of websites or made of electron, they simply can't give you native look and feel, especially if you've selected some funny theme. And even native apps tend to have their own look and feel, so there is no point to even try. SSD makes everything worse: if your window looks like material designed or adopts motif style or mock some electric applience, but have KDE's header, that is inconsistency far more ugly. CSD gives you consistent look within a window and allows to use header space for something useful and also avoids job of composing parts, rendered by different processes within one window.
Actually, there only two legit reasons why anybody could oppose abolition of SSD. First, that mean additional work for those who are creating some windows without using of toolkits. That can be fixed by some lightweight library for drawing decorations. Second: authors of DEs might want to have their headers to add useless features, like hiding headers in fullscreen mode or adding some buttons like "mute this app" or "always on top". But, when you got rid of header bars, like gnome did, there are nithing to hide in fullscreen mode, and instead of adding tons of meaningless buttons there can be one window button with popup nenu with all these features.

[ssokolow]

Gnome developers are 100% right. You can't get "consistent look" anyway: now when half of UI, you are interacting with is either UI of websites or made of electron, they simply can't give you native look and feel, especially if you've selected some funny theme. And even native apps tend to have their own look and feel, so there is no point to even try. SSD makes everything worse: if your window looks like material designed or adopts motif style or mock some electric applience, but have KDE's header, that is inconsistency far more ugly. CSD gives you consistent look within a window and allows to use header space for something useful and also avoids job of composing parts, rendered by different processes within one window.
Actually, there only two legit reasons why anybody could oppose abolition of SSD. First, that mean additional work for those who are creating some windows without using of toolkits. That can be fixed by some lightweight library for drawing decorations. Second: authors of DEs might want to have their headers to add useless features, like hiding headers in fullscreen mode or adding some buttons like "mute this app" or "always on top". But, when you got rid of header bars, like gnome did, there are nithing to hide in fullscreen mode, and instead of adding tons of meaningless buttons there can be one window button with popup nenu with all these features.

I am neither of those and I have some complaints about it:

First, I consider consistent titlebars more important than consistency between titlebars and window content. I see your argument as being analogous to "Every website should be allowed to customize the look and feel of its tab in the browser's tab bar" ...and I seriously hope you're not MySpace-crazy enough to be in favour of that. (It's bad enough that some browser engines implemented vendor-specific ways to allow sites to customize the look of the top-level scrollbar.)

Second, SSD allows the window manager a standard place to provide functionality the application developer never thought of. (Thankfully, KWin also provides a hotkey that triggers its context menu, but that still doesn't account for anyone on a window manager like Fluxbox that supports WM-level tabbing.)

Third, GNOME's vision of what goes in the titlebar on a dialog box runs direcly counter to decades of Human-Computer Interaction research and some of the founding design principles of the WIMP (Windows, Icons, Menus, Pointer) paradigm. For example, that, like a paper form, the natural interaction flow of a dialog should be the same as reading a page of text in the language in question... meaning that OK/Cancel and other action buttons should be at the bottom. (This is a recurring problem I've noticed with GNOME. They copy the superficial elements of desktops (primarily MacOS) but miss the point on why those elements originally were developed. Classic cargo cult thinking.)

[Weasel]

Gnome developers are 100% right.

No they are 100% wrong.

You can't get "consistent look" anyway: now when half of UI, you are interacting with is either UI of websites or made of electron, they simply can't give you native look and feel, especially if you've selected some funny theme.

Who the hell considers websites part of "native look and feel"? Damn normies.

And even native apps tend to have their own look and feel

Unless the app requires it in some way for something with actual purpose, then you're only using shitty apps or are designed like garbage.

Second: authors of DEs might want to have their headers to add useless features,

Gnome devs don't get to decide what features are "useless" or not. Their shitty DE is useless.

[Khrundel]

First, I consider consistent titlebars more important than consistency between titlebars and window content. I see your argument as being analogous to "Every website should be allowed to customize the look and feel of its tab in the browser's tab bar" ...and I seriously hope you're not MySpace-crazy enough to be in favour of that. (It's bad enough that some browser engines implemented vendor-specific ways to allow sites to customize the look of the top-level scrollbar.)

So, you're OK with crazy-styled buttons within browser's client area, buttons you have to push all the time, but browser's tab and close-button from a header must be correctly styled and same way as close button from another windows? Looks more like you're just rationalising.

Second, SSD allows the window manager a standard place to provide functionality the application developer never thought of. (Thankfully, KWin also provides a hotkey that triggers its context menu, but that still doesn't account for anyone on a window manager like Fluxbox that supports WM-level tabbing.)

Yes, and I've mentioned this reason. For me, that is just another toy, thing you'll never use. But there can be a middleground: one standard button to invoke WM menu.

Third, GNOME's vision of what goes in the titlebar on a dialog box runs direcly counter to decades of Human-Computer Interaction research and some of the founding design principles of the WIMP (Windows, Icons, Menus, Pointer) paradigm. For example, that, like a paper form, the natural interaction flow of a dialog should be the same as reading a page of text in the language in question... meaning that OK/Cancel and other action buttons should be at the bottom. (This is a recurring problem I've noticed with GNOME. They copy the superficial elements of desktops (primarily MacOS) but miss the point on why those elements originally were developed. Classic cargo cult thinking.)

Please, stop pretending there are some kind of traditions and wisdom. Every f****ng time new version of windows/MacOS/KDE/GNOME/Android is coming out they are changing controls styles just to show that this is a new product. And not just changing look, they for example replaced standard and tabbed control with accordion and nobody actually mind. I think UX-specialists, like any others, tend to exaggerate importance of their job.

[Khrundel]

Who the hell considers websites part of "native look and feel"? Damn normies.

I don't see much difference between some online app like calculator or todo list and native one. If one can have its own look, why can't another?

Unless the app requires it in some way for something with actual purpose, then you're only using shitty apps or are designed like garbage.

I'm not a big fan of all these skins, but why fight losing battle for a principle, which worth nothing?

Gnome devs don't get to decide what features are "useless" or not. Their shitty DE is useless.

Just use another. This doesn't require SSD.

[ssokolow]

So, you're OK with crazy-styled buttons within browser's client area, buttons you have to push all the time, but browser's tab and close-button from a header must be correctly styled and same way as close button from another windows? Looks more like you're just rationalising.

I prefer a clear separation between my window manager and my content, regardless of whether the window manager is an X11 window manager, a Wayland compositor, or a web browser. Heck, the whole reason I'm looking forward to Wayland as implemented by KDE is that SSD is a natural extension of the claimed goal of Wayland to deny individual applications the ability to meddle with the desktop as a whole.

(eg. I'm tired of writing KWin Window Rules to overrule applications which act like three-year-olds with markers and a nice clean wall. Likewise, once I've upgraded off Kubuntu 14.04 LTS, I'm looking forward to using Firejail and/or Flatpak to do the same for GOG.com and Humble Bundle games that want to scribble all over my nice clean $HOME without so much as a "by your leave".)

It's similar to how I can't stand the Windows approach of every damn application having its own update manager, with some of them designed around "opt out of updates" rather than "prompt to update".

Do you really want to get into this kind of discussion with someone who does the following (and more)?

• Ripped out his desktop's GUI update notifier and wrote his own when the hidden option to disable "nag to restart to update kernel once a day" was removed.
• Configures his browser so that media autoplay defaults to disabled.
• Installs a browser extension to toggle page animation and leaves it set to disabled most of the time
• Uses uMatrix in a JavaScript-whitelisting configuration and only enables it for sites which actually need JavaScript to be functional.
• Writes his own Stylus userstyles to overrule annoying design decisions in individual websites he frequents. (eg. eBay)

Yes, and I've mentioned this reason. For me, that is just another toy, thing you'll never use. But there can be a middleground: one standard button to invoke WM menu.

Which every application has to implement in their custom titlebars. That's bass-ackwards and doesn't solve the problem of fighting to ensure that I don't get GNOME's idiotic "tons of padding everywhere" aesthetic in my titlebars too. (One of the things holding up my migration to a newer distro is research and testing to determine whether it's less hassle to maintain a gtk3-mushrooms PPA or switch to Archlinux.)

Please, stop pretending there are some kind of traditions and wisdom. Every f****ng time new version of windows/MacOS/KDE/GNOME/Android is coming out they are changing controls styles just to show that this is a new product.

It sounds like you share my opinion that they're idiots.

And not just changing look, they for example replaced standard and tabbed control with accordion and nobody actually mind. I think UX-specialists, like any others, tend to exaggerate importance of their job.

Just because people don't listen to us doesn't mean we're going to go along with every little bit of idiocy when we have the knowledge necessary to at least make our own computing environments comfortable.

[Weasel]

I don't see much difference between some online app like calculator or todo list and native one. If one can have its own look, why can't another?

Because the browser is the app. Everything that happens inside the browser is its own thing. Those "web apps" won't show up in the taskbar either.

That's like saying, you want a random game's interface to be the same as any other game, or else let's just give up on a common theme completely anywhere else. Seriously?

I'm not a big fan of all these skins, but why fight losing battle for a principle, which worth nothing?

Nah, only edgy apps use their own themes when it's not even needed. They want to be the cool kids but end up just showing how retarded they are (e.g. Chrome).

[Khrundel]

I prefer a clear separation between my window manager and my content, regardless of whether the window manager is an X11 window manager, a Wayland compositor, or a web browser.

Wait a minute. You need SSD to have some standard window headers and borders and you don't care if window content will follow same theme. Right? And now you're telling that you want these headers to visually separate SSD from window content. Right? Then GNOME's CSD is exactly what you want: you will clearly see everything as it is: titlebar will look like part of window's client space because it is a part of window's client space, no confuse anymore.

Heck, the whole reason I'm looking forward to Wayland as implemented by KDE is that SSD is a natural extension of the claimed goal of Wayland to deny individual applications the ability to meddle with the desktop as a whole.

Well... no. Claimed goal of Wayland is an isolation. That mean every app has access to it's window and only to it's window, no more funny "extensions" which add current time to active window's header, for example.
Another Wayland goal is to start from scratch and get rid of all stupid decisions, made long ago. That why everybody hates Wayland: it doesn't bring some new features, it mostly removes old and suggests to reimplement them, which isn't always possible. One of these features, as GNOME team thinks, is SSD. Returning SSDs is a sloppy road, if you're adding suboptimal extension just to draw fancy headers and add some buttons to them, why plugin authors can't? Why not add an ability to draw native looking buttons for those, who want to follow user's theme? That will transform Wayland to X12 in the long run.

Do you really want to get into this kind of discussion with someone who does the following (and more)?

Well, you unconventional desires, but not beyond redemption
I hope some day you'll decide you have enough of this and will stop wasting your time.