DWD: Protocol U-Turn

Since Martin posted his Wayland progress I’ve noticed an uptick in questions about CSD, so I figure now is a good time to upload this post I’ve had sitting around, as for the past month I’ve been closely examining the concept of “Dynamic Window Decorations”, or “DWDs” and how to better implement them.

When Last We Saw Our Heroes

For those who need a primer or reminder, DWD is the sister of “Client Side Decorations”, or “CSD”s. Both CSD and DWD are methods for placing widgets in the frame area of windows to save vertical space, look cleaner, and either make applications feel unique or more integrated.

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

CSD charges the application with drawing the whole window including the frame, instructing the window manager to discard the provided frame. This is the method used on Windows, OSX, and GTK. DWD is aiming for the opposite approach; the window manager continues to draw the window frame, but the application can request certain widgets to replace the window title. Martin Gräßlin plans to keep as much as possible on the server-side as there are many important advantages including customisation, stability, trust, and integration.

DWD “1.0” Was Getting Complicated

One thing CSD will always have over DWD is customisation; when an application has free reign over the whole window it can literally do anything; it can make windows round if it wants to, it can invent crazy widgets and put em’ in the title area, and more. DWD isn’t suited to this, and while designing the first iteration of the protocol I tried to bang a square peg into the round hole by providing those many possibilities.

In my infinite wisdom I re-invented X, with a sprawling protocol that covered dozens of edge-cases which would likely never be used. Even with that, people still complained about the fact that many customisations would still impossible. People also didn’t like the KDE crew being the stewards of this protocol, as different environments want to do different things.

DWD, as originally envisioned, had to change – it was just too complicated and inflexible. Listening to the feedback it was clear the protocol had to be simple, flexible, and tractable. A large requirement was also making it able to grow outside of KDE with or without our ‘approval’.

DWDs New Approach

DWD, as I have drafted it, has been boiled down to a discovery service whose sole purpose is getting apps and window managers to figure out compatible protocols, and specify some standard UI controls which will use those protocols.

Here’s the quick overview on the current core “DWD Protocol”, again, as of my current draft (which could totally be rejected):

  • DWD will be organised into “extensions”. Extensions are just blueprints listing required D-Bus specifications, widgets/controls, and options.
  • Applications and the Window Manager handshake for compatible extensions.
  • Applications tell the Window Manager what controls from those extensions it should display, and how it wants them laid out.
  • Applications hide their native controls.
  • DWD is done and gets out of the way at this point. Control is handed to specifications like MPRIS2, and Window Managers (or Plasma) control the app through those protocols using the requested controls.

That’s it, DWD “2.0” in a nutshell.

KDE will need to create some reference extensions (plus some D-Bus specs) and hopefully everyone will be happy enough to standardise on the basics. From there any environment can create specialised extensions for DWD, we can work with extensions we like, and maybe standardise on the really useful ones (much like libinput has been folded into many environments). If someone makes an awesome extension that handles admin access requests, we could use it. If we make an extension that handles progress charts, someone else could adopt it. I’d like us to develop two reference extensions: a basic toolbar extension, and an MPRIS2 extension.

Advantages over “1.0”

Security is the biggest upside to offloading work on other protocols. DWD doesn’t care how the standards are implemented, so they can be as secure (or insecure) as they choose to be. Security issues or weaknesses in the protocol itself will be mitigated, as the protocol is much smaller. Patches for applications or changes to functional protocols can be made without breaking DWD.

Integration is also another bonus. Parts of the desktop can integrate the protocols extensions use, without DWD needing to explicitly support it. The best example is MPRIS2, which already exists and has amazing support everywhere. The idea behind DWD is that we create more MPRIS-type extensions as we need them.

Finally, core DWD is out of the hotpath for data passing. Window Managers don’t need to be “like X” and conform to complex drawing and customisation tasks. Hopefully as a de-stresser to Martin, this method of offering DWD will be much more easily implemented in a plugin architecture which can be gradually expanded upon. We won’t need to have the full protocol out-of gate, and environments can start with the bare basics and evolve as useful extensions are finalised. I don’t know how he might want to do it, but DWD extension plugins could be potentially be maintained entirely outside of Kwin (or other Window managers) if we play our cards right.

The Downsides

Nothing is perfect, so of course there are downsides;

Customisation.

The big elephant in the room. Going over more standard protocols (and not bloating the new specification) means applications will have no say over how content is styled in the window. I considered this for a while and ultimately decided that it’s O.K.

21cd7e7b6bc1893c23a2e2faad0e9239

We could still offer a few more standardised ways of doing common things we do today, such as passing a colour palette to sync with the window, but outside of the handshake I’ll push for an extension-over-integration policy.

 

The application doesn’t need to know how things are done, only that they’re getting done. The WM knows more about the environment it’s in than the application; functionality is what matters. The volume button on a computer might be shown as a slider, but on a touch-device it may be a larger button with a popout slider. Maybe a phone will simply use the hardware controls. It’s up to whatever is managing the control.

For people already seething with rage ready to point at me and say “Linux is about choice! Applications should choose what their UIs look like!” I will point out; applications can chose not to use DWD. They can choose to implement a CSD-based application. But lets be real here: when we find a need for speciality widgets, if they are really something useful, their host toolkits/environments can always add the extension.

Generally though, if an application is doing something really unique it’s probably doing it’s own thing anyway – like Chrome/Chromium – or breaking the local HIGs. If you absolutely need to save that 18px while also showing a one-of-a-kind rainbow-powered rocket-widget which must be in the frame… CSD is the price of needing to be that special.

Fragmentation.

With anyone able to create extensions, there’s a change we might have a situation where two environments create two similar offerings. For this, I believe it’s a chance for everyone to experiment, and then work together to standardise. The one thing this means is that applications created for another environment might take longer to get CSD-like functionality, though they should present their interfaces in their traditional application UI.

I think this is still better than CSD, as often a broken CSD is unusable vs a DWD which will simply not conserve space.

DWD

So, in the end, this is the direction DWD has gone. Keep it simple, let anyone decide how it should be used, and piggyback off of proven protocols.

MPRIS2 shows what a purpose-driven protocol can do, and already has lots of examples of “remote control” interfaces. Outside of MPRIS2 we would create missing D-Bus specifications which would hopefully make the wider applications library accessible in a similar manner. Specifications for things like progress management, search, sharing, and many others could be created which will benefit applications, and allow deeper desktop integration for everybody.

For those who saw the previous designs in my original DWD blog post, not much has actually changed visually. Everything I posted is still possible, but now we have a much more practical way to do it which I am much more confident we could reliably implement and share.

Spooky Scary Post-Halloween Monster Post

With Halloween settling down and children retreating back to their lairs so they can bathe in their sugary loot, it’s time to post an update, and not just any type of post – but a Spooky Scary Post-Halloween Monster Post!

Wallpapers

Before I get to show-and-tell I wanted to make a quick digression to something we noticed a few months ago after the 5.4 wallpaper was released…

There has always been some pretty harsh criticism against the wallpapers I’ve produced, some of this comes down to being bolder and more vibrant in our designs, and some of it some of it comes down to the fact that my early work was genuinely bad. We listen to comments wherever they come from (even if we don’t specifically reply), be it a forum on a news site, Reddit, or imageboards. Until Plasma 5.3 though the criticism lacked constructiveness and was mostly just mud-slinging. The Plasma 5.4 wallpaper though must have crossed a threshold at some point, because the entire VDG very specifically noticed an uptick in constructive criticism, and a it had a heavy influence on the 5.5 wallpaper.

What this all comes down to and what I really want to say is this; do be critical of our work! But be critical in a constructive way, so we can build on your comments. Calling a wallpaper “dogshit” doesn’t give us much to work with, but pointing out the Dutch Angle of the last wallpaper as being too extreme – that we can work with and improve the next wallpaper. Since we had the feedback, I’ll go over the two main points we’ve heard.

#1: The Brightness / Saturation.
More often worded as “the author must have eaten his crayons before puking on the screen” this was a result of how I initially imitated the 5.1 wallpaper with the Breeze palette, and absolutely failed; so much in fact that I think it may have affected the perceived colours of later wallpapers.

While some people certainly enjoyed the lighter wallpapers the main comment was that the over-saturated wallpapers were too much. Interestingly, wallpapers on Plasma 5 have been trending towards darker tones, below being some swatches I quickly composed of our wallpaper history:

swatchesWhen I started making the wallpapers at 5.2 I had decided to stick with the official Breeze colour palette, which is geared towards icons. This meant that working at the same luminosity Nuno used for the 5.1 wallpaper would oversaturate mine, which is what happened. It’s worth noting that the 5.2 wallpaper was made purely for personal use, and it was only by a fluke that we used it in production. With 5.4 I think we approached the tipping-point of appropriate brightness/saturation, and I think we’re closer to the ‘right’ amount now considering out palette.

#2: The Dutch Angle / Drug Induced Wallpaper
This is a simple fix: stop using intense angles. But! If everything is made flat it becomes visually uninteresting. As a matter of fact none of the KDE wallpapers have been perfectly level, except Nunos original wallpaper which had clear vertical orientation. I think this was just because 5.4 was so extreme, and also because there were no other mounting points a user could visually register.

With the ‘acid trip’ feel of the last wallpaper, I think it was (again) the dutch angle throwing users off a bit along with the fisheye lens of the horizon line. I do worry that such a perception may impact the professionalism of the desktop, so for future wallpapers I may attempt to better avoid this moreso – though this wallpaper does maintain a more organic shape, which I expect may get dinged on that score.

So, what’s in the pipe for 5.5?

I’m very excited to announce we will be shipping 3 wallpapers this upcoming release. The two below continue the evolution seen in previous wallpapers. They are “Event Night” and “Event Day”. Event Night will be the 5.5 default.

desktopWallpaper-event-1.0-kvermettedesktopWallpaper-event-light-1.0-kvermette
Lionel Chauvins’ “Pastel Hills” will also be available, which harkens back to Nunos original design using a lighter pastel palette. I also have the feeling this is the first wallpaper we have distributed made with Blender. I highly recommend checking out his new KDE-look account if you like the smooth jazz that is his wallpaper, hopefully he uploads his other works. 😉

2560x1600

5.5 Wallpaper Contest
Finally, Andreas is continuing his wallpaper contest; the deadline is in roughly 9 days, so if you have a beautiful image you want to submit please jump in and submit your wallpaper!

KDE.org

KDE.org is undergoing a redesign which should one day present a more unified and consistent interface across the myriad of systems we currently use.

The most obvious issues with the current site are twofold; there’s no consistent navigation, and no two systems look alike. Because we have so many systems which are largely incompatible and/or on completely different hardware, we’re taking a unique approach to the new design so we can begin to unify the disparate designs.

We’re building the user-facing elements as a modular set of pieces which can be arbitrarily inserted onto any website, regardless of the technology or hardware they use, as long as they support even the most primitive skinning. These modular pieces are self-contained, and should be fairly easy to insert into existing systems until larger changes can be made.

I’ll have screenshots later (maybe a video) once I finish up a few more modules for feedback. Unfortunately I’ve had exceptionally busy weekends (when I get most of my work done) and haven’t been able to make the progress I had hoped for. I’ll post more on that later.

Fiber Browser

Because I have been swamped with smaller projects I’m temporarily going to put Fiber on hold to nail other things down, as I want to give more time to immediate smaller impacting projects across KDE as a whole, rather than constantly scrambling around several half-finished todos.

The original plan was to have a version which would be “presentable” at Sprints so I could garner interest, but that will be dropped. One thing that has become clear is that other developers will want to work on it regardless of me ‘promoting’ it, so I’m comfortable in the thought that I could assemble a small team later on. Also, the main KDE devs are busy enough anyway.

Next, after (very careful) consideration I may temporarily drop CEF and pick up WebEngine when I seriously resume the project. Fiber is a one-man band, and to say CEF integration has been nothing short of a pain would be an understatement. I feel like the most important aspect of Fiber will be a rich, deep API and modular design – but with so much focus on getting CEF functional it simply sucks the life out of the entire project. Instead, I may shift to a CEF port as a “Fiber 2.0” feature (hopefully when other devs may maintain the APIs), which should help as by then Servo will be more mature and I can test it as the primary renderer.

Unofficially I may still chip away at it – but for now I’m more comfortable saying it’s on pause while I focus on my todo list. I will resume work on it once I’ve bumped off a few smaller things, and hopefully It’ll speed up development a bit by switching to WebEngine for the 1.0 release along with having fewer balls to juggle.

Polish Effort

Before I say anything else, hats off to Hugo for his work. I’m not going to lie: I threw him to the wolves on this one (unintentionally!), and he’s solo’d the real work going into Breeze polish. So, hats off to Hugo for being blazingly awesome!

On the design notes, one thing that became apparent somewhat quickly was the fact that the design I presented began to heavily diverge from the current Breeze design, so much as to be considered a different design entirely. I’m still debating how to handle this, as this is one area where I wanted to free up time so I could more properly contribute.

In terms of stuff getting done, we’ll have some pleasing adjustments to several visual elements such as menus and pixel-tweaks. We’ve also identified several issues such as misalignments in applications, dark-theme colour woes, and inconsistent spacing; I don’t believe we have fixes in for everything, but I’m confident in my ability at throwing Hugo to the wolves. ;P

DWD

There’s not much to report here, but a couple people have been wondering about this. For those not in the know, DWD will be a protocol-driven solution for widgets in the titlebar, similar to the CSD approach that is the Gnome headerbar.

Mainly I’ve been working on the specification, and it’s been pointed out that DWD as a technology will never be suited for insanely weird and creative widgets. To mitigate this I had written some crazy crap about all the special and unique ways a widgets might be customised, and I realised it was pointless to try matching the “creative potential” of CSDs with endless options. I did a thought experiment and swung the other direction;

What if instead of offering primitive widgets with crazy tweaks DWD focused on higher-level but rigid purpose-driven widgets? You don’t request a slider with a volume icon, you request a volume widget and feed it a few channels. Instead of a lineedit you’d just put up a search box… And this approach shaped up surprisingly well.

The general mindset is the idea that CSD eschews system integration in exchange for more radical customisation. DWD on the other hand is about integration though standards – and the initial spec didn’t play to that strength. The main downside to this new spec is the fact that we do sacrifice more creativity in the headerbar, but I looked at it, and in most screenshots of Gnome CSD widgets seem remarkably standardised as well. I’ll be doing a post later which gets into details and pretty pictures but this seems to be the direction to move towards.

That’s all, folks!

sluggerfly

Random Sluggerfly!

New artwork coming in 5.4 & the tale of a troublesome wallpaper

For the past month I’ve been slightly more active than usual, and I’m excited for this release and some of the art I’ve managed to throw into the pipe;

Icons, Icons!

I would like to make a special mention that not all of these icons have been greenlit, and several of them are pending approval and may be dropped/require changes. Some were literally finished minutes ago while others have already been integrated into projects. \o/

image10430After “harmlessly” throwing in a couple monochrome icons from my personal projects, I found myself reading a few of the icon requests and one thing lead to another… Now I’ve pushed in somewhere around 25 new icons, mostly towards apps with the goal of filling in gaps of common applications. These new icons will hopefully bring a much more cohesive launcher menu, with more core and popular applications having Breezy icons.

Some of these may be shunted to an extended repo; 3rd parties get antsy when they see their logos get “breezified”, so “branded” icons need to occasionally be separated from the main repository to avoid troubles and takedown requests.

Lastly but not least; Uri and Andreas have been nothing short of awesome in helping me get these out, thanks guys!

The tale of an annoying, terrible, awful wallpaper, and How I Made it.

I’d like to say that I’m less a man and more a force of nature – one able to sweep my hand and make art bloom at will… But this would be a lie, and occasionally getting art out there makes the only force I can muster feel like a fart in the wind. The new wallpaper for 5.4 just did not want to be made, and took days on and off trying to figure out what to do. I nearly just suggested we ship a backup wallpaper I had on the sidelines.

Eventually ideas got figured out, and after an unstructured failure (again, making me look at “the backup”) I started taking screenshots while using a more structured approach. I imagine I wanted all reading this to feel my pain. Either that or laugh. One of the two. Either way, the new wallpaper was one of the more involved processes used for a Plasma 5 wallpaper, and here are the steps for how it came together;

Continue reading “New artwork coming in 5.4 & the tale of a troublesome wallpaper”

Plasma Sprint 2015

Just over 2 weeks ago I stepped off a plane, putting my heels onto Canadian soil after spending a week participating in the Plasma 2015 Sprint. The entire experience was exhausting in the best of ways, and after landing home my throughput was thoroughly trounced for some time as I settled back into normalcy. But lets rewind to the beginning;

The day of my arrival in Barcelona it would be a far cry to say I was nervous – in the moments before pressing the buzzer I was in a downright terror! These people will realise I’m an idiot! Ship me back to Canada on the next canoe! Needless to say only minutes in to the sprint not only were my worst fears completely unfounded – but I met a group as welcoming as they were brilliant.

Finally, I think I have the perspective to share my experience. I won’t try to recap the entire event, I will mainly focus on VDG work.

But first! The People of KDE

I met about a dozen dedicated and hard-working developers in the Blue Systems office during the sprint, and it needs to be said just how great these people are – each and every one passionate about their respective fields and projects. I’d really just like to give a shout-out to everyone I met in the Sprint. They’re the kind of people who make you smarter by proximity, and they welcome you to do it. For anyone invited to a Sprint I highly recommend jumping on the chance; you will be enriched for doing it.

IMAG0387_BURST001

Drawing Konquis

After arriving mid-day Jens Reuterberg headed the idea to begin creating and stockpiling promotional graphics. Essentially we wanted vector artwork which could be used easily for things like release announcements, large print materials, web pages, etc. Jens dove head-first into logotypes, and I splintered off into doing up a pair of vector Katie and Konqui graphics during my half-day; Konqui being a direct trace, and Katie being new. You can view the original graphics by the talented Tyson Tan here.

g4358

Download KatieDownload Konqui

VDG ❤ Developers

There was a great deal discussed during a pair of review and planning sessions in the first two official Sprint days. One of the biggest things (for Jens and I) was helping the VDG and developers interoperate better; for those who don’t know, the VDG communicates very differently than mainline developers.

Devs tend to focus on bug reports, mailing lists, reviewboards, and IRC. Members of the VDG tend to use Forums, Hangouts, and to a limited extent IRC. Immediately there’s very little overlap, which means at this point developers have to go to the forums to wield the VDG.

The problem lies in how forums operate; where the VDG design processes benefits from the relative chaos, it’s not good for developers looking for the ‘final word’ of the design discussion. It’s further impacted by forum conversations which don’t have definitive conclusions, or discussions which can get muddled down. When developers go to the forums they need a solid final product to build around – but on multiple occasions they end with a half dozen different designs and no clear answer on what they should do.

It was a short discussion during the Sprint, but Jens and I both immediately agreed that this is an area where the VDG must step up and refine our process.

The current idea will be sticking with the forums threads as the main creative area, but changing the way they spin down. Once we feel a design discussion has gestated, the VDG aims to have a member pull the ‘final’ design from the conversation, at which point they’ll put together a coherent deliverable developers can understand and act on, on a channel they are comfortable with.

There are still details we are ferreting out before we more formally put this into motion, but the essential aim is to move the VDG into a position where we can reliably ship usable deliverable design, on a channel developers can comfortably handle.

Breeze Applications

This only came up briefly during the Sprint as well, but is something which has been brewing for a while now – so it might be worth mentioning ‘for realsies’, essentially since I don’t think anyone pointed out that this is a ‘thing’;

KDE and Plasma have a bit of a history with names, and for many core applications we’ve been wanting a more consistent scheme for it all. At the same time, with every major tookit release (i.e. Qt4 -> Qt5) many applications need to be ported or re-written. Finally, on these major releases, visual/workflow trends have usually shifted meaning the experience of applications will also shift.

So, all this stuff going on, we figure it’s time to put a bow on it and turn this cavalcade of factors into one cohesive event, so we’ve come up with the concept of Breeze Applications.

The idea is that, coinciding with frameworks, trend, and design changes we will name a subset of the bundled applications after the current design. So for Plasma 5 we will have ‘Breeze’, for some future plasma version many moons from now we may have ‘Gust’ or ‘Wind’ applications.

What does this mean? The biggest thing is that we intend to use these ‘Breeze’ applications as standards bearers, which we hope to see other applications follow. It’s much the same way Google treats ‘Holo’ and ‘Material’, along with their base applications: This is the design, these are the examples. Ideally we intend to focus on only a few applications, which developers will be able to dissect and say ‘oh, this is the plan’. In addition, as new technologies and techniques land, we hope Breeze applications will be the frontrunners in adopting cutting-edge KDE/Plasma technologies.

Does this mean every Plasma or KF5 app will be named “Breeze X”? No. We only plan on Breeze-ifying the more simple core applications which can be easily maintained, kept up to date, and streamlined enough that the code could easily be used for reference material.

Fun fact: The bathrooms in Frankford are powered by Ubuntu!
Fun fact: The bathrooms in Frankford are powered by Ubuntu!

Dynamic Window Decorations

Before I even get started on this, I must give props to David Edmonston. The man is a trooper, and I feel almost as if I tortured the poor gentleman throughout the sprint.

During the sprint I presented some of my DWD plans; technical details were discussed, implementation questions were raised, and concerns were were round-tabled. The discussion was extremely positive and productive, and real issues were ferreted out.

IMAG0392_BURST007

One of the larger questions was ‘what IPC protocol should be used?’; I personally was educated about the Wayland protocol, and that it could be used even on ‘non-wayland’ systems – since it is just a protocol and not an installed library. Ultimately, the developers present agreed that D-Bus was the way to go, the general consensus being that the protocol is known and familiar, mature, battle-tested, and isn’t going to shift or break.

I also gave my personal thoughts on how applications might access/implement DWDs, and while there’s still considerable room for discussion, it seems to be on the right track. I was cautioned by developers and I feel the need to point out: even when the DWD protocol does pick up steam it will still be years before it’s available in any meaningful way.

During the development portion of the Sprint I managed to rope David into doing some DWD work on a proof-of-concept level. Through his efforts we now have a much better idea of what obstacles we will face integrating widgets into server-side decorations, such as ensuring the draw code runs correctly/efficiently. He heroically managed to get window decorations to draw usable sliders, so we do know window decorations are capable of drawing server-side widgets.

Sadly, the proof did nearly cost David his sanity. It probably didn’t help that I was giggling like an imbecile. Sorry about that, David. I hope the tea made up for it. :/

UI Feedback

Throughout the Sprint Jens and I were able to lend our services in helping to design and streamline interfaces. Towards he end of the Sprint we also did a walkthrough of the Plasma desktop and several components to identify surface-level bugs and weak areas.

This included an extensive review of the system settings utility and its KCMS.

I also managed to chip in some light advice with a new power-manager tool, and an upcoming redesign of the Baloo settings manager with Vishesh Handa.

And a Great Deal more!

As I mentioned at the start of the post, and can only mention again; There were a lot of really great people at the Sprint – and all of them had their own projects, goals, plans, and feedback. It was really impressive to meet people who had such a deep understanding of KDE Frameworks and Plasma, able to talk about extremely complex technologies in detail over a coffee.

I, personally, learned a great deal from everyone. From being unable to compile a package to now comfortably hacking, simply rubbing shoulders with the outstanding individuals was absolutely my privilege.

There’s a great deal not in this post, but I imagine other posts will fill in the rest… So on a closing note I will say again; if you are ever invited to a Sprint, don’t hesitate to say yes – it’s an amazing experience which is beyond worth it!

I drank this. I still don't know what it was.
I drank this. I still don’t know what it was.

How Bread is Helping Make Breeze Cursors Pixel Perfect

Some people accuse me of being a crazy person. Others are wrong. But occasionally the seeming madness of it all will bring about good things.

Last night was a sleepless night in all the good ways; I’m excited for the upcoming Plasma Sprint, and knowing I’ll be packing myself into a cigar tube and flinging myself across the North Atlantic Ocean is too much for me to sleep over. I had promised a commenter (too long ago) I would make green cursors, so I decided to make good on my word. After it took 5 minutes I needed more; and the wafting smell of my bread maker inspired me to make a Bread cursor theme. Once that was done, sufficiently delirious, I sent my weird bready message to the VDG. They appear to have ignored it – a wise decision. They’re busy people doing actual work.

bread

Today I opened up the cursors to see what I had done.  Nothing too terrible, and I decided it was worth polishing them up if just for the larfs. One of the touches was to add a half-pixel white outline between the crust and loaf for contrast.

When I rendered the tweaked cursors, they started to look awful because of how SVG images layer and clamp nearby vectors. Simply put on a vector edge, even if there’s another identical edge above it, both edges will affect their neighbouring pixels as opposed to the upper vector shape ‘blocking’ the lower shape.

sample1
The “desired result” is the result a designer would expect, while the actual result is technically correct.

This had the effect of making the hand of my newly minted bread cursor (with the most edges) look “washed out” because the two lighter inner layers were covering the outline.

sample2

The solution for this problem is to ‘supersample’ the cursors in our build scripts. Supersampling is when you render the image at a much higher resolution, and scale it down to the desired resolution. Instead of going directly from Inkscape to a final image, we first export each cursor to a temporary file which is 4x standard resolution and 2x double resolution. We then scale down and copy that image to the final resolutions.

The end result is going to be the option for us to more easily use sub-pixel detailing in cursors without worrying about losing smoothness; any extra detail may not be noticeable on a day-to-day level – but it’s the polish Plasma users are beginning to expect. Additionally, high-resolution cursors will also benefit because the half-pixel details will become full pixel details, and on a high-quality screens you’ll have ultra-sharp graphics.

breadAnd that’s how bread is helping make Breeze cursors pixel perfect!

Now, super-pixel-perfection isn’t that noticeable so there’s not going to be a rush to update existing cursors; but if one day you quietly notice your cursor is a little bit sharper than it used to be – you can thank bread.

Download The Cursors:
(extract “compiled” cursors to your icons folder to install, or download the source to edit or remix them. Golgari is a green/black theme)

Bread Source
Bread Compiled
Breeze Golgari Source
Breeze Golgari Compiled

Plasma 5.2 – The Quintessential Breakdown

header

KDE is one of the oldest open-source desktop projects which can be found today, and over the years it has established a rich history of highs and lows. During some points it has been the undisputed ruler of the desktop world, while other times it had fallen behind or faced hard trials.

A memory everything but forgotten, just over 6 years ago KDE tore itself apart in spectacular fashion to assemble itself anew. Brave users who wandered through the rubble and wreckage saw developers rebuild the KDE before their eyes, witnessing the birth of ‘Plasma Desktop’ and it’s sister project ‘KDE Development Platform’. It was universally understood that this twisted gnarled creature of a computing experience was both hideous yet full of potential, and over 5 years of refining Plasma it had struggled, crawled, hobbled, walked, run, and eventually mature into a fine desktop.

Despite becoming an accepted way of computing there has always been one nagging persistent issue with it all; KDE is old and the legacy it inherited was a knotted mess of a foundation, with over a decade of old code accumulating to encumber nearly every aspect of the system. Software could not be written to use KDE Development Platform without pulling in so much baggage, and like a bundle of cords or strings there was no chance of pulling one from the mess without receiving the entire ball of twisted tangles; even a simple media player could bring in nearly all the legacy materials, even when used outside the Plasma desktop.

KDE developers knew what had to be done and set into motion years ago a complicated, time-consuming, and challenging goal: “we must untie the knots”. With a looming Qt5 transition on the horizon (the underlying toolkit used by KDE) developers saw their opportunity to untangle the ball as they ported to the next Qt.

But there were fears, warranted fears, that this process would again lay waste and pervert the now solid Plasma Desktop, people fearing they would be forced to decide between their beloved systems with an expiry date, or a new era of painful unfinished instability. The developers had a different plan in mind; a silent revolution planned to pass silently with little fanfare, as the underpinning foundations are churned into a sleek and modular framework which could be as loved as the desktop which used it.

“We must untie the knots.”

That day has already come and passed; dubbed “KDE Frameworks 5” for the technology, and “Plasma 5” for the environment/applications, these technologies have been in circulation as technical demonstrations and alternatives for some months now. A combination of nervous anticipation and memories of being burned by the 4.0 releases lead all but the bravest to venture early and discover nothing nearly as painful as the transition between KDE 3 and Plasma. With KDE Plasma 5.2 being formally announced as the default environment of Kubuntu 15.04 due only months away, Frameworks 5 and Plasma have been recognised as maturing usable products – which means it’s time to take a serious look at what to expect when you turn it on for the first time.

For the sake of simplicity I will be referring to KDE Plasma Desktop as “Plasma 5.2”, KDE Frameworks 5.6 as “Frameworks 5”; most regular people don’t need to know the exact version of the frameworks, and this review will be focused on the experience of the Plasma 5.2 desktop as it feels today. Some parts of the Plasma 5.2 experience are holdovers from Plasma 4, but I will cover them all the same should new users wonder if the hand-me-downs of the previous generation desktop gel with the new experience. I won’t be covering most technical issues in this breakdown; there are several that I had, however I’m using Beta software on an Alpha operating system – technical issues are to be expected which won’t impact final releases.

Curses! … I mean, Cursors!

cursors

In the upcoming release of Plasma we’ve done some work on the humble cursor; we’ve added a few missing states, and there will also be a brand new “snow” version, along with minor tweaks to the existing Breeze cursors. But me being lazy and the merge window having closed, there are a great many more cursors which haven’t made it into this release, so I’m putting them here for everyone to use and redistribute.

All of the cursors I’m posting will have 2 versions; the source and the compiled versions. Download the source if you’d like to edit, remaster, or improve the icons – build instructions are included, and our build script has been significantly improved and should be pretty easy. If you just want to use the cursors download the compiled version and simply extract them right into your icons folder (usually found in /usr/share/icons/) and enable them in your control panel.

Standard

Not much has changed, but if slightly softened shadows and diagonal cell-sizing cursors are important (or you just don’t have the default cursors) then here they are;

Breeze (Source)
Breeze (Compiled)

Contrast Cursors:

Probably the most important cursor set I regret not getting into this merge quickly enough is a new contrast style; so if you or someone you know is a visually impaired user, I’d like to offer this new cursor set. I can’t claim to be visually impaired myself, so if there is a user who is visually impaired I would like feedback on this particular cursor set and its usability. It also comes with an extra-large size as well.

Breeze Contrast (Source)
Breeze Contrast (Compiled)

Hacked

Hax0r3d! Some people love it, other people hate it; here’s a colour-matched cursor to accompany the “Ghost” “hacker” style.

Breeze Hacked (Source)
Breeze Hacked (Compiled)

Obsidian

Is the dark default cursor not dark enough?

Breeze Obsidian (Source)
Breeze Obsidian (Compiled)

Snow

This was a widely requested style; white Breeze cursors! These cursors will be in the upcoming plasma release, so if you’re upgrading, you can skip installing them.

Breeze Snow (Source)
Breeze Snow (Compiled)

Other Colours

Amber, purple, blue, and red… ‘Nuff said.

Breeze Amber (Source)
Breeze Amber (Compiled)

Breeze Purple (Source)
Breeze Purple (Compiled)

Breeze Blue (Source)
Breeze Blue (Compiled)

Breeze Red (Source)
Breeze Red (Compiled)

DWD – a FAQ for questions around the Web

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!

Presenting DWD, a Candidate for KDE Window Decorations

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!

What if… KDE Used Windows 10 Design Components?

A study of what-if scenarios which posit what KDE would look like if it took a different approach to certain aspects of design. Note that these posts are in no way “the direction KDE is going” and are simply a study done to reference designs and ideas we may never have investigated.

Forward

First, a brief overview of Windows 8;

Windows 8 was Microsofts’ first step towards creating a unified ‘experience’ between the range of products running Microsoft Windows. Before Windows 8, early tablets which ran Windows typically ran a traditional Windows desktop; because desktop Windows was designed for mice, it typically required a stylus, trackball, or other similar input; keyboard solutions were universally sub-par. Microsoft ideally wanted its mobile audience to use laptops and phones instead of tablets. Apple and Google later devoured the tablet/phone market with iOS and Android respectively, and touch-screen devices became the norm. With their advantage in touch input, these two systems grew into tablets. This left Microsoft in a bind; Windows mobile was not capable of delivering a capable experience, so instead of taking the route Android and iOS did (growing their OSs’ up) Microsoft decided to begin shrinking its more capable desktop OS down. Windows 8 was the first step in this process, and essentially laid a touch-centric layer on top of a traditional desktop OS. The end result was an OS with split personalities and it required desktop users to work around touch components, while mobile users more/less had a decent – but more limited – experience.

Windows 10 is Microsofts’ attempt to correct the design flaws of Windows 8; Mainly by allowing the interface to vary between form-factors, such as including a start menu and introducing a multi-desktop mode.

Consumption vs Work-Oriented Design

In terms of design, Windows 8+ has a much more consumption-oriented design, as opposed to a work-oriented design; and it has a large amount of data throughput even in the main menu. This is appealing to mass-market users who desire quick access to information, and the ability to quickly act on it. For example, the twitter live-tile not only shows the latest updates, but is a one-click access point to that data. We don’t have that efficiency; we can launch applications, or display plasmoids, but we don’t have an efficient solution that does both. On the other hand, users have complained that the live-tile interface can become chaotic, with literally dozens of tiles calling for attention.

Desktop Linux and KDE have traditionally kept towards work-oriented designs, and consumption efficiency is left in the hands of the applications. This is trouble for KDE, because we don’t bundle simple applications which other environments do; i.e weather, maps/directions, or a clock/timer/alarms app. We do keep these as desktop components, but instead of simply launching applications, KDE requires a user to use complex editing tools to add and configure those widgets. In addition, if we did bundle those applications plasma widgets still do not launch relevant applications; our weather plasmoid does not launch a weather app, our photo widget does not launch a gallery. This poses another problem because a user must also know how to create a dash with independent widgets and know how to invoke that dash if they do not wish to crowd their desktop with plasmoids.

One way this could be solved would be creating a class of “launcher widgets” which are read-only QML widgets the system would treat as icons. Additionally, we might create a new file-level protocol for a QML “icon widget” format which could enable dynamic icons for application launchers. For example, a weather app might have a QML-based icon which displays todays’ weather. Though this could cause serious performance ramifications if implemented poorly, and adds dramatic complexity to simple file-browsers.

It should be noted that you can launch plasmoids in KDE through KRunner, but this method is pretty much inaccessible for regular users. This feature is much more slanted towards development than actual real-world usage.

KDE should consider allowing widgets to flag themselves as being “launchable” – allowing them to be launched similarly to applications from a proper applications menu. Sometimes you need to make quick notes about something without the need to save files or open the “KDE Advanced Text Editor”. Maybe you just only need the dictionary once in a blue moon. Allowing these to launch as KDEs’ version of “modern apps” might be highly beneficial, and give access to KDEs well-designed plasmoids without the need to modify the desktop. Also, our container application which actually contains the widgets could offer buttons to do things like quickly add the app to the current desktop, panel, or dash. This could later be integrated into Martin Gräßlins’ server-side-decorations.

The notes plasmoids - launched as an application
The notes plasmoids – launched as an application

While a great deal of applications are being written in QML, launchable plasmoid applications for KDE might be a good option when use-cases are simple-enough to be desktop-ready, but still useful enough to work as ‘standalone apps’. This might also make plasmoid development more attractive to developers who work more in traditional applications. Things like maps, directions, notes, cloud-based services, contacts, and other simple utilities – especially those which piggyback off the system – would be especially viable if developed under this model. Not only would we have our own ‘metro apps’, but these ‘Plasma Apps’ would be incredibly flexible in their ability to integrate to the desktop.

The dictionary plasmoids - launched as an application
The dictionary plasmoids – launched as an application

Start Menus

The Windows 10 Start menu has embedded live tiles. For plasmoids which aren’t big enough to be launched as applications, or not used consistently enough to be placed on the desktop or in the panel, Plasma could offer a launcher that has an embedded widget tray, or offer pop-up containments which could house collections of plasmoids.

Embedded widgets in a start-menu like launcher
Embedded widgets in a start-menu like launcher

Technical Challenges

For the most part, Plasma is already flexible enough to allow us to extend plasmoids into ‘Plasma Apps’. As a matter of fact, the plasmoid preview utility used by developers already gets us most of the way there. For the most part, there’s no real (obvious) technical hurdles.

One design aspect would be making a ‘native’ plasma theme for plasma running in an application mode.

Pros

  • Launching plasmoids as applications offers extreme occasional-use convenience.
  • Ensuring widgets can easily launch related full applications fits the “simple by default, powerful when needed” mantra.
  • Application developers might be more interested in plasmoid development when KDE users could launch it as a ‘real app’
  • It would help fill KDEs’ need for simple applications.

Cons

  • Users might not appreciate their program lists getting filled with plasmoids, especially if they can’t be hidden.
  • Plasmoids looking to be used as applications would need to account for more static contexts or alternate storage locations.
  • Everything listed here would add redundant applications to the system.
  • If plasmoids launched generic types of applications, we would need tonnes of default application types; default weather, default stock ticker, default dictionary, etc.
  • Applications lists would need to be overhauled to display plasma-apps.
  • Adding widgets to widgets (for the ‘start menu’) would need a clever editing UI, adding complexity.

Notes

Overall, the main issue KDE has is the disconnect between simple applications and simple plasmoids. KDE does have the functionality of other desktops in plasma, but it can feel more cumbersome to access it, especially if it’s in a situation where you may only need it on occasion. Plasmoids like the dictionary are the perfect example of this; I know no-one who refers to a dictionary often enough to constantly need one, but I can also say everybody likely needs one on occasion. For me, launching a browser and doing a Google search is faster than digging out the plasmoid. I don’t use the dash either, but even still do we want the KDE dash to be the junk-drawer of occasionally used widgets forever?

I found that adding live tiles was beneficial to the start menu, as it does become a simple notification area; I think it would be beneficial if we were capable of embedding widgets into launchers or secondary ‘container plasmoids’. I think KDE did do this at one point – can anyone let me know? I also think launching applications by directly clicking on plasmoids should be added; opening a full weather application would be great if we could package them together, and the same goes for stocks, maps, etc etc.

Chime in!

What are your thoughts on creating a more consumption-oriented design? What did I miss, any addendums? Let us know!