KDE With Theoretical Client-Side Decorations, Windows 10 Influence

[johnc]

I'm still looking for a WM/DE that allows me to resize windows without going on a pixel hunt. With easy I mean having at least 4 pixels hotspot *inside* the window frame (like Windows has had since 3.11).

Yeah, really. But you have to understand that when you say stuff like this the average DE designer is going to look at you like you have a third arm growing out of your forehead. "Re... Re-size?? You mean... you don't run every 'app' in full-screen mode on a 1024x768 laptop?"

[zanny]

I'm fine with client side decorations unless we end up with applications that look like this:

Applications already do this. Steam natively uses its own decoration regardless of WM.

I think it requires hacks to bypass window managers in some way, though.

I'd like to see CSD as an option, in the same way applications can support dock actions via some negotiation API (maybe you have to approve Windows hiding their own Kwin frame) so that applications could conserve screen space by removing the need for a title bar.

I'd also like to see full menus in the title bar, KDE already has appmenu-qt to put it in the title bar as a button, but I'd like to see the whole menu embedded like in Ubuntu as an option.

Anything to help take advantage of screen real estate other desktops are utilizing but KDE just is not taking advantage of. And for a desktop that has historically loved stuffing as much detail into an area as possible, it seems like an oversight.

[Baconmon]

I hate windows..

[Remdul]

@gens:

I do know there's a shortcut key for this, but 1) this requires unnecessary extra user action (keyboard), and 2) most users simply don't know this. Especially those coming from Windows, or your average aunt/grandma/parent. Or kids growing up with Android or Win8 (ghasp!), where everything is full-screen and completely lacks the concept of resizability, let alone shortcuts.

And the keyboard shortcut is *not* a solution, it is a merely workaround for this (unnecessary) problem. Window resizing has always been there in most Linux DEs, it was just never made user friendly (for reasons unclear to me).

If you need a manual/reference for *any* GUI, then the GUI is failing its purpose. A GUI is supposed to *be* a guide to an application's total functionality ('window resizing' here). Keyboard shortcuts, in this case, fail the 'discoverability' rule of UI design, because you have to know they exist before you can look for them.

And note that you've had to look it up, and that it varies per DE/WM.

(Also, I'm pretty sure the keyboard shortcuts were historically intended for window manipulation on machines without a pointing device.)

@droste:

Thanks, I should try a recent KDE version again, perhaps it has improved (or my troubles were caused by some non-standard theme or something like that).

[ssokolow]

I never understood the hate towards client side decorations. The applications look so good with it and there's no vertical space to waste. I've been using chrome without the top bar for ages. I've always preferred having just one bar with the window buttons and all the tab on the left than have a one extra bar with just 3 buttons wasting space.

Also those mockups look absolutely gorgeus

I think it's a mix of the following:

First, too much bad experience with the Windows implementation of CSD where, if a Window is chugging badly, that impairs your ability to drag or minimize it because the chugging affects its ability to manage input on the decorations.

I used to hate CSD for this reason but a GNOME dev has reassured me that this can be solved by designing the API such that the client draws everything, but the compositor only delegates input for regions explicitly carved out for client-side content. (eg. clicks on the titlebar would still be handled directly by the WM unless they're within a region that's had something like delegate_input(x, y, shape_mask) called on it.

Second, too many people remember the bad old days when it was almost impossible to find Qt and GTK+ themes which match. It's been argued that this could be solved by having a common "draw windeco" library all toolkits implement, but I'm still wary about this, given how commonly I still see closed-source apps botching the future-proofing of their dependencies or badly reimplementing UI toolkit stuff.

It's bad enough that supposedly fixed versions of GTK+ 3.x still show both server- and client-side titlebars on me sometimes, resulting in a doubled menu bar.

Finally, many people with a Human-Computer Interaction background (myself included) look at how CSD is being used and see it as just another way that people like GNOME devs are throwing out decades of HCI research in the name of bling.

For example, I think action buttons in the titlebar is a horrendously ugly and stupid idea. There's a complex mixture of reasons that they're in the bottom-right corner of the window. (It boils down to "a good UI reads like a page, from top to bottom and left to right") This is similar to how, while I'm not a big fan of OSX, MacOS 8 and 9 still have a surprising appeal to me because of how much work they put into professional HCI tuning.

[carewolf]

Applications already do this. Steam natively uses its own decoration regardless of WM.

I think it requires hacks to bypass window managers in some way, though.

It is not really a hack. It is a window manager hint, telling the window manager not to give it a window decoration. Many windows do this. Tooltips for instance are top-level windows without decorations.

[sunweb]

I hate that flat crap, hate CSD that WILL bring inconsistency to the looks(and Wayland solving problem with freezed programms is untested and unproven), I hate the idea of putting widgets inside launcher. KDE made even GTK programms look consistent but with CSD it won't. So why the F there is even a thought to change that?
WTF are you smoking, are you here to destroy KDE, are you working for MS?

[Creak]

Window resizing has always been there in most Linux DEs, it was just never made user friendly (for reasons unclear to me).

Apparently guys running KDE are telling you window resizing works fine. And, while I know what you're talking about, I don't have this problem in GNOME anymore since the release of GNOME 3... a long time ago.

[caligula]

@gens:

I do know there's a shortcut key for this, but 1) this requires unnecessary extra user action (keyboard), and 2) most users simply don't know this. Especially those coming from Windows, or your average aunt/grandma/parent. Or kids growing up with Android or Win8 (ghasp!), where everything is full-screen and completely lacks the concept of resizability, let alone shortcuts.

And the keyboard shortcut is *not* a solution, it is a merely workaround for this (unnecessary) problem. Window resizing has always been there in most Linux DEs, it was just never made user friendly (for reasons unclear to me).

If you need a manual/reference for *any* GUI, then the GUI is failing its purpose. A GUI is supposed to *be* a guide to an application's total functionality ('window resizing' here). Keyboard shortcuts, in this case, fail the 'discoverability' rule of UI design, because you have to know they exist before you can look for them.

And note that you've had to look it up, and that it varies per DE/WM.

(Also, I'm pretty sure the keyboard shortcuts were historically intended for window manipulation on machines without a pointing device.)

@droste:

Thanks, I should try a recent KDE version again, perhaps it has improved (or my troubles were caused by some non-standard theme or something like that).

You're confused. The keyboard shortcut for resizing is the correct way to do it. Average user wants fullscreen apps so the resize icons should be hidden to avoid confusion. Average user only needs minimize / maximize. For power users there's the shortcut. Everyone (power users) has known the shortcut. Maybe you're happier with a touch interface?

[molecule-eye]

Is it currently possible to resize windows with ease in KDE? I'm still looking for a WM/DE that allows me to resize windows without going on a pixel hunt. With easy I mean having at least 4 pixels hotspot *inside* the window frame (like Windows has had since 3.11)

In KDE you can resize by grabbing window borders, and you can set window borders to be VERY thick. Even with no window borders, there is a large triangle in the right bottom of window corners to enable resizing, and even a small pixel area you can grab anywhere the border should be. Even better, I bind resizing to a shortcut key so that you can click ANYWHERE in the window (while holding the shortcut key) and start resizing.

I just switched to Gnome 3 today though, to give a real spin for a couple of weeks (since I was horrified at where Plasma 5 is and is going). Grab areas for resizing are decent.