Don’t know what DWDs are? Click the link below to find out!

https://kver.wordpress.com/2014/10/25/presenting-dwd-a-candidate-for-kde-window-decorations/

It seems about the right time to post some common questions and misconceptions about DWDs I’ve seen around the web, so here’s a general FAQ about DWDs; If I missed any questions about DWD, please post them!

Window decorations would be responsible for widgets. Here's 3 potential window decorations using DWDs.
Window decorations would be responsible for widgets. Here’s 3 potential window decorations using DWDs. Note that the decoration dictates style – and users dictate the decorations. Complete control of your personal preference.

DWDs are going to make my windows inconsistent and ugly! Application widgets might clash with my window decoration!

DWDs are not CSDs, and all theming and drawing is handled by the window manager and decoration. In addition, applications only export the structure of their widgets, they do not pre-draw or draw the widgets themselves. Applications would have little or no say in how their decorations look, just like traditional SSDs.

That being said, we don’t want DWDs to be absolutly rigid, we are looking at ‘safe’ ways applications can do basic branding on themselves in a reasonable manner, which decorations could potentially integrate without excessive effort. The main thing we are looking at is allowing applications to offer a colour pallet which decorations could use to tweak their appearance, but DWD ultimately would put the power in your hands and options would also be provided to disable unwanted hints and effects for more consistency. A primary sentiment with DWDs is that the user would be completely in control of all aspects DWDs would provide.

Will I lose my current customizations, or ability to customise? Will I lose the ability to customise my windows in the future?

No! DWDs will actually give you more options – at least in KDE.

The only change to your existing configuration might be the switch from standard SSDs to DWDs when the option is initially added (or deemed stable). If you wanted your current setup to reign supreme, you could simply disable DWD-based widgets, and your desktop would be remain identical to how it is today.

I want features like controls on my phone, or controls in the panel, but I don’t like widgets in window decorations. Can I have one but not the other?

Yes. Since DWD is just a protocol, we could potentially build DWDs to be enabled/disabled on a per-service basis. You disable it in kwin, but keep device integration, or vice-versa.

How will I move the window if everything is interactive?

There are a few things we can do to address this issue.

The first is by looking at individual widgets and checking to see if they could conceivably be dragged. For example, buttons could easily be considered draggable surface. Progress bars are a draggable surface. About the only things that can’t really be dragged (which we would include in the specification) are tabs, text inputs, and sliders. Sliders take very little vertical room, they are less of an issue.

Next, we’ll recommend decorations insert generous area of padding in parts of the frame, which would provide grabbable area to drag from. Of course, if you have something against padding and would rather drag a window by holding alt – I’m sure an ultra-compact theme will accommodate you.

Lastly, we’ll also look at how widgets are configured, and potentially we could offer alternate behaviours for widgets. If users didn’t care about the order/arrangement of their tabs, we could easily have an option to just make tabs another draggable surface (and disable rearranging). Sliders could have an option to require users specifically use the knob. Text inputs could be set to require focus before a drag->select can occur. There are many options.

Overall, we want to assume that at least one or two apps will “abuse” DWDs, so I’d want to build ‘safety’ on the decoration level.

DWDs are complicated / CSDs would be simpler.

For applications developers DWD should be similar in complexity to CSD but will have extended options available and additional features, while omitting APIs for complex styling. DWDs will not impose default structures or layouts, or make assumptions about your layouts. Overall, DWD should be roughly equal to CSD for applications developers; they’ll likely just have a different API focus.

On a system/library level CSDs may be simple when you look at them in face-value; a simple library lets a program draw its own more functional header. But when you look at the grand scheme of things CSD libraries by nature don’t care to integrate with all environments, causing massive headaches and complexity to all other developers outside the targets of the CSD library; if the CSD library did attempt target target all environments, the CSD library itself would be *insanely* complex. Simply put you’ll never, ever, ever hear about a CSD library that supports KDE, Gnome, Windows, Mac, Unity, etc etc. DWD also forgoes the need for complex hacks and workarounds that desktop environments have had to kludge together; such as enabling corner-dragging in the toolkit because there’s no window manager support on frameless windows.

With DWD, environments can choose to support or not support DWDs, and provide incredible amounts of integration which CSDs simply cannot offer. Environment-specific integrations applications are doing (such as menubars) is primarily done through kludges and duct-tape, and even then they still don’t properly support every environment. Unity/Mac-style menubars are so broken in so many places it’s silly; support for the same applications and desktop environments vary from distro to distro. Gnome is moving towards eliminating them completely, with Gnome devs expressing that it’s one of their goals.

Lastly, the look and feel is also less susceptible to breakage; it’s been noted that GTK will often break themes, meaning theme developers constantly have to keep up with CSDs. With DWDs, the window manager doesn’t even know or care about the toolkit – it just follows the standardised instructions.

In other words once you step outside a face-value glance, DWD eliminates huge amounts of complexity – and more importantly breakage – through consistency. And support, while initially about as bad as CSD, actually has a chance of propagating across multiple desktop environments and toolkits reliably.

The buttons are too big! I hate this big button trend! (aka, I don’t like the look! It should look like this!)

I agree! DWD applications should absolutely fit and feel exactly how you want them to. If DWDs are implemented, it would be up to the window decorator and decoration to provide options like spacing, sizing, look and feel. So aside from the options decorations themselves might be able to provide, being able to completely change the decoration or decoration engine is an option. You could use minimal themes, fancy themes, ultra-compact themes or even embed the controls elsewhere and use a minimal wire-frame. DWDs would give you *more* control over the look of your applications than you’ve ever had before. So if you think one style is ugly, you aren’t ever stuck with it.

I don’t like DWD or CSD! Just keep SSD! Keep my titlebars clean!

Depending on the window manager using DWDs, buttons in titlebars could be disabled; resulting in traditional SSDs. The DWD specification is aiming to be completely backwards compatible, which means we also get a traditional SSD mode for free. That being said, DWD is still mostly conceptual at this point, so you’re still ‘safe’ from the evils of UI changes for a while.

Could my toolbar menus be placed in the window frame if DWDs aren’t supplied?

I personally would not fold this in to be a part of the DWD specification – but developers might decide otherwise. In my designs I had DWDs placing the application menubar into an overflow portion of the command menu; I should elaborate on that:

Ideally menubars in DWD command buttons would be an application-specific option and not part of the core DWD specification. Not all applications use menubars, and in some cases (such as productivity or professional applications) the application *needs* those menubars front-and-center – not behind a button. The DWD client library would likely just include a convenience function that would allow easy menubar embedding into the command menu’ putting it into the applications’ control.

In other words, I think this should be a Kwin-specific thing, and not a DWD-specific thing. The goal of DWD isn’t to ‘take over’ the window, merely to extend it.

Could DWDs fall back to CSDs?

Yes, they could! But no, KDE won’t!

One of the few things about KDEs’ implementation would be that we would not use CSDs as a fallback ourselves. DWDs could conceivably fall back to either CSD or SSD, but it would be an application/toolkit decision. KDE sentiments are falling back to SSD if DWD became a thing, and I personally agree with that choice. KDE/Qt technologies are designed to be used in a cross-platform cross-environment manner, and CSDs are probably the least portable thing you can integrate into a program for a number of reasons.

That being said, other environments/toolkits – if they decided to pick up DWDs for other potential benefits – could use or switch to CSD as their fallback.

Could other toolkits & programs be ported to DWD? Or is this just going to be KDE/Qt?

DWD, being a protocol, is highly portable. Native implementations in various toolkits should be possible; not just Qt and Gtk, but wxWidgets, Java, or others could implement it. In addition, toolkits would not need to worry about their environment in DWD, so a GTK application with DWD could fit right in with KDE, and vice-versa (if a Gtk environment hopped on board the DWD train). That being said, we don’t know who is interested in DWD outside of KDE, and even if they were it would likely be a while before it started propagating around.

Some applications which offer plugin support could implement DWD by using their API by hiding native widgets – Firefox being a prime example. There may be limitations to customization from implementation to implementation, but it is possible. Some applications (such as Google Chrome) are more questionable as to whether or not this approach would work, but it’s still better than nothing (its known chrome has ways of hiding the tab bar, but I personally don’t know enough about the chrome addon API to know if it’s possible in that context).

Gtk programs using CSD are a much tougher question to answer. I don’t know much about the Gtk-based “headerbar” CSD library, but if *any* solution were to bring DWD to Gtk it would be in that library. From what I’ve been told there are likely significant hurdles, and if DWDs were to be implemented it would be for feature-oriented reasons, meaning early cooperation or adoption is unlikely. Either way, DWD is being designed to be toolkit and environment agnostic, so there won’t be hard KDE/Qt-driven requirements in the implementation. Also, I need to stress that I’ve heard of no interest for DWDs from Gnome or Gtk developers – Gtk may ever use DWDs.

Will the DWD protocol use DBus?

DWD will likely be DBus-based. This likely means DWD features will be disabled on Windows unless a windows-specific utility library is written using QtWinExtras (for Qt applications); If such a library were to be implemented, it would offer a truly cross-platform way to use many currently windows-specific features, such as thumbnail toolbars, icon overlays, and Glass.

For external use (like networking or bluetooth) it depends entirely on how developers want to approach it, whether or not they would be in the core protocol, or use external plugins/services to extend the base functionality of the specification. I simply don’t know the optimal solutions or how developers might approach DWDs from a technical standapoint.

Could I have my decorations on the side or bottoms of my windows?

That would be up to the decorator, theme engine, and system; applications won’t get to know how their DWDs would actually be implemented, nor would they get get ‘final say’. The DWD protocol will provide applications with the chance to provide hints and metadata to how they believe they would optimally be displayed.

KDE developers are leaning towards consistency in the UI, so that consistency is being built in to an extent; There are ‘hints’ I’d like to see specified that the default KDE setup would not use, but we do need to consider the fact that other decoration engines or environments might want those hints. If a hint was of significant and immense value our applications would readily want to request, I will seek to have those hints included. Once a specification is made, it gets much harder to extend over time (and then get new feature adoption) so I feel it’s important to have obvious specifications included, even if we ourselves won’t use them in our default setup.

Things like position hints, colour hints, font hints, and other which could realistically be desired I think should be included in the spec.

Is DWD secure?

DWD will broadcast window controls, and this obviously means if DWD is done poorly, it could grant access to applications and cause all sorts of trouble.

For a very real example: Dolphin will open a web-browser if you type an HTTP address into it. Odds are a file manager with DWD will offer the location input. Someone hijacking your file managers’ DWD could allow them to open your web browser to a malicious web-page. If DWD is done improperly, scenarios like that become possible. Scary!

Already, my personal DWD specification is addressing issues like this. I won’t get into technical details, but DWD will be locked down by default, and flags will be used to express where, how, and who can access individual widgets; with denial outside non-root window decorations being the default access policy.

So, yes, DWD has security in mind, and will be well locked-down.

DWDs will allow *any* widget in the decoration / Applications will draw the widgets and DWD will just import them.

False. The widgets will be drawn by the consoles, so DWD has it’s own widget vocabulary, independent of the widgets offered by the applications’ toolkit to ensure consoles receive predictable input. We also don’t want to simply include everything + the kitchen sink, as having too many widgets means more complexity, more work for theme designers, and more work for implementations. DWD isn’t meant to be a “put your application in the header” library, it’s meant to compliment the main interface.

That being said, the widgets being drafted cover pretty much all reasonable use-cases and will aim have all the most common widgets, including buttons, buttongroups, breadcrumbs, sliders and other goodies. I don’t know what developers have in mind when they picture the widgets, but the final widget will be well thought out so designers aren’t overburdened creating DWD-ready decorations, and application devs still have the tools they need to build high-quality interfaces.

What will the first KDE release using DWDs look like?

The VDG has been keeping this under-wraps for some time, but we have designed a new, original, beautiful interface which KDE will default to when we switch to DWDs. We believe a lush photographic background will be key to adoption, and bold colours with subtle hints of depth will be the norm in the future.

nononono-dwd
Modern. Beautiful. Original.

Footnotes;

I’m going to be going holding off on DWD-related posts beyond this until I’m more firmly in touch with developers on the topic (which may be far off, we have busy devs!); I’m beginning to rub up against the boundaries which I can reliably talk about without referencing them first. This post was written simply to address C&Qs around the web (which I saw) and thought I’d address; as usual, this post is not guaranteed to be accurate, and when developers start aiming towards an implementation they could go in a complete different direction than what I’ve written here. So, salt people!

Advertisements

57 thoughts on “DWD – a FAQ for questions around the Web

  1. I had this thought that, assuming compositors are pretty good these days, you could use the window alpha mask feature (which doesn’t work particularly well at the moment because blur doesn’t work with it). I made a dodgy mockup of what I was thinking: http://i.imgur.com/4CePCQ1.png

    Firstly you start with the theme essentially rendered over the full size of the window. Then the theme can supply some information about which bits of that image are out of bounds (the red bits), and anything drawn to those areas would not be displayed. Then, using the mask information, your application can render itself with its own alpha mask and recieve events etc in the “header” area. And with that, you have a pretty application! (Assuming Firefox doesnt use the Gimp logo…). Applications would have to ask to be rendered like this.
    Just an idea.

    Like

  2. I’m really naïve about WM stuff, but I can’t avoid thinking about having an Windows implementation of DWD at least for KDE apps. I can’t think, however, how could this work without having a QAbstractNativeEventFilter implemented for each app to handle what Windows terminology calls “Non Client Area” (http://msdn.microsoft.com/en-us/library/windows/desktop/dd162743(v=vs.85).aspx) (and maybe also the same applies for Thumbnail Toolbars, Tab Thumbnails and Deskbands to achieve DWD features)

    My past-self played a little with Tab Thumbnails and it was a disaster (don’t judge me, this was 3 years ago 😉 https://git.reviewboard.kde.org/r/102758 ) but now QAbstractNativeEventFilter looks better than its Qt4 counterpart (still we’d need, however, to use installNativeEventFilter in every app to achieve this).

    Like

    1. The nice thing is that, unlike in Gnome, you can turn stuff off and go back to classic decorations ;-). Customization potential is what I love the most in KDE!

      Like

  3. @RandyRanderson, for the lack of a reply button I have to post this here.

    Certaintly, CSD may give developers the oportunity to make inconsistent apps, but DWD is not the way to fix the problem, because anyway, developers have the rest of the window to make inconsistents, are they going to implement a protocol for that too?

    Now, some of the problems of inconsistent betwen KDE and GNOME applications can be mitigated with a theme, that is something that exist today, and if GTK applications still doesn’t look that consistent then so be it, that obsession to make them look like KDE applications is ridiculous anyway, let the user deside if it wants to use it or change it for nother more consistent.

    Let’s talk about the problems that DWDs,bring to the users, applications will demand more CPU cycles, if a music player has a progress bar in the heather and is playing a song that last 300 seconds, it means it have to send 300 signals to DWD protocol via DBUS (or whatever they use), this is error prone, and I’m talking about a single window and a single widget, the sync problems they wil have will be more trouble some for the user tan a simple inconsistence, and there are more problems I won’t list here.

    But you know, its they funeral anyway, if they want to go that way so be it, I use GNOME Shell where I think they are making the more sane desitions

    Like

    1. It’s one thing to have inconsistencies *inside* the window, it’s another to have them in the decoration – which is supposed to be the system-run sanity-check for organizing all the windows (even if the apps running in them are unruly). The former is tolerable, the latter is not.

      As for CPU usage, that’s completely bogus. The highest message-rate scenario I can think of is some kind of smooth-flowing progress bar embedded in window decoration. Even at 30FPS, that’s nothing even for very low-end CPUs like the ~600MHz ARM11 in the Raspberry Pi. And when kDBus finally hits the mainline kernel, DBus messaging is going to be *blazing* fast, not much slower than synchronized communication between threads in a single process.

      Also, please remember that with modern compositing WMs, no application draws directly onto the screen. They draw to memory buffers representing content of their windows, which are then used by the compositor to re-render the screen when something changes. So any synchronization issues are *already* present and dealt with, and it is no (additional) problem to have compositor re-render things only after *both* window content and decoration are updated, so that content and deco widgets are kept in sync.

      Like

  4. Why don’t you just stick to CSD? I think you benefits you get from DWDs (theming, configuration) are just not worth it and will bring new kind of inconsitencies.

    Liked by 1 person

        1. After reading the arguments, the issue with CSDs is the fact that CSDs would require exponential complexity to maintain. Once one toolkit has a feature, they would all need the feature, for every window manager, in every enviornment… Also, any window interactions (like window tabs) would also require IPCs to function, and even with that if the active window froze you’d have all sorts of inter-process weirdness.

          I used to be super gung-ho pro-CSD until I really had to take a super-serious look at it. Funationally, CSD just isn’t worth it.

          Like

          1. I don’t think so, I believe DWD is more complex and CSD give more freedom to developers, they cand add the controls they need to the header, handle them selves the events easily, wit DWD they are limited to the controls it provides and it has to handle the events in a more complex way.

            Liked by 1 person

            1. CSD give more freedom to application developers by allowing them to not have to think about the environment they run in or the ecosystem at large, which creates a lot of consistency and usability issues (basically the mess that you get on Windows). Basically they just shift the problems from the developers to the users, which is the worst thing a technical solution can ever do.

              Like

            2. It’s one of those apples-and-oranges things; you need to pick what demons you want to live with. KDE is focused on compatibility, technical flexibility, and modularity – so DWD is a concept that evolved from those choices. Gnome and similar enviornments are aiming for simplicity and toolkit-level integration, so CSD was the go-getter. DWD adds complexity though and CSD sacrifices integration and portability.

              I think DWD better fits KDE because of it’s more ‘modular’ nature, along with its potential portability; while the buy-in is initially more complex, the payoff from being able to embed widgets in several areas seems ‘very KDE’ in the things that can be done with it. In the end, I also think the API for applications developers will be roughly the same in terms of complexity.

              Ultimately as much as I rib on the Gnome guys I respect their ability to get UI out, and with KDE I respect the technical dicipline. It’s all a matter of apples and oranges.

              Like

  5. I think Dwd is too much complicated and will bring performance overhead, security issues and fragmentation to linux desktop because it is very difficult to implement.
    Instead, i propose a very simpler approach:
    Half/half. Let me explain. The whole rectangular window area should be csd. But only the decoration concerning minimize,maximize and close button, should be ssd and rendered over the appropriate area of the window. Instead of the complex dwd protocol, a simpler protocol is needed, just for the window manager to inform the application where it will be overdrawed.
    That approach, solves the problem of hanged windows which rasterman described on previous post.
    I propose to render ssd decorations over and not to exclude any area from the window rectangles, not only because of unwanted complexity, but in favor of drawing pictures or gradients for window background without corruption.
    So we won’t have the common problem, which Matthias Berndt describes. (ok f**ck the origin of screenshots, the problem is the different toolkits). But different toolkits will continue to exist and probably the different themes too, giving a very ugly and inconsistant gtk app with qt dwd!
    I think its preferable for the windows to don’ t have the same window bar with each other than the inconsistancy inside the window.
    Another situation that dwd excludes but my half/half approach permits, is that mockup from your whatif csd proposition post, where a pdf reader app used the whole right side to render the page and in the left side the pager was under the decoration.
    Also it should be a user option to go back to classic ssd for every user who prefers the inter-window consistancy, informing the app that can draw its widgets everywhere it wants.
    Weither you believe it or not, that information came to me in a dream!

    Liked by 1 person

    1. CSD is not easy to implement. It’s a myth. Just look at the huge amount of issues I reported against GTK when they introduced CSD. It is not easy to get it right.

      So anything using CSD for the basic is not going to be easy. Period! Any other solution might also be difficult to implement, but that’s not a reason to say one should use the easier CSD.

      Liked by 1 person

      1. And by the way, it’s not CSD. It’s basically NWD. No window decorations. Maybe we need some methods to emulate a title bar (because I don’t think it’s a concept that should be completely lost (okay we’re back in the csd realm (but actually that does not automatically mean it sucks just because the GNOME people did such a shit job implementing it))).

        Like

  6. Bad idea, really bad idea…

    I worked on appmenu support and doing ui things using dbus is a bad idea: segfault in apps, freezes, …

    That’s why Canonical moved to gmenumodel/qmenumodel based on gio and not on dbus…

    Like

    1. For exposing the widgets to the decoration I’m rather leaning towards using the Wayland protocol. But this would limit the use case significantly. If we want support for things like kde-connect having a Wayland interface is proabably not sufficient. Maybe it could be done by forwarding from the Wayland compositor.

      Anyway I think it can be done with D-Bus in a working way if the API is designed in a proper way. We have to look at it once the designers finished the drafts. (That’s the good part, just because the designer say D-Bus doesn’t mean that the engineers will pick D-Bus 😛 )

      Liked by 1 person

  7. I think this is a cool idea, especially in combination with dbus! As an application developer you must not use any special toolkit, which is really great!

    Like

  8. I like the idea of sliders which can only be adjusted by grabbing the knob. Too often I adjust those things by mistake. But then you might get comments like “why does this widget act differently than that one?”

    Just a note that about the only part of that compact bar draggable with fingers (touchscreen) would likely be the title, and buttons if so enabled (without slider tweak). The gaps are tiny.

    Like

  9. Server-side decorations (and this “DWD” stuff is just a variant of those) are a Bad Idea. Yes, they make sure that every window has the same decorations, but that’s not the important bit! What matters is that the decoration of a window and its contents match, and server-side decorations are the best way to ensure that never happens. Just look at some screen shots:

    You can’t tell where Firefox ends and the window manager begins, it’s all of a piece, just like it should be. Now let’s compare to Firefox running on Kwin:

    Granted, that screen shot is a bit older, but it illustrates the problem: The window manager doesn’t know what the app looks like, so it draws a decoration in a completely different color and style that doesn’t fit in at all, it’s butt-ugly. And this is *precisely* the reason why I never used any of the window decorations that can be obtained through GHNS: because the one that’s shipped with KDE is the *only* one that matches the contents of the KDE applications!

    Also it doesn’t sound right at all that the KDE/DWD developers get to decide which widgets can be placed in the decoration and which can’t. What’s essentially happening here is that you’re inventing a new GUI toolkit controlled through RPC. Other people have tried that before (Fresco/CORBA being one example) and it turned out to be a bad strategy. How do you know what kinds of ideas UI designers will come up with 10 years from now? You don’t, just like the designers of X11 didn’t know what kinds of drawing primitives we’d need these days. So you’ll end up bloating the protocol with more and more functionality that application developers need, and you can’t ever remove stuff because that would break compatibility. Unfortunately it seems that KDE is more into discipline and bondage than developer empowerment these days. Which doesn’t make sense because users have a very effective way to protect themselves from misbehaving applications: they stop using them. The whole problem is essentially made up as it was always possible to do crazy things with X11: applications could move their windows around, they could have crazy shapes (xeyes, anyone?) and yes, they could suppress window borders and draw their own. And yet, I can’t even remember a single application where this was in any way a problem.

    Worst of all, as far as I know there isn’t even yet a way to find out whether an application will draw its own decorations or not on wayland. Therefore, GNOME applications running on KDE might end up with two window borders and, even worse, KDE applications on GNOME might end up completely without decorations.

    It’s probably too late at this point as the KDE developers already seem to have made up their minds. But still, I felt like this has to be said: Server-Side decorations are a mistake, just like server-side drawing and toolkits were. Thanks for reading.

    Liked by 1 person

    1. As x11tete11x mentioned, both of those screenshots are both traditional SSDs, the only difference is one was configured to blend in, and the other wasn’t. By default, KDE is configured to blend in, and it actually has autodetection now to better blend in even more. On a side note, many of the Gnome CSD-oriented applications make a point of having the CSD contract from the remainder of the application – so they usually don’t blend in.

      With Firefox (the app in your sample shots) there’s no CSD support, only SSD support (except on Windows / Mac where Firefox uses native APIs for enhanced tabs-in-title area); but with DWD it would actually allow us to integrate Firefox via a plugin. I specifically put together a screenshot to illustrate how Firefox would look under DWDs (this screenshot showing a white theme); We get native KDE look’n’feel on a completly non-native application. Also, a Firefox DWD could also broadcast other info such as ongoing downloads which you could then read on other devices, get jump-list like functionality, and other goodies. Technologically speaking, DWD offers superior integration compared to CSD. If you want a CSD-based browser using application-driven UI refer to Google chrome. 😦

      In terms of us deciding on what widgets can be integrated, were not going to specifically say ‘no’ to be evil; we want apps using DWD to be great, but we also have to be careful not to overburden everyone involved; Once we get the core widget set down, we can see what’s working, what’s not, and make considerations from there. If you look at most apps using CSD though, you’ll find most of them stick with a very small subset of widgets, and if DWDs aren’t appropriate, then they can just be ignored.

      In terms of longevity, DWD is not implementing a toolkit, it’s a protocol; DWD does not dictate what the display end of the protocol uses. DWD is more/less just a message service. With KDE, Qt would obviously render DWD widgets, but in other enviornments Gtk could be used. All DWD manages is send/receive. In addition, widgets have pretty much settled down since GUIs became mainstream; we aren’t really inventing new widgets anymore – even in touch – and the form-factors were targeting don’t even demand many of the widgets we do have. If DWD ever got so unmanagable that it was impractical to use, DWD falls back gracefully to traditional SSDs – so breaking it would simply revert an application back to SSD – though I honestly never see that happening. X was difficult because it touched almost everything in the system from display drivers to printers to window managment; DWD would a fraction the size of X.

      With Wayland, the choice to use CSD or SSD isn’t enforced by the protocol, it just allows CSDs to become first-class citizens. Gnome applications getting double-bordered is already a known issue in many enviornments otuside of Gnome – and this is largly because they have ignored compatibility. With DWDs, if an enviornment does not support DWD it will fall back gracefully to SSD – so DWD applications will never be borderless. Basically, any issues in regards to window integration will be because of CSDs – as is currently the case.

      Anyway, I’d highly reccomend reading or reviewing https://kver.wordpress.com/2014/10/25/presenting-dwd-a-candidate-for-kde-window-decorations/ as it answers many of these questions. Hope that helps clear up some things!

      Liked by 1 person

      1. Now, I don’t know what this “blend in” stuff is that you’re talking about, but I’ve never seen any of it on my desktop. Every time I try to install a new window decoration via GHNS, I end up switching back to the default one (oxygen or air or whatever it’s called these days), because *all* of the other ones don’t match the window contents and just look out of place on every single application I’ve tried them with. So please, stop insulting my intelligence my pretending the problem doesn’t exist. It does. And stop spreading this blatant falsehood: “Technologically speaking, DWD offers superior integration compared to CSD”. They offer *different kinds* of integration. SSDs make window borders consistent across windows. CSDs make window borders consistent with window contents. Unless all applications switch over to the same toolkit, **you can’t, in general, have both**.

        And of course, this is also not true: “We get native KDE look’n’feel on a completly non-native application.”. No, you don’t, stop saying that because it’s rubbish. What you get is a browser that uses one style of widgets for the web pages and dialogs and another style of buttons for the widgets that happen to reside in the window decoration.

        > In terms of us deciding on what widgets can be integrated, were not going to specifically say ‘no’ to be evil;
        You’re assuming that developers are actually going to ask you for this stuff. Hint: they won’t, and there are tons of reasons for that. One is that they *know* that lots of stuff that might go into the decoration makes sense for their application but not for any other. Amarok used to have something called a moodbar, and it would fit perfectly into the window decoration, but it’s nowhere near anything that would make sense for general applications. Another reason is that developers want stuff that works *today*. They don’t want to contact the KDE team to beg them to add a new widget to the DWD and then wait for half a year or more until it ships, then wait for another year until their users migrated, just to perhaps find out that maybe their idea wasn’t as good as they originally thought. If you don’t give developers an easy way to try out new UI concepts, they’re not going to bother and just do without. Many ideas *will* be lost this way.

        > In addition, widgets have pretty much settled down since GUIs became mainstream; we aren’t really inventing new widgets anymore
        That’s horseshit, and you know it. Gtk 3.10 alone introduces SIX new widget types. And Gnome largely switched from check boxes to GtkSwitch widgets recently. So yes, new widgets are being invented all the time.

        > In terms of longevity, DWD is not implementing a toolkit, it’s a protocol;
        That’s like saying that libX11 doesn’t have drawing functionality because it doesn’t draw stuff itself but only implements a protocol to tell the X11 server to do it. Like that’s what matters! When something allows me to make a few API calls (and it doesn’t matter at all whether those are D-Bus or CORBA or library APIs) that describe the widgets that should be put on the screen, then that thing is a toolkit to me. That those API calls go through D-Bus is an implementation detail that I don’t even care about as an application developer. Hell, that’s what OO RPC is *all about*: hiding all the IPC nastiness and pretending that you’re just making some method calls on an object.

        > Gnome applications getting double-bordered is already a known issue in many enviornments otuside of Gnome – and this is largly because they have ignored compatibility. With DWDs, if an enviornment does not support DWD it will fall back gracefully to SSD – so DWD applications will never be borderless. Basically, any issues in regards to window integration will be because of CSDs – as is currently the case.

        Whom are you trying to shit here? You’re incapable of the kind of stupidity required to believe an argument like that, you’re just being intellectually dishonest. Don’t do as if you don’t realize that that argument can easily be turned around to blame Kwin for double-bordered Gnome applications. The compositor can either draw decorations or not draw them. Since Gnome applications draw their own decorations these days, Gnome Shell obviously won’t draw any, and since SSD/DWD applications won’t draw them either, they’ll end up without when running on Gnome Shell. There are two ways to fix this: either fix KDE applications so they draw their own decorations like they ought to, or establish some mechanism for the compositor to query the application whether a decoration should be drawn. And please, don’t insult my intelligence again by pretending that Kwin doesn’t understand MWM_HINTS_DECORATIONS and similar already.

        Like

        1. Matthias, I mostly agree with your opinion. Especially about the consistency part and the forcing/restricting of app developers.

          *BUT*, please calm down and stop insulting Ken!
          This is totally not appropriate and I hope you know it, too!

          Liked by 1 person

        2. Before I reply, I’d just like to mention that I’m super-happy to get feedback – positive or negative. I do try to ensure I’m factual in my statements but I will be the first to say I am wrong on many occasions, and I am not a veteran developer with precise answers. Any time I’m wrong about something, please let me know and point out the correction, and I will be happy to share that knowledge and correct myself. Also, you have my condolonces if you feel insulted, I was simply trying to be clear in my explanations. That being said I have a very low tolerance when decorum isn’t excercised; I’d like my blog and the community in general to be healthy and constructive; this is your first and final warning that I will not tolerate your language and attitude in general, if you would like to continue commenting on my blog do so in a constructive non-inflamatory way. I will be editing your existing comments to censor your language tomorrow.

          With ‘blending’, I was referring to the way the window border smoothly transitioned to the application, like the first screenshot you posted; where you can’t tell where the border ends or the application begins. Oxygen is a prime example of a window border which blends in with the widget theme. You can replicate the effect with (some) other themes, but it might require some configuration, or even an alternate widget theme. I know there are a couple “matching sets” out there which can look dashing.

          I do beleive there was some crossed wires referring to my comment on the “native look’n’feel” for non-native applications; I was referring to know applications like Firefox offer no window-manager integration on Linux – in the respect that there are no “tabs in borders” or anything like that. The KDE look’n’feel I was referring to is Firefox exporting its tabs and buttons as a DWD decoration, thereby acheiving the native “tabs in border” effect. Firefox will likely never offer anything like CSDs (it’s just not worth it for them) so DWDs is literally the best (only?) option. Things like dialogs, button styles, etc not looking ‘native’ is entirely a toolkit-level issue, and would not be solved with CSDs; If an application can’t be trusted to integrate into the look of a toolkit, why would I trust it with the behavior of my desktop?

          With widget integration things like the moodbar would indeed never make it into the DWD; and yes, super unique innovations like that probably would take a hit. The time it takes for features to propigate (especially with protocols) is also a genuine concern, so lots of thought is going into the first round of widgets. But I do think the concerns are overstated; developers request features all the time – it’s hardly begging, and when features are added they’re integrated as we go along; smaller standards can move relativly quickly, and even if a decoration isn’t caught-up to the standard the worst that happens is the deco kicks back into traditional SSD mode until it updates. That all being said though, I think we’ll have a pretty decent set of widgets picked out of the gate. Outside of that, with CSD you do lose the ability to innovate at the decorator level and features like window tabs, shading, button customization, etc are lost.

          On inventing widgets, the 6 new GTK widgets you mentioned are for the most part just re-stylings and combonations of existing concepts – save for the headerbar. The stack-switchers are functionally identical to tabs, the revealer is simply an animated container, and the search bar is a preformatted text box. There is nothing I see in those widgets that can’t be duplicated with a combination of existing widgets, and I beleive that doing a good job on mainstream widgets will yield equally positive results, possibly being more flexible with the right options.

          I won’t get into your argument on toolkits vs protocols; simply because a protocol conveys basic structure of widgets does not make it a toolkit. Speaking strictly in terms of longevity, a simple protocol with simple structure will last a long time because it doesn’t worry about the complexity of the toolkit; it’s not like the standard button will be depreciated.

          In terms of KDE applications needing to draw their own decorations because it’s what’s Gnome is doing, the vast majority of applications on Linux make no attempt to handle their own borders; the issues arriving with CSD are because CSD is the deviation from the established standard. It’s not just about the visible decorations; it’s about behaviors, settings, and window-manager capabilities. CSDs don’t integrate well and they cause a bumper-crop of issues when they don’t have window-manager help. Even resizing a window from a bottom-corner was a big deal for CSDs, and if I recall correctly they had to add a hack to the entire toolkit to fix the issue; as a developer, do you want to use a toolkit held together with duct-tape and bailing-wire? With DWDs and SSDs you’ll get sane, reliable behaviour consistently, and that those decorations will respect your settings and preferences; no hacks, no workarounds.

          Like

    2. “completely different color and style that doesn’t fit in at all”
      Its the application which is supposed to use the system theme (and hence the window borders etc), not the other way round. I don’t want one of my apps to be pink and the other to be green, or it will be like the web where every damn website looks different and behaves different.
      I felt like this has to be said: Client-Side decorations are a mistake, they kill consistency and hurt your brain.

      Like

      1. > Its the application which is supposed to use the system theme (and hence the window borders etc), not the other way round.
        Yeah, except that’s *never* going to happen. Qt and Gtk aren’t going anywhere for the forseeable future, and attempts to make them look consistent (such as gtk-qt-engine) have ultimately failed. The only way to achieve consistency is to make them use the same toolkit, and if that ever happens, the whole discussion is moot.

        > I don’t want one of my apps to be pink and the other to be green, or it will be like the web where every damn website looks different and behaves different.
        Sorry for bringing this to you, but that’s what’s happening already. Apps have complete control over almost all of the window, and every attempt to do it differently (like Fresco) has consistently failed. And somehow people accept that just fine and don’t even think about it most of the time. Why are those few dozen pixel rows above the window supposed to be so different?

        Like

        1. “attempts to make them look consistent (such as gtk-qt-engine) have ultimately failed”
          Actually, The oxygen team has made native versions of the oxygen theme for Qt, GTK2 & GTK3 and I say they’ve done a rather great job at it. Also, Qt’s GTK theme works great at adapting your GTK theme.

          Like

          1. The point is that it should work for *any* theme. And yes, it works quite well for Qt applications on Gnome, but Gtk applications on KDE Plasma still suck.

            Like

            1. And who’s fault is that, exactly? QT has gone out of its way to mimic the GTK theme. So why isn’t GTK going out of its way to mimic the QT theme? In fact, if I understand the changes to GTK3’s theming correctly, it’s now *impossible* to do something like that.

              Like

            2. Thx! Trent M that’s the point… WHY on the earth KDE should take care what GTK do in KDE Enviroments?, as Trent M says… “QT has gone out of its way to mimic the GTK theme. So why isn’t GTK going out of its way to mimic the QT theme? ” …

              Like

      2. While I agree with you when you say applications should use the system theme, I want emphasize some cases where ergonomy is better if the application use a specific color scheme. For instance, Gwenview or Blender display elements (pictures, 3d models) that are usually brighter than dark.
        In order to increase contrast between elements and UI, they display elements in dark panels. The UI doesn’t look nice if all other widgets are not dark too.
        In the best world, there should be two system themes: a dark and a bright, and the application should be able to choose the one that better fit its use case.

        Liked by 1 person

      1. Great, so you have color theme support. But that’s just one tiny part. UIs are themeable, and there’s no way you’re ever going to make the widgets drawn by kwin consistent with those drawn by the application. All the buttons and sliders and whatnot *will* look different than those in the application window.

        Like

        1. If an application goes so far as to provide different looking widgets than DWD is not a solution for it and such an application would not even think about using it, because they are “special”.

          Like

          1. So you would consider Amarok:

            and Clementine:

            special?

            Strangely Ken’s post always feature music players as examples, but I guess then these are new ones, which yet need to be written….

            Like

            1. Amarok and Clementine use their native toolkits (Qt) and do actually fit in to their enviornments. Martin is referring to applications like Chrome, Firefox, Kingsoft Office, Opera (to a lesser extent now), LibreOffice (to a lesser extent) FontForge, media centres (ike Kodi) etc. Luckily, some are flexible enough for us to do integration through plugins (like Firefox)

              Amarok and Clementine do have a couple of unique widgets, but if they wanted to jump onto the DWD wagon they don’t need to lose them – they just wouldn’t put it into the deco. The deco could have play, pause, next, prev, volume, sountrack, and album in the deco, and keep the moodbar in the main window.

              The main issue Martin is getting at is 99.99% of the time applications which break from traditional interface conventions are usually the applications least likely to ever integrate and the most likely to do their own thing. It’s usually the result of a weird/custom/outdated toolkit, or because they have their own ‘brands’ and specifically go out of their way to be special. Either way applications that don’t integrate well with the native UI will never blend into SSDs, would not port to DWDs, and would likely need completly custom CSDs to do what they want anyway.

              Even if you look at Gnome CSDs I see no applications really breaking the mould with headerbars, the most customization I’ve seen so far is pallet swaps – which are covered. Otherwise, I haven’t seen any truely unique widgets or styling in a CSD-based app which we won’t aim to provide in DWDs.

              Like

    3. Finally someone who understands it! I too think this approach is completely crazy (and inconsistent – applications draw their content themselves in their rectangle but not in the titlebar: ???)
      I have written basically what you’re saying a few days ago on that other DWD article, just WAY worse, so I’m really thankful for you pointing out the issues in a civilized manner 😀 Just so you know, I’m with you. I also think the applications should be allowed to completely do their own thing and only the window buttons should be serverized. That way you can have a wonderful immersive experience (take a video for example – we don’t want no titlebar in here!) and the app can have a simple rectangle to draw into. That’s pretty much how every designer (at least on dribbble) would do it. Everything that needs to be cared then would be the space for the window buttons. Can’t be that complicated, ay? Additionally, we could even hide the window buttons to go into something similar to android’s “Immersive mode”, which basically hides everything but the most important content of the app. If the app does not respond within, say 1 second, the buttons reappear and it can easily be closed again. Also, moving the window would not even be an issue because why couldn’t you drag the buttons? But actually, at least with Qt-apps it should be very easy to make EVERYTHING draggable that’s not a control.

      Like

  10. “DWDs will allow *any* widget in the decoration / Applications will draw the widgets and DWD will just import them.”

    This one relates to why extending things to other toolkits will be a challenge. Contrasted with Gtk’s header bar, where the widgets in the header *are* native widgets drawn by the application, and fully hooked into Gtk event handling, etc. It’s unlikely to be possible to change this code easily to use the theoretical widgets provided by a DWD specification… certainly, it won’t be possible to do it entirely in the toolkit… a new API and new application code would be needed.

    Like

  11. As for dragging, I have always wanted to see a button that can toggle things like the decorations or better yet, activate something similar to the unity drag handles, which make dragging and re-sizing much easier than just using the edges or some “hard to identify/obscure draggable spot”, i.e.:

    http://askubuntu.com/questions/68910/what-is-this-hidden-unity-window-dragging-feature-i-discovered-on-accident-and

    anyway keep this stuff coming they look amazing imo.

    Like

    1. Huh. I’m surprised we don’t have that. Not even as a hidden plugin. ‘Should be doable just as a kwin thing, doesn’t even need to be DWD. I brought it up in the VDG, I’m actually really surprised there’s no feature like that; closest we found was “window geometry”, but that doesn’t give you grab handles.

      Liked by 1 person

      1. Ok… And why we don’t have Plasmoids resizeable this way… but using the ridiculous icon? When there are many plasmoids close each other, they cannot be resized because the UIs overlap.

        As for the topic, many of the points are also points pro CSD. Most notable example: “How will I move the window if everything is interactive?”.

        Today the real and first point PRO is being safe when you cannot fix an app that uses CSD (because is closed source). Like Adobe Reader (already unmaintained anyway). Everything else is a matter of properly designed UX, which (as admitted in this article) can suck with SSD/DWD too – and it’s easier for mistake when the API is tricky and have to be tested on many desktops (read: Unity, GNOME care only so much about Plasma compatibility…).

        Crashed/hanging app is equally useless for me with CSD as it is with SSD. I don’t use the volume controls of crashed Amarok anyway: they do not function because the app itself is dead already.

        The concept makes me feel like using QWidgets on iOS. Can work but…

        Like

      2. Having something like a grid to drag window edges to might be nice too, e.g. to make it easy to resize a window edge to the middle or one third of the way across a screen.

        Like

    2. I don’t think that’s a useful feature to implement. It’s quite hidden (one needs to know the magic mouse button to trigger it) and is no advantage over the unrestricted move/resize mode with Alt+lmb (move) or Alt+rmb (resize).

      Like

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