The idea is actually explained in the mockup sketch, but before reading it, tell me what you think.

Would this work for average users? (not "technically". Implementation is my problem
Would this (partially, at least) address the recent interest in CSD?



(Yes: vertical text is suboptimal. Yes: there'd be better space in the lower left of the particular window.)

luebking,

I don't know about everyone else (and sorry for being negative) but IMHumbleO, i'd prefer not to see CSDs in KDE.

One of the things that turned me away from Windows & Gnome (and one thing that i hate about Android) is lack of consistency in the 'workflow' in applications. Compared to them KDE is almost like 'stop all the attempts at trying new things with the UI & just do the basics, and do them well', the desktop we've got is straight forward, familiar and works really well - why change it?!? Personally I think that KDE would possibly do well to perfect this 'do the basics well' approach & let all the other OSs do their own thing.

At the moment KDE for me is almost a refuge from all the nonsense that other OS's are trying out. A good example is my Android phone, most of the apps by Google themselves use are pretty consistent in how they work so you've got a good idea what to do to perform a certain action, but move away from Google's own apps and the workflow in the third party apps is horribly inconsistent - it's like the designers of those apps have gone power crazy being able to do anything that they want with the UI. I'm not old & stuck in my ways by any means but in contrast to the other OSs, i like the fact that KDE has a fairly consistent UI.

I'd prefer not to have CSD's at all - but if they were done i'd like there to be strict controls on what layout each application used in their titlebar but (and correct me if i'm wrong), we have no control over that but we do have control over the SSD decorations that we've got now.

In my perfect world CSD would have never been used by anyone. If no one else would use CSD I would say stay with the traditional concept of SSD. The window decoration is not waste of space at all, it is a tab area for me and can hold a lot of information too.
But the world is not perfect and not consistent at all, so I think it does no harm if KDE invented DWD, since all the others are brewing their own solution anyway. It kinda destroys one of the core strengths of Qt: natively looking applications across DEs/platforms. Imho if the application developers focused on getting things perfect within the space they have, everything would be fine. Tampering with window decoration too does not improve the quality of applications at all imho and that effort would be more sensibly invested in improving the applications themselves.
I do not think Gnome people will implement support of DWD or anyone else in the proprietary world, so this would only benefit users of Plasma/Kwin, which is kind of sad.
Since all the other camps however have done much worse already, I think its okay to invent DWD to benefit Plasma users.

please notice:

this is NOT CSD NOR DWD

The idea is to simply shrink the titlebar (we don't need visible borders for resizing anyway) to a required minimum box and (starting at some default position) allow the user to position it freely on the clients edges.

The question would be whether this could address some interests of the CSD promoters.

luebking wrote:please notice:

this is NOT CSD NOR DWD

The idea is to simply shrink the titlebar (we don't need visible borders for resizing anyway) to a required minimum box and (starting at some default position) allow the user to position it freely on the clients edges.

The question would be whether this could address some interests of the CSD promoters.

If I understand the idea right, this has nothing to do with the applications implementation? It would be completely implemented in kwin right?
Yes, I think that feature could be really useful. Sorry for the misunderstanding.

kdeuserk wrote:If I understand the idea right, this has nothing to do with the applications implementation? It would be completely implemented in kwin right?

Yupp, it's "just another deco approach" - a bit like BeOS.
Just that I do not want to hear "I'm not interested in CSD anyway and since decos are plugins - go for it!"
I'd like to know from ppl. who'd prefer CSD whether this could talk them out of CSD.

Whereas kver's mockups are pretty nice and slick, the idea of DWD (for what stands the first D?) goes too far in your example, IMHO. For instance, I don't know happens when I click on the gear symbol. You could add a caption as it is required for toolbars, of course. But then you actually move the toolbar to the (smaller) title area. I'd say the approach works only for applications with limited functionality, like music players ("simple" in HIG terminology), but not for complex applications.

BTW: How does the DWD/LCSD work in case of WQXGA, 4K or the like? I mean, the title bar needs to get scaled up/down properly.

Again: this is NOT DWD related.

The black box is a plain good old server side window decoration, the rest is the client.
The "difference" is that the decoration is not (necessarily) outside the client, but can be positioned on the edges (inside and outside) by the user.
Starting by a hopefully untaken position (eg. top right edge)

In theory, such deco could be written right now (for KDE4 on X11, if you pelase), but I'd prefer to wait until KDecoration2 API has settled

---
"D" supposingly means "Dynamic", i'd rather use "E" for "extendable".
It will probably require more coding efforts than kver may think (because you need to bind the GUI asynchronously in the client and care to not flood the bus from either side - looking at the sliders here, but that's out of scope atm) and of course can only support a very limited set of default widgets (also since each and every decoration plugin will have to implement this GUI extension)

It seems to me your mockup does cover only one advantage of CSD/DWD : optimisation of vertical space.
However, I can see two advantages in the current KWin window decorator which DWD also have:

• Consistency is preserved: Window controls are place in the same position for every window, and all of them have their icon displayed in the title bar.
• Configurability: KWin allows you to place your window controls where you want, to add a "keep on top" button, to remove the minimize button, etc... DWD doesn't change that. With your mockup, you would have to place it near the others.

Besides, I don't understand very well how it would work. How can you tell that there are no useful controls under the area that you reserved for window controls? If you can't, the only solution would be to allow the user to move it on the side, assuming there is a side where it is not bothering. How would this be implemented in practice?

I agree with you that DWD requires a lot of coding, might not be as performant due to dBus calls, and will be limited, but if designers really want to be widgets in the titlebar, then I think this is the best solution to do that.

There'd be no limitations to buttons/order implied - the titlebar is only shorter (as for direction changes on vertical titlebars - that's a topic of its own

You'd be able and probably at times have to move the titlebar. By MMB, pressing Ctrl, having a special butto/area, ...

luebking.

One thing that i DO prefer about your idea compared to DWD or CSD is that in those, you've got controls added into the area that used to be reserved for the titlebar. In your idea you've still got a well defined 'title bar' area that's got the usual controls in it (close, minimize & maximize) with no other controls added in there - it's just a title bar whose size & shape has changed a bit - that seems a bit more straightforward than DWD or CSD where the title bars change from app to app.

Don't get me wrong, I still think doing a CSD/DWD thing's not where I personally would like to see KDE going, but i would give your idea a try if it happened.