When the first CSD “what if” was made in the KDE community forums it became the catalyst that got me in touch with some of the fine developers who really do make KDE happen, from them and members of the VDG I was educated on a new method of decorating windows with clean yet powerful widgets, and I have the privilege of presenting the idea we have worked and iterated on for some weeks now today;

Foreword

Client-Side Decorations (CSD) and Server-Side Decorations (SSD) are two methods for displaying the frames around our windows; and as history gets written it would be noted that KDE would back SSD, and Gnome would embrace CSD.

As a primer for those uninformed about what these two things are; lets begin by saying the window manager is the “server” and the applications are “clients”. “Server side decorations”, make the display server or window manager responsible for drawing the frame including window controls and title of the window. “Client side decorations” make the application is responsible for drawing its own frame. While the difference is subtle, the impact is notable; It historically determined whether or not applications could draw buttons or other widgets in their own windows, or even forego window frames entirely; usually saving a great deal of space in the process. But once an application is responsible for drawing its own frame, all sorts of naughty things can happen, such as a crashed application becoming immovable or unclosable – without opening task managers or using cryptic hotkeys. If programs don’t do the highest quality job drawing their decorations, it causes problems.

Because of those points, SSDs are traditionally considered inflexible and wasteful of space, while CSDs are considered potentially unstable and unpredictable in certain cases, but very flexible in general. KDE developers like Martin Gräßlin, and many other KDE contributors have given this topic serious thought because there are serious pros and cons on either side, and made the decision that CSDs have too many downsides they want to avoid.

Introducing DWD; the next generation of SSD

The VDG has been tasked and trusted by very intelligent folks to conceptualise an evolution of SSDs; internally we’ve been calling it Dynamic Window Decorations or “DWD” for short, to avoid confusion. And it has us excited.

Before I continue, a disclaimer:

This is still deep, deep in the conceptual phase and we don’t know *if* it will be implemented, when it would be implemented, how it would be implemented, or when it would be adopted. There’s a large number of ifs, and we don’t have specifics. One thing we will say is that currently, this is the idea with the most developer interest;

Also, we are actively seeking community feedback on the DWD concept, use-cases which might be desired, and developer feedback. I’m sure we’d also want feedback from other projects interested in the DWD concept.

Lastly, there’s many examples in this post; many developers are probably finding out about this concept the same time as you – please don’t inundate them with questions;  we don’t know if this concept will even be implemented. KDE developers are extremely busy with many fantastic features, so please respect their inboxes.

Thank you.

So, what is DWD?

DWD can be boiled down to a core protocol where an application would broadcast a list of widget specifications, at which point other parts of the system (“DWD Consoles”) could take the specified widgets structure, generate the UI, and display native widgets where desired. Using this method, DWDs try to strike a balance between SSDs and CSDs, allowing application developers to be more flexible inside the window decoration while also addressing the need of a window manager to remain in control to avoid the downsides of CSDs.

Indeed, DWDs would be themeable like traditional decorations, fully supporting transparency effects.
Indeed, DWDs would be themeable like traditional decorations, fully supporting transparency effects.

It’s important to note that the application is not responsible for drawing the widgets, only specifying what widgets it wants drawn. An application might say “I have a button, this is its text, and when its clicked I want it to send a signal back to me”. The application would have no part in the rendering of the widget.

What could DWD do for you?

DWD is more than being able to embed some widgets into a window border – that’s the main benefit and design goal, but we quickly realised it can go a lot further since the window manager could also relay these requests to other parts of the system; enabling them to become “DWD Consoles” and display widgets outside the window entirely;

  • Plasma could display widgets directly on a panel, below window thumbnails, or even directly on the desktop itself, controlling windows without even opening them. Exporting windows controls to a plasma panel may allow some applications to run completely  chromeless.
  • A media player might export its most prominent controls, and you could use them in the task-manager window preview without ever restoring the window. (thought in some scenarios it’s also possible with MPRIS)
  • Tools like the amazing KDE Connect could receive requests for controls and embed them on your phone. You could conceivably open your phone – in another room – and tell Muon to do an update and watch the progress from your phone.
  • Finally, raw console. Not so much for usage as much as it would be used for testing the protocol in a bare-metal way.
DWDs could be exported to panels, window decorations, or potentially even phones.
DWDs could be exported to panels, window decorations, or potentially even phones.

What would DWD look like?

DWD in decorations would look remarkably like CSDs, but more consistent. Applications would not have the ability to say “I want my decos on the bottom”, or “I want my window frame to be pink and furry”, or “I want my window to be a trapezoid”. DWD applications could, however, provide a stripped-down version of the standard colour palette used by KDE which the DWD Receiver could optionally use, which the user could still optionally disable.

What is important to notice, however, is that as opposed to CSD, the window decorator remains in full control. If an applications asks the decorator to use a special color palette and the user doesn’t want that, the window decorator can decline the request and keep all applications visually consistent.

If you were the type of person who has a theme with their window controls on the bottom, you can rock bottom-window DWDs! Do you like your minimise button on the left, and your close button on the right? DWD can fit in the middle. A core goal is the acknowledgement that users know what’s best for themselves. You should be able to configure what you like, and have your preferences enforced by the system.

DWDs could export most - if not all - chrome in simple applications.
DWDs could export most – if not all – chrome in simple applications.

If a computer doesn’t have DWD – or you disable DWD, then DWD would simply fall back to drawing widgets inside the traditional application area as usual. So if you use Gnome, XFCE, Windows, or Ratpoison, DWD won’t break other environments. KDE apps would look and run almost exactly the same as they do now; when they open they would quickly negotiate with the DWD server to determine if they should hide some widgets from the content of the window and have the server render them in the DWD instead, always showing the widgets in the traditional content area if no DWD support was detected.

In addition, applications such as Mozilla Firefox could use plugins to export their tab data and hide native tabs – giving non-standard applications full DWD support. Since DWD would be standardised, any plugins of this manner would only need to be updated to support the application – and would work wherever DWDs are supported.

Distributions could potentially brand CSDs knowing they would not be violated by applications.
Distributions could potentially brand DWDs knowing they would not be violated by applications.

How might DWD work?

DWD is a protocol based on applications exporting the structure of a small set of widgets, along with a menu, and metadata such as colour schemes and technical info in a client<->server<->console relationship. This would be done in an environment independent manner, so DWD could function on any environment that wants to implement the protocol.

The specification would limit applications to exporting from a set of predefined widgets, and the control of how those widgets are used is entirely up to whatever is drawing those widgets. The protocol would be kept simple, clean, and goal-oriented, with less focus on specific widgets (“I want a slider”) and more focus on actions (“I want a range”). Applications could not invent new widgets, but new widgets and goals might be added to the specification later as the demand is noted.

Many services could accept DWD controls, and act as DWD consoles; the window manager could display CSD-like controls, Plasma could embed controls in a number of places, and KDE connect could receive content, too.  DWD would not be a replacement for protocols like MPRIS, but for many applications DWD would help broadcast a wider range of controls to outside sources than normally feasible.

The two main componented of DWDs; the control menu, and the console client (here shown as a window decoration)
The two main componented of DWDs; the control menu, and the console client (here shown as a window decoration)

As the widgets are drawn by the ‘consoles’, the window manager can handle applications that are stuck as it does now, allowing the various consoles to much more gracefully disable them until the application becomes responsive or is forced closed; so none of the downsides of CSD crash-cases impact DWDs. The primary goal of DWD is for Dynamic Windows Decorations, and it should always be the first design goal, but DWD opens many other possibilities.

DWDs in various states and configurations. The second example illustrates DWDs in enviornments without DWD support.
DWDs in various states and configurations. The second example illustrates DWDs in environments without DWD support. Window decorations could easily offer different modes to better accommodate screens; Example 3 is a compact variant. Window decorations could also side-load or bottom-load decorations on the window – it’s up to the user.

Where can I learn more?

I’m sure there will be several developers reigning hellfire in on the various mistakes this post probably has – so the comments section will probably become a good place. But I’d recommend avoiding flooding developers with DWD questions; you will likely see DWD posts come out on aggregators or social circles, and until we have a firm grasp of how this technology might form – we request your patience. Smart people with more influence will likely help change these designs dramatically for the better if they go forward.

I will be posting more in-depth designs and work on individual components of this DWD concept, and refinement will happen as feedback rolls in. I, personally, will not post any more technical details on how DWD may work – I’m not qualified to go deeper on this subject, and again, smarter people will figure it out better than my conclusions; I’ll continue posting designs and concepts for DWD applications as a mini-series in the coming week, with more focus on individual DWD elements and application.

And again;

This is still deep, deep in the conceptual phase and we don’t know *if* it will be implemented, when it would be implemented, how it would be implemented, or when it would be adopted. There’s a large number of ifs, and we don’t have specifics. One thing we will say is that currently, this is the idea with the most developer interest.

Also, we are actively seeking community feedback on the DWD concept, use-cases which might be desired, and developer feedback. I’m sure we’d also want feedback from other projects interested in the DWD concept.

Lastly, there’s many examples in this post; many developers are probably finding out about this concept the same time as you – please don’t inundate them with questions, as, again, we don’t know if this concept will even be implemented. KDE developers are extremely busy with many fantastic features, so please respect their inboxes.

Thank you.

Last, but not least;

I’d like to give my sincerest gratitude to the KDE community for the support of my initial PlanetKDE posts, and especially to the excellent KDE VDG group whom I’ve had the privilege to work with. They absolutely define great community. I’m so excited to have gotten to bring the earliest VDG DWD concepts to the community, and the Visual Design Group was simply amazing in making it happen, so thank you!

Advertisements

75 thoughts on “Presenting DWD, a Candidate for KDE Window Decorations

  1. >such as a crashed application becoming immovable or unclosable

    This is FUD, GNOME use CSD and when an application is broken, clicking the close button from headerbar show “force quit” dialog.

    Like

  2. This is a bad idea. You are copying Gnome, or at the very least some one else in doing this. If you want to make applications more mobile, or touch friendly then make adaptive UI, not one crappy interface for both.

    Like

  3. Jep, that looks really nice – beautiful and functional… But … WTF?! STOP THAT!! o_O
    You read right: Your “invention” is awful – but it looks really cute 🙂 …

    As a user I can not mind about _how _ and _where_ I have to click this window to achive !
    If I can not move a window by it’s titlebar, i’m scewed, because it breaks my workflow. Where shall I drag the window ? Do you really want me to snipe for the last unused pixels??

    My computer and it’s OS is only a tool, and if I can’t achive what I want to at the moment ( because strange things happen) I’ll get frustrated… [and then I’ll blame you 😉
    Some UI-elements have to stay _exactly_ the same in the OS. Every time sometings different, the useractions will do “friendly fire”. I can say that not only because beeing haunted by bad UI’s, but because I’m programming UI-applications as well ( tools for students and collegues) and even my “skilled users” are raging, if buttons placed unexpeced. In those cases I like to say: “If you do something different without doing it better, you better do something different” (Wenn du Etwas anders machst, ohne es besser zu machen, solltest du besser etwas Anderes machen)

    For a good worflow a nice titlebar is essential. The “three magic buttons” and the program’s Icon too.

    That’s only a convention, derived from M$ – in a different OS we can do different things ( as long as we don’t scare away the M$-runaway-users 😛 ).
    But what ever we do, it has to be a consistent UI, with a consistent usage – even if it kills us!
    We wanna round windows? Ok – but the handle has to be at the same spot EVERY TIME!

    As a “Pecae proposal”:
    From the developers point of view, it would be the best, if the Programm don’t paint into the titlebar itself (because it is _that_ critical), but it exposes a container/plugin. This container has a certain max hight and max lenght (defined by the OS), so it can be drawn into the titlebar, footbar, sidebar… or where ever… At initialising time, the composer gets the message, that there exists such container, it’s lengt (in px) and callback adress. That container can be drawn, if the user clicks the “small mode”-button in the titlebar (or alike).
    How the container internals behave, and what there will be displayed, stays under the developers control – but not how, where and when it will be placed. Only in the time, the composer adds it into the bar, the container will be executed, able to clean the titlebar at any time (if the user decides so, or the container hung up… ).

    This way, the developer don’t has to mind about OS-UI behavior (!!) and only has to prepare a plugin for a well definded API in the “give-it-to-me-and-I-do-somethimg-if-I-am-feeling-lucky”-manner.
    –>Nice tradeoff: Those plugins can be used in the PDA-style as well, could be placed in the taskbar button while the window is minimized, could be “lend” to other programms like M$-OLE-Containers, or simply stand-alone (for code recycling only).

    I know, you only want to make things look awesomely beautiful, and develop crasy stuff… :]
    … but please don’t scew the things, we depend on. Otherwhise my last resort will be a DIN-norm for windows! 😄

    Like

  4. If you have to instruct the user where the button, to click to install updates, then you’re doing something wrong. Otherwise, there are some “nice” looking designs here. Good use of colours without looking stupid and garish.

    Like

  5. NONONONONONONONONONONONONO

    I’ve been shaking my head the whole time while reading this. CSD-Style decorations (in lack of a better name) are awesome, this however is not. What this is asking for is a completely new way of designing user interfaces. Which is not inherently bad, I’ve thought about it too and have come to the conclusion that it’s not even that bad of an idea: Just give the user the freedom and let the system provide the design. Including layout. This could even go as far as the application not even requiring widgets, but only functions and letting the system design the UI. This is not a bad approach (i think at least) but not only a MASSIVE amount of work, but also crippling and probably pissing off a lot of developers who want to make their own design. Again, MAYBE a nice approach. But this is not how software works right now. How it works is basically the system providing the application with lowest level user input (cursor location, keys pressed) and the application giving the system back a whole bunch of pixels that define the look and information it contains. Only few programmers write their software that way; most use a graphic toolkit (GTK, QT …) which just happens to looks the same for every application using it and accept styling from the system. What you’re proposing is what I’ve described above. Not inherently bad, but really damn inconsistent!

    By the way, I’m sorry for my incredibly bad writing style at the moment but right now I really just want to get all this stuff out of my head.

    So, where were we? Right. If you decide for one concept, stick to it! Virtually the whole world of operating systems has chosen giving the application control over its looks and only providing styling suggestions. It gets it’s nice little rectangle and inside it can do whatever it wants.

    Now, let me propose a new, MUCH SIMPLER concept right here. It may be flawed but let me give you the core idea in one sentence:

    Integrate the system into the application.

    What I mean by that is that you should give the application the freedom to draw its own widgets (kind of gnome-style), but still leave the controls in the hands of the system to avoid abuse. After all, what matters is the content the application provides, not a thick bar at the top that provides nothing more than 3(!!!!!!!!) buttons and maybe the name of the application. Do we really need that much space for so little function? Of course I didn’t mention the drag area in here but everything /not/ a control could theoretically be one. A quick search on dribbble reveals what designers would do if they could: Fuck the title bar!
    What the vast majority does is going chromeless (extending their applications to all edges of the window) and just putting the buttons in the corner. Not only does this look absolutely gorgeous (allows consistent look of the app), but it is also a MUCH better use of space than having those three buttons on the top. It’s also way less complicated than your approach. Also, the essential controls aren’t always in the title bar. Would you EVER be comfortable using a video player with the controls at the top? I’m not so sure if I would. Thinking about it this is also a great case example. What matters in a video player? The video. Not the controls. Not the cursor. No distractions. So why not apply the same thing to the window? Let’s say if the application responds to a ping every second or so it may enter “immersive mode” (borrowed from android) and display nothing but the video. Upon moving the mouse the [window-]controls are faded in again. Just something I thought of when watching a video and simultaneously trying to work on something else (not a good idea, i know, but this comment is not about my productivity :p): Don’t you think it’d be awesome to take the window, resize it, move it to the edge of your screen, right-clicking on the window-controls and selecting “keep on top” (which could be improved by the way by implementing “priority layers” which could be accessed by right-clicking that menu item) and just have it there playing without any title bar you don’t want to see anyway almost as big as your video wasting your precious space? I absolutely think it would.
    Almost noone on dribbble uses stock window decorations and I’m pretty sure why. Either because they’re deemed ugly, too big or just unneccessary. A music widget for example that displays the cover of the [song/album] on the top and various controls on the bottom would probably look horrible with a title bar (
    https://dribbble.com/shots/854898-Miniplayer
    https://dribbble.com/shots/1002161-Music-Player
    https://dribbble.com/shots/1293954-Music-Player
    https://dribbble.com/shots/1566910-Spotify-Widget
    https://dribbble.com/shots/867419-Mini-Music-Player
    https://dribbble.com/shots/1094595-Music-widget-Inspiration-PSD-GIF
    https://dribbble.com/shots/1003467-Music-Player-Widget
    https://dribbble.com/shots/998953-Hurricane-Player
    is that enough? I think that’s enough. ).
    There are however in terms of design no problems at all integrating the functionality of window management into it. The buttons could still be displayed at the top and the cover could be a (bigger than usual (which i consider positive!)!) drag area.
    Now, this concept is somewhat related to the way microsoft windows (disgusting, i know) handles it, the app may request “titlebar-less-mode” and may now draw “into” the titlebar. It has to provide it’s own title, but the system controls are still where they belong. This seems to have proven to work very well as almost every major windows app makes use of this feature that I can think of on top of my head. To be fair, that is only Firefox, Chrome, M$ Office and Windows Explorer. But this feature is especially useful for tab-managed applications for which titles wouldn’t make any sense anyway as they change by the tab open and are displayed in the tab bar already, anyway.

    Holy shit, that just took me over an hour to write. Because I’m such a bad-ass and I really need to go to sleep (it’s 4AM already?!?!?), I’m not even going to attempt trying to structure this wreck of a post or even proof-read it.

    Still, If you have made it this far: I love you. Seriously, thank you for your effort of reading my almost unfiltered stream of thoughts and not running away screaming. Please let me hear from you. What do you think of it? If you want to help me make this into a full-fleged concept with illustrations and stuff, contact me! I might post something about it on my blog, but then again, I’m not able to structure stuff or get more than a few lines of text when writing carefully.

    Again, I’m pretty convinced of my idea. If you’re not, tell me why! Because at the moment I really don’t see any substantial flaws.

    This post feels so unfinished … but I think I have said everything I wanted to say. Again, thanks for your patience. Good night.

    Like

    1. For the most part you just described CSD; as soon as the application draws its own controls, the client is decorating itself. Once the client is drawing its own decorations the window manager can no longer provide consistent functionality, so either the client must provide duplicate functionality or do without it. Additionally, maddening amounts of complexity, exceptions, and hacks are needed for applications to operate ‘as expected’.

      The other route you have suggested is having the application able to draw over the window decoration; MS Windows actually cheats to accomplish this; instead of letting the application draw in the window frame, Windows actually just extends the frame styling ‘down’ into the application (their preferred method). MS can also wipe out frame compontents and push the application area ‘up’ a bit, but it requires the application to start drawing what are usually system buttons, almost completly going back to the CSD well.

      One thing I don’t think anybody would debate is that CSDs for individual applications can look good; but it’s just not a good idea once you take an entire systems’ worth of applications into account; once every application had a wacky design you’ll ultimately get a hodgepodge which you can’t rely on. Designers *love* to do crazy and beautiful designs, but to some extent we need to reel it in and keep things practical for users who require certian amount of reliability and stability, and CSDs just don’t offer that, no CSD system can offer consistent behaviour between systems. It’s why Chrome allows you to fall-back to SSDs, because CSDs can cause issues and limit functionality.

      DWD isn’t a new method for drawing the entire interface, it’s just a method for defining select widgets for drawing outside the system; you wouldn’t use this to build an application – just enhance existing ones. If an application really wants to be ‘special’ it can do so with CSD – it’s just a terrible idea, and the KDE devs aren’t interested in shipping solutions which will cause problems; they’d rather spend development effort for the applications looking to provide sane interfaces. You can still use CSDs and they aren’t going anywhere, but you aren’t going to get a CSD solution inside KDE frameworks – the developers have lectured people on why it won’t happen, and I’ve come to agree with them.

      Like

      1. Do not understand what you are saying about CSD. On GNOME, ALL applications are using headerbar and GTK widgets and so it’s more consistent than SSD. Only one theme, no more stupid window decoration theme.

        Like

  6. I am thinking that this has potential for letting applications using different toolkits share a consistent look and feel on the desktop, as well as allowing applications statically linking in DWD-aware toolkits to fit into the desktop (just thinking of VirtualBox’s statically linked “all Linux distributions” bundle, which statically links in a version of Qt and never quite looks right). If so then it is something I have been waiting for for a long time. Thank you for the work you have already put in, and I hope it comes to fruition!

    Like

  7. Good idea. Please implement it in a way, that the app comes without the top border, if it doesn’t use widgets. The minimize, maximize and close buttons can be placed in the top right corner of every app. This would save a lot of space on the screen.

    Like

  8. I had a very similar idea after GNOME came with it’s client side decorations and the problems that come with them. I love how the new GNOME apps look though. I personally think that this is the next step for application design, and I love how it simplifies a lot of basic operations in applications. GNOME started this, but KDE apparently gave it more thought and made DWD. I think this is the way to go, and you should coordinate with the GNOME project if you can possibly make a standard library out of this that can be used by both GNOME and KDE. A bit like the wayland/weston relationship.

    Now I have a little comment on how you could drag windows, because as I understand it now you have no limitations to the widgets that application developers can put in the window decorations. This makes it possible for them to add input grabbing widgets over the whole bar. Meaning that you won’t be able to grab a window and drag it around because some widget wants that mouse movement. Now you could possibly limit this problem by not allowing any input grabbing widgets in the primary control group. Because in your mock-ups these are the biggest, I expect every application with sane designers to have something similar. So if you disable input widgets on that part of the window decorations you have a huge part you can actually use to grab and drag the window. For instance with GNOME Web (epiphany) you have the URL edit box in that same region. When you click that it will make it an edit box where you can enter a new URL, but you can’t drag the window around when you want that, then you have to click somewhere else first. Of course usually when you click that you are probably going to change the URL before you are going to drag the window, but you get the idea I hope. So basically the primary control group should be a place where the application can put widgets that tell you something about the state of the application but you can’t edit or that they grab mouse input (eg. for sliders).
    This means that your current secondary control group would become primary because that just makes more sense to me.

    This got pretty long, thanks for reading 😛

    Like

  9. Looks great.

    Very original, and very beautiful. I can’t wait to see and use this.

    Just couple of ideas I got when I saw this:

    Really like Icon-only tabbed windows combination with DWD. Suggestion to give ability to make this icon-only tabbed windows hidden, and an icon to show them on click (icon placed where last tab is). maybe even on mouse hoover show list of all tabbed windows (as drop-down list with titles of applications, so if you have multiple applications of same type inside, that you can differentiate them).

    Also maybe consider if application does not have this DWD widgets defined, but it has menu bar, consider placing it’s menu bar inside primary or secondary control group (If that is possible), since there are applications that use menu bar a lot, and placing it inside several submenu does not really make it user-friendly. However, if you place menu bar inside DWD you directly save space, without making it harder for user to access menu bar.

    Maybe even (if possible) if application has toolbars allow placing them inside DWD.

    Maybe Control button can have DWD entry in every application with options what to show in DWD { “DWD mode (grayed out in case app does not have DWD defined)”, “Classic mode”, “Menu Bar mode (show menu bar in DWD)”, “toolbar mode (show toolbar icons inside DWD)” …. } how to act with tabbed windows {“show icon-only tabbed windows”, “hide tabbed windows” … }. This options can be saved and last mode used with certain application is used next time that app is started.

    But, all in all, as I said before – very original, and very beautiful.

    Regards,
    PP

    Like

    1. I like the idea of having the menubar become the primary DWD group on apps without DWDs defined; it would probably need to be the window manager emulating a DWD for these applications. KDE already has menubar export options, so I don’t imagine this would be a bridge too far.

      Like

    1. This would take a herculean re-engineering of how GNOME 3 technology works. I’m afraid they would require an existence proof and some good press on the success of implementation before considering such a big rewrite.

      Like

      1. I don’t know about “herculean re-engineering” – they’ve certainly put a lot of work into CSD in the past few years, but since that’s largely done through standard APIs, it may not be too difficult to port CSD-using apps to a DWD model.

        That said, I definitely agree with the second part of your post. Even in the KDE camp, this is still a purely speculative design, without even proof-of-concept code. I’m sure the Gnome developers and designers will have read this series of posts with interest, but there’s really nothing yet that would motivate them to drop their own efforts and throw support behind DWD. It’s just too early for that kind of thing… all we have so far is a bunch of mocked-up screenshots, and a lot of thinking.

        Like

    2. I personally would be interested in their feedback, but as Simon mentioned this is still purely conceptual. Though if this does take off, it would be good to have other developers weigh in early in the design process before any cement starts to harden. Especially if they point out methods of application integration – such as having their apps switch from CSDs to DWD in enviornments which support it. Then we can all have our cake and eat it to.

      But even KDE developers have yet to seriously weigh in, and Gnome is pretty far down their road – so I imagine they’ll be late to the party if they decide to join at all. But I’d love to be proven wrong.

      Like

  10. Please refrain from having two columns of icons next to eachother in the menu. There is an “All options” submenu where you listed that the orphaned elements can be placed, use it and don’t duplicate the elements.

    Like

  11. I see this idea being very useful even outside the SSD/CSD area. Allowing an application to advertise a set if widgets could open the doors to some interesting user experiences that are not being eplored at the moment.

    Liked by 1 person

    1. I keep running into ideas other people are having!

      One person mentioned DWD controls in lock screens. It never occured to me, but being able to have your locked computer do things like switch songs or display update progress? It’s elegant.

      Another person also suggested two things; letting non-gui applications register DWDs, and letting registered remote computers access those DWDs. His reason for this was freaking clever: administration. If you have dozens or hundreds of servers or office computers; DWDs could provide an easy alternative to managing those computers en masse. Something as simple as turning down the music on someones’ computer, or telling apache to restart from one place with no need for specific or cryptic administrator tools.

      Like

    1. They define what they want that control group to be. Theoretically, you could redefine it. There’s no code yet, so who knows if that’ll be possible, but one would imagine reasonably it would be.

      Like

  12. Looks really good, but the amount of effort, time and code that would be required to implement this is enormously higher than just implement CSD. CSD are simple, the code to implement it is simple and you have much more flexibility than a sort-of protocol to draw widget that would change change and die in a future release of KDE due to the too much high maintenance required. Maybe I’m exaggerating, but let’s not bloat our code and implement CSD as an option (by default) and always support SSD too. That would be awesome, because every users will have the choice, the code will be smaller, faster than a protocol because it’s directly the application talking to it’s widgets, and it will be easier to maintain. Even the code to support both of the mode would not be bigger than the code required to support both of DWD and SSD.

    Like

    1. Your right that this is more coding effort, but it also provides way more functionality than just CSD (think of the MPRIS-like functionality of the update manager, etc.). And ofc the goal has to be here to get other DE’s / toolkits on board.

      But also regarding just CSD, there is no way to get consistent decorations (I mean simple things like if the close button is a red “X” or grey “O”). So either you spent more work here, too (and form a cross-DE / toolkit interface) – OR you get the mess it is on MS Windows. And as a true DE fan you don’t realy want this or do you? 😉

      Like

      1. Yeah, I would not like to end up in the mess of windows CSD, but then again, in X11 nothing prevents you to do this mass, just look at steam, decoration buttons are barely usable and inconsistent. If KF5 provides the right tool to expose a well defined API and protocol, that would be great. If we are implementing this, we must be sure of what we do to not end up in a mess, so we must be really careful in that kind of thing.

        Like

      2. I’m sure this will use the cross-platform dbus to work, like how application menus do (they can be moved to a widget, button in titlebar, or fall back to being inside the application).

        Also, sometimes you need an existence proof – a reference implementation – before others will follow you.

        Like

        1. Indeed. And the fallback could be CSD if DWD is not available, that would prevent applications to suddenly change appearance. The ideal is that every KF5 application supports both three method to handle decoration, but that is an ideal. It may not be possible, but that would be the best.

          If you want pure CSD and keep the feature like the update manager buttons, nothing prevents the application from exposing buttons while drawing it’s own decorations.

          And again, we need a rock solid implementation and protocol specifications or else no one will bother using it. It’s a king of thing that MUST not end up in a mess or a bloat. I’m confident Martin is capable of, but again, time is alway a bummer when coming to great ideas.

          Like

    2. An SSD window is just a DWD window that has received no DWD control groups on the dbus message queue. A CSD (like Google Chrome and Steam are today) are just windows that hide the SSD controls by default (ALT + F3 to show the window manager menu).

      You wouldn’t make separate code paths for each if you have any idea how to create software.

      Like

    3. DWD is initially more complex, but it’s also centralised complexity and protocol driven and that’s an important pair of differences comapred to CSD. CSDs are done in two general ways; programs “go it alone” and do everything themselves, and there’s official libraries provided by toolkits which manage that complexity.

      For go-it-alone applications like Chrome or Steam the complexity of drawing and managing the window is completly on the applications. Bugs and issues caused by those applications are at the mercy of individual developers, and they can be dealing with issues across several enviornments. The applications are bigger, they have less chance of *any* sane integration, and benefits of the window managers (such as drop shadows or tabbing) are lost outright in most cases. I know Steam has several issues with thir CSD on KDE – and all too often I get headaches when a video plays and all mouse input is stolen by the damn thing. Plus, if a CSD has an ugly UI there’s nothing you can do about it – no system will make that app pretty.

      For applications using toolkit libraries, the complexity is on the toolkit, and the general trend we’ve seen from toolkits is that when they start using CSDs they say “screw you if you’re not using our toolkit – we do it for us!” It’s a bit harsh, but Windows CSDs are Windows only, Mac CSDs are Mac-only, and Gnome has honestly been uncooperative in this regard (from the conversations I’ve seen); Qt is about the only cross-platform toolkit which might try to co-operate, but that’s a huge amount of complexity to strive for, because we’d be flooded with enviornment-specific bugs and issues. Do you really want Qt or KDE developers tied up on Windows and Mac CSD bugs?

      With the protocol driven approach, the complexity is on the implementations and the protocol itself; and I’d imagine some core library would come out of it that would manage that complexity in a generic system-level way. It’s much easier to push a fix to a central library than it is to dozens of applications. When applications do use DWD there would of course need to be some DWD-specific code in the app, but if the protocol is kept simple on the app side it mimimises chances for breakage.

      Like

  13. Ken, you are an amazing designer with neat ideas! I really like your mockups. Dwd is certainly a lot better than csd. However personally I would be happier if simply everyone agreed in keeping window decorations. With KDE having DWD, Gnome having CSD, Windows having SSD etc. it will be hard to have portable applications that fit nicely everywhere (which is the huge benefit of using Qt). Apart from that: For me the window decorations are never wasted space: It is an area of tabs for me, that you can hide if not needed. If applications would work harder on delivering a beautiful interface in the space they have, it would certainly be more effecient and consistent imho. But I guess the world isn’t consistent anyway so your concept is right next to the traditional imho.

    Liked by 1 person

    1. Windows has a lot of CSDs and OSX has had the concept of blending titlebar with toolbar for a long time.
      I think the fat titlebar/toolbar concept is one that a lot of people have slowly been moving towards, just look at Google Chrome.

      I absolutely believe that standardizing on a sane implementation of it, for applications that want it (because not every app will use it when it’s here) is important.

      Liked by 1 person

    2. One thing I like about DWD is that’s it’s an extension of the SSD model; and because of that, it can fall-back gracefully to an SSD, which every modern GUI system supports. So DWD applications are still perfectly portable to Windows and Gnome with no loss; it would simply mean systems which don’t support DSD would behave the same way they do today. Plus, DWD isn’t limited to window managers; a desktop enviornment could stick to SSDs and still use DWDs for things like exporting controls to phones, enhanced lock screens, dock applets, or generic remote controls – and that could very easily be the first applications as the tech is tested.

      One thing I really do like is that DWD is not a ‘selfish’ design, and that other enviornments can enjoy DWD support too, assuming it takes off. I firmly beleive that this is one of those things which once the foundation is laid and initial hurdles are passed will be an asset to the whole ecosystem.

      About the biggest issue right now is manpower; Wayland is taking the majority of resources right now (and it should – it will improve all our lives), so there’s just not that many hands in the window managment world free and open to build an entirely new protocol into their systems. Two big paradigm shifts at once would be difficult, even if we did have a larger pool of developers. But I’m sure we can all agree that even though we don’t have the most developers, we have some of the best; and if/when they do get to it, they will do very well and be very thoughtful.

      Liked by 1 person

  14. It’s a really good initiative, I’m eager to have try it out. Meanwhile, please have a look at
    – Ars Technica’s Yosemite screenshots and review: http://arstechnica.com/apple/2014/10/os-x-10-10/12/#applications and
    – at Apple OSX Yosemite’s HIG here: https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/OSXHIGuidelines/WindowTitleBarToolbar.html#//apple_ref/doc/uid/20000957-CH39-SW1

    They basically have/had a very similar idea, maybe some of them can be an inspiration for you also.

    Like

  15. This looks really interesting. I am wondering if there will be ways to have applications not written with this concept to export data to display widgets, in a way similar to how dockmanager plugins expose information (as in Icon-Only Task Manager), or code say a python wrapper to increase the functionality of arbitrary apps? (for example make VLC show playback buttons and bars in the titlebar).

    I am also interested in if this would support smaller titlebars. I for example only use a 16-24 pixels tall titlebar. Would that be possible to use, even if it looks small?
    Other than that, it’s quite the interesting concept and I would love to play around with it. Can think of a number of fun widgets that could be doable, like grouping pidgin notifications in its titlebar or something. Fun!

    Like

  16. Reading your What-if series, I was a little disappointed that it was only looking at adapting existing solution with “KDE spirit” rather than identifying areas where others were doing better and looking for the best solution for the identified issues, which may not be the one that the other environment chose.

    I am very glad that your post on CSD triggered the work on DWD. It is indeed a very elegant way to proceed. And it keeps compatibility with other window managers, which is very important in my opinion. I hope other environments also go for this, it could become a FreeDesktop standard. Of course, a lot of work remains to be done, but it may be a good idea to get in touch with other DEs (I think about Unity in particular, with Unity 8 for desktop being in design phase) about that.

    Liked by 1 person

    1. I wanted to keep away from raw analysis because I don’t think it would have the same impact. It’s super easy to say “X does Y better”, but it can be easy to ignore and we fall into the trap of just telling ourselves that our ways are the best ways – especially if we don’t actually see how we ourselves would do using these other techniques.

      I think putting things in context is important, especially when they look as if they were on the cusp of ‘being real’; because then you ‘see’ what can be done, and it’s harder to dismiss. From there it has to be a real conversation on the values of other systems, because it has that context and you feel like “that could be your desktop”. People have to ask why that picture isn’t, couldn’t, or won’t be real.

      That being said, I didn’t trigger the conversation on DWD; the post on CSD more/less brought me in to that fold, and made me aware that it was a thing developers and the VDG were thinking of. When I found out the developrs wanted to see some form of proof-of-concept designs I practically jump-tackled the chance to do it.

      Like

  17. These are gorgeous though I do worry slightly about functionality. How do you move a window if everything in the title bar is interactive? How do you resize a window if there’s no distinct window corner?

    Just thinking out aloud, if I have a keyboard, I can hold Alt to do both of these and if I had a multitouch monitor, I could use two finger gestures… But I can’t see a good way for just a mouse.

    Like

    1. There’s a few things in the design in DWDs that’s going to keep functionality intact; this was meant as an introductory post, and actually skipped huge amounts of information from several drafts that have been written. I plan to post in the coming weeks on specific topics which were skipped.

      For window dragging, there’s a few things we’re doing. First, you’ll there’s about 20-30px of spacing between widgets; this is specifically to allow for drag area in suboptimal conditions. Also in the draft is the behaviour and drawing of widgets, and that their manipulations would be dictated by the console drawing the widgets. This means Kwin can spec widgets to contain more draggable surface than might normally be offered. Some widgets don’t really allow for this – like tabs or text inputs – but in situations where an app uses mostly undraggable widgets, that’s where the padding should hopefully kick in and provide reasonable surface area. There’s no reason spacing couldn’t be a user setting, either. Users might do something like extra padding on the top of DWD-enabled windows, or extra space on the sides of separators.

      Finally, if DWDs are not cutting it they could also be disabled, reverting back to the standard decorations we are using currently. DWDs could also probably be managed in window-specific rules, too.

      In terms of windows with no defined corners; that’s up to the window decoration. By default (though not illustrated here) KDE would probably continue easily ship with full frames if DWDs were implemented. For examples like the frameless movie player, that would be up to the user to customize the window to nothingness – so they’d know what they’re getting into if they did that. That example was more/less just illustrating the possibilities; for example, Plasma Active might have a field-day with that feature.

      Hope that helps!

      Like

      1. Very interesting idea.

        One issue not discussed is how to handle short titlebars which don’t provide enough widget space. When launched an application may be able to probe this and adjust itself accordingly, but it’s unlikely application designers are going to handle window resizes causing widgets to be lost.

        Like

        1. There’s a few options for that scenario, but I imagine it’ll be a combonation of resizing the primary widget group dynamically, and having a minimum width for windows – possibly based on the minimum widths of all the included widgets and spacing added together.

          If we were to dynamically cull widgets, it would be done in an automatic way; first the tertiary group would be removed, then the secondary group. I’m not a fan of this idea, as there’s a concept of “safety” built in to the spec, where “safe” consoles guarantee all the controls will be exposed. Something like a plasma window thumbnail would not be “safe” as it would only display the primary, and maybe the secondary, groups. But a window decoration should assume all cotnrols are important.

          Next, we could have it bump the various groups into multiple rows (in extreme situations); but I don’t like this as it defeats the entire space-saving aspect of the design.

          Lastly, we could scroll the widgets or hide the elements and offer a button to show them again. But I’m not a fan of any widgets going out of view.

          If this idea took off, an HIG would be put in place and one of the big things it would push is not cramming DWD consoles with a glut of buttons, which would be problematic. At the worst-case scenario, I would probably just add a second row, with secondary and tertiary buttons falling on the new row; and I would only do that if the screen itself could not physically fit the minimum width of the window. About the only reasonable scenario for that would be a standard screen with extremly large sizing settings, like somone with poor vision might require.

          Like

      2. For resizing, at least when compositing is enabled, can’t you do what MacOS does – allow resizing from the shadow? In MacOS, there’s a few pixels of the window’s shadow that function as a resize target, so while there is no visible frame, there is a part that you can drag to resize.

        Like

        1. I personally like this, and KDE already does it (at least in the oxygen deco with borderless frames); I imagine it would be up to the decorator and decoration. My own style preferences have leaked into these designs, but I’d still imagine frames would be standard issue for usability purposes.

          Like

    2. I would imagine it would work like the new Ubuntu feature of having menus in the titlebar. If you click, the menu opens, if you drag, the window moves. IE, buttons are only buttons if not dragged.

      Like

      1. This can be problematic. Typing this on a touchscreen computer with 275 DPI; “clicking” with a finger without any drag motion is quite difficult. Using a drag-start-threshold would solve this, but adds another parameter to configure somehow.

        Like

  18. Awesome concept and awesome looks indeed! Please, do whatever it takes to bring those window decorations (icons, buttons, etc.) to users. That’s the KDE desktop I’ve always dreamt of!

    Liked by 2 people

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s