Planet KDE

Syndicate content
Planet KDE -
Updated: 22 hours 21 min ago

Put LXQt to work on Fedora 21 and epel 7

Tue, 2014-10-28 19:35

After i joined RedHat on some time ago, i slowly start to been involved more and more on Qt and KDE matters, even been more active joining Fedora KDE SIG,  as a newbie :-).

One of the recently internal discussions lead to a necessity of bring lightweight desktop, at least one, in a polish state.

Since LXQt is finally came on 0.8.0 to Qt5, and we’re actively working on Fedora 21, Qt5 builds and KDE Frameworks,  and there are needs to jump and do at least the first usable state of the project, i jumped the wagon.

Eugene Pivnev was already working on initial packaging for Fedora, but i was advanced in the work when lead DKE packages from Fedora Rex Dieter told me, but at least i could use part of his work on sysstat packages and qtxdg packages. I borrowed his full packages.

was only two days of work and is still in the baby steps, that’s why i packaged everything on Fedora copr buildsystem until we have proper review. We still have no group for install whole desktop and need to install packages by hand, and there’s an explicit dependency on openbox as window manager, but was a quick decision to make things work fast.

I’m still deciding how to deal with lxqt-admin package due some dependencies, but is the only missing from the 0.8.0 series on

So, if you want to try it, recompile, help me, complain to me, you can find the work here:

For the repository on copr:

  • Fedora 21 – dnf copr enable heliocastro/lxqt or yum copr enable heliocastro/lxqt
  • Epel 7 – yum copr enable heliocastro/lxqt 

Ps. I will not intend to compile/enable Qt 4 builds, only Qt 5 build because this is the direct goal

Categories: FLOSS Project Planets

Accessibility is alive (QtSpeech progress, Jovie's deprecation)

Tue, 2014-10-28 18:05

For some time I've been considering what to do about Jovie which was previously known as ktts (KDE Text To Speech). Since before the first KDE Frameworks release actually, since kdelibs used to host a dbus interface definition for the KSpeech dbus interface that ktts and then Jovie implemented. I have a qt5 frameworks branch of Jovie, but it didn't make much sense to port it, since a lot of it is or could become part of the upcoming QtSpeech module. So Jovie has no official qt5 port and wont be getting one either.

What will Okular, KNotify, and other applications that want to speak to users do instead? The answer is QtSpeech. QtSpeech is a project started by Frederik Gladhorn to bring speech api's to all the platforms that Qt supports. It is still in its infancy, but is quickly improving. A few weeks ago when I built my kf5 stack with kdesrc-build I noticed that kdepim(libs?) was depending on it and it hasn't been released yet, so I got motivated to send some improvements to qt-project. Frederik and Laurent Montel have been pushing fixes and improving it also. It is as easy if not easier to use than the KSpeech dbus api (and doesn't require dbus either) and can be used to speak text on linux/unix, osx, windows, and android platforms so far. If you are an expert on any of these platforms please send patches to implement api on these platforms in their backends, the more eyes on this project the faster we can get it solidified and released.

You may be asking but what about feature X in Jovie that I will miss desperately. Yes there are a few things that QtSpeech will not do that Jovie did. These will either need to be done in individual applications or we can create a small framework to add these features (or possibly add them to QtSpeech itself if they make sense there). The features I'm thinking of are:

1. Filtering - Changing ": Hey QtSpeech is really coming along now" to "jpwhiting says 'Hey QtSpeech is really coming along now'" for KNotifications and the like. This could likely be implemented easily in knotify itself and exposed in the notifications configuration dialog.
2. Voice switching - Changing which voice to use based on the text, or the application it is coming from or anything else. This might make sense in QtSpeech itself, but time will tell if it's a wanted/needed feature.
3. User configuration - Jovie had a decent (not ideal, but it was functional) ui to set some voice preferences, such as which voice you wanted to use, which pitch, volume, speed, gender, etc. This will become the only part of Jovie that will get ported, which is a KDE Control Module for speech-dispatcher settings. This may also change over time, as speech-dispatcher itself possibly grows a ui for it's settings.

All in all, progress is being made. I expect QtSpeech to be ready for release with Qt 5.5, but we'll see what happens.

Categories: FLOSS Project Planets

Work in progress

Tue, 2014-10-28 17:54

So what's happening since last release one month back? If you look only at source code evolution, you may think I already entered hibernation... not completely!

I've been following the packaging progress of the new release, to be sure I didn't miss something as for my first time (re-shipped UI translations and docs; and there is a new MLT dependency due to stabilizer change).
I'm also keeping an attentive eye on bug tracker and forums, to be sure nothing is breaking in users hands due to small changes introduced. Some very active Kdenlive fans already do a wonderful job, sometimes I feel I can add something, knowing the program's internals and backends.

In parallel, I'm trying to make some progress in migration to KDE project...
For what purpose? With better words than mine, the KDE manifesto explains the advantages of being part of such a wide community. Important aspects, regarding Kdenlive history, is long-term access to all the data, and mutualizing efforts not only for coding but also for services hosting (homepage, forum, mailing list, bug tracker, build bot), and for documentation and translation teams, etc.
The process is going on, with most data transferred to KDE servers, and completing the incubation steps one by one.

Last but not least, I'm spending lot of time in the code... but not writing a single line!
As discussed several times, the first step towards Kdenlive evolutions is code reordering/cleaning/refactoring. So I am studying the existing code (big parts I've never read entirely, only jumping at lines pointed by backtraces or analyzers...) and the unfinished refactored code from previous years. I'm taking notes, considering how to join both ends, and not far from starting to put my mess!
If you have advice on methods or tools for this step, please share!

Categories: FLOSS Project Planets

Ceph Developer Summit 2014 - Hammer

Tue, 2014-10-28 13:39
The Ceph Developer Summit (CDS) for the next major Ceph release called Hammer started today some hours ago (2014/10/28). It's again a virtual summit via video conference calls.
I've submitted three blueprints:
We already discussed the Ceph security and enterprise topics. You can find the results/logs in the pad. The sessions are recorded and will be available afterwards.
If you are interested in Ceph development: now it's time to join the video conference call. You can find all links, the timetable and blueprints to discuss here. There will be a second track with a lot of interesting discussions tomorrow.
If you are interested to work e.g. on the Ceph security topic: check the pad and feel free to contact me.
Categories: FLOSS Project Planets

Communicating from Plasma 5

Tue, 2014-10-28 11:29
Porting KDE Telepathy to Qt 5 and Plasma 5

I started working on that port back in the last KDE Telepathy sprint in Barcelona last April. Back then, I started to work on it because I have been doing heavy usage of the KTp plasmoids back when using the KDE 4 Plasma series and I didn’t want to live without them. Back then, I only ported the minimum parts of ktp-common-internals so it would work with KF5, as well as the plasmoids. It was quite some work, but definitely worth it since I’ve been using them ever since, and it’s worked wonderfully.

Last week I started working on those ports again, this time trying to start get all of them ready for end-users, first step being starting to port the rest of modules. It’s worth mentioning how good the response has been, given that many people chipped in and gave some modules a go. It’s a bit weird to do this kind of porting in KTp, because there’s tons of little repositories to port rather than a big one, but I guess it’s kind of part of it’s beauty anyway…

KPeople as a KDE Framework

KPeople is a Framework for fetching contacts from different sources (Telepathy, Akonadi, Facebook, etc) and unifying them into a same model,

An important part of making sure all of KTp works is ensuring that its dependencies are up to speed and this time the one I’d like to bring some light to is KPeople. The port is ready really, only depending on having some of its own dependencies from kdepimlibs in a releasable state, but it’s also quite in shape too. It’s a framework I’d really like to see shining in the next months.

Furthermore, I finally managed to find some time and get the automatic contact merging back on. This I started more than a year back and then Franck Arrecot worked to make some GUI interface for it, I think it’s quite interesting. Take a look into it if you think it’s interesting.

We need you!

Last but not least, there’s still lots to be done. I’d like to aim for a nice and clean release of KTp by the end of the year, ready to be shipped with Plasma 5.3 and the applications, if the maintainers allow so.

So if you’d like to help, you can take a look at this Kanban board we created and take the tasks you’d like.

Categories: FLOSS Project Planets

Window decoration themes in KDecoration2

Tue, 2014-10-28 08:37

Most of the window decorations available for KWin are not native decorations but themes for a native theme engine, such as deKorator, Smaragd, QtCurve or my own Aurorae. Themes are much easier to design and to distribute than a native decoration which has to be implemented in C++ and be distributed by the Linux distribution. Thus themes are an important part of the decoration system.

But we did a very bad job of integrating the themes into our configuration system. The configuration system only knows about native decorations and doesn’t know that the native decoration is in fact a theme engine. This makes selecting a theme difficult, because a user has to first select the theme engine and then configure this to select the theme. Downloading new themes through GHNS is also difficult as again it requires to go through the configuration of the theme engine. We can do better.

With Aurorae I tried to address some of the problems by extending the configuration system to know about Aurorae, to be able to find the themes and render previews for it. This only worked because Aurorae and the configuration module are in the same source tree and could share code. Nevertheless it needed to have multiple code paths in the configuration module to load the native themes, Aurorae’s SVG themes, Aurorae’s QML themes and to render the three different kind of themes.

The solution works for one theme engine, but others are still not supported. Which is something I find very sad as it turns the theme engines to second class citizens and also looks bad as my theme engine has full support while others don’t, while doing as a good or even a better job at themeing than Aurorae.

When I started to think about KDecoration2 and started to draft the API design I wanted to make sure that theme engines become a first class citizen in KWin. Last week I started to port the Aurorae theme engine to KDecoration2 and added the missing pieces to make KDecoration2 fully theme aware. The configuration of the selected theme is moved into the framework and the selected theme is passed to the native plugin when a Decoration gets created.

As a result of this work the command line options for kdecoration-viewer changed to:

kdecorationviewer [plugin] [theme]

which allows us to load for example the plugin for Aurorae with one of the SVG based themes:

To announce support that the decoration plugin is a theme engine, the decoration plugin has to put some information into the JSON meta data:

"org.kde.kdecoration2": { "themes": true, "defaultTheme": "kwin4_decoration_qml_plastik", "themeListKeyword": "themes" }

If the value for themes is present and true the framework will pass theme information to the Decoration. The framework looks in its configuration for the theme to be used, if there is none it falls back to the defaultTheme from the JSON meta data. The configured theme is passed to the Deocration when being created through KPluginFactory::create which takes a QVariantList as argument. As first element the framework passes in a QVariantMap with a key/value pair of “theme” as key and the configured theme as the value.

The last value of the meta data above is themeListKeyword which is used by the configuration module to locate all themes and provide them. I have not yet finalized the mechanismn so this is still experimental code. The keyword is used to create a different Object through the KPluginFactory. Righ now this is a QObject with a QVariantMap property called “themes”. Each key is the user visible name and the value is the internal plugin name. That’s enough information for the configuration module to create a dedicated instance for each of the themes, create a preview for it and properly load/store the information. It allows us to have a configuration module which currently looks like this:

This new configuration module does not have any Aurorae specific code any more. It just knows about plugins and themes and can display them all. As one can see in this screenshot the KCM does not need to know whether it’s a QML based theme (e.g. Plastik) or a SVG based theme (all the others). Which is a nice improvement to the situation before.

The mechanismn for locating the themes will probably change and be moved to KDecoration2 directly. It needs some more tweaks to expose GHNS information and support looking for new themes and deleting existing themes. So there is still a little bit of work to be done. But overall the state is now looking really good and I will soon start the review process for the new API so that KDecoration2 will land in Plasma 5.2. Of course that will be faster if we get more help to finalize the last missing pieces.

Categories: FLOSS Project Planets

Shared Values ⇒ Shared Ideas? What we can Learn from Firefox Australis

Mon, 2014-10-27 21:00

If you’re asking yourself “Huh? Australis? Is that edible?”, then let me explain: Australis is the codename of the new user interface that was introduced with Firefox 29 (see the Article on the Mozilla UX Blog for some background).

Australis is the result of years of design and prototyping iterations, which were lead by the recently defined Firefox Design Values. Of those values, especially one looks quite similar to the KDE design vision/motto/slogan/tagline/mantra (yes, it has been called all that!) that I described in my last blog post and which is described in more detail in the “Design Vision and Principles” page of the KDE HIG (though I swear to Stallman that I hadn’t read the Firefox Design Values when I came up with that tagline):


Balances power and simplicity – Firefox is simple and easy to use, clean and straightforward in its design. But simplicity is a means, not the end – the end is understanding and user-agency.


Simple by default – Simple and inviting. KDE software is pleasant to experience and easy to use.

Powerful when needed – Power and flexibility. KDE software allows users to be effortlessly creative and efficiently productive.

Though not identical, these values are very similar in their meaning: Both the Firefox and KDE User Experience teams aim for a simple overall user interface, which still offers easy access to powerful features for those who need them. The similarity becomes clear when one compares what I’ve outlined in the aforementioned blog post with the principles which the Firefox UX team derives from that value:

80/20/2: default to surface minimalism and easy access to the rest

user-agency and understanding, not just less

Even though neither of us blatantly copied the other (they were first, but I only became aware of that document after we wrote ours), the similarity isn’t purely coincidental, either: Both KDE and Mozilla have started off from a quite tech-savvy user- as well as contributor-base, and both aim to reach a broad(er) audience without taking the powerful features which advanced users need away from them.

And – not surprisingly either – both groups came to a similar conclusion for how to solve this dilemma: Putting those things which most people use regularly on the main user interface, while offering well-integrated access to the more advanced and/or less frequently used features. In the Australis UI, there are three tiers of access to features (from most to least frequently used): The toolbar (actually, also the tab bar, but for the sake of simplicity I’ll just subsume both under “toolbar”), the button menu and the (hidden by default) classical menu bar.

However, the tricky part is that for many applications there isn’t “the normal user” and “the advanced user”, and therefore there isn’t “the normal feature” or “the advanced feature”. The same person can for example be a power user for graphics software who needs a very powerful tool for their job as a designer, but at the same time be an absolute novice when it comes to software development tools, because they have only just started teaching themselves some basic programming to be able to whip up some interactive prototypes.

A browser is one of those applications: It’s an application which every user with an Internet connection uses (with the majority using it every day they use a computer), which many use “casually” but many also use for highly sophisticated tasks (and in case of ChromeOS even for pretty much every task). Therefore there is no chance to say “An average browser user uses this and that feature, whereas an advanced browser user uses this and that feature”. The same goes for frequency of user scenarios: Some people use their browser mostly for reading on websites, others use web applications more often than “plain” websites, web designers/developers frequently use highly specialized tools.

So what did the Firefox UX team do to accommodate to that uncertainty? They made the user interface highly customizable, allowing users to populate both the toolbar and button menu with whatever UI elements they wish, as well as to rearrange the elements within each area freely. This means that users can adapt the UI to their personal usage patterns. And even UI elements that are created by addons are treated just like the ones that ship with Firefox by default.

What my Firefox looks like in Customize mode – And yes, I’ve put the search bar in the friggin’ button menu, because I mostly use web shortcuts instead!

Is this high degree of customizability worth the effort for every application? Certainly not. For applications which are only rarely used or for which usage patterns are indeed highly consistent across users, a static user interface works just fine and has the big advantage for users that if they forget where a certain function is, they can consult the documentation or ask someone else, both of which are not possible if they can decide where to put it.

However, for applications which are used frequently and for which usage patterns vary between users, a flexible user interface solves the problem that even the best user research and most carefully designed default user interface cannot accommodate to the users’ idiosyncrasies. And even though some companies or designers may have made some people believe that an option is always a sign of bad user interface design, one of the dialog principles laid out in section 110 of the ISO 9241 (“Ergonomics of Human System Interaction”) is still “suitability for individualization”.

So, for all who feared that somehow KDE now decided to be “like Apple” or “like GNOME”, which translates for them to “Not giving the user any options”, fear not: In those cases where it makes sense, a flexible UI is precisely the embodiment of “Simple by default. Powerful when needed.”

Filed under: KDE, User Experience
Categories: FLOSS Project Planets

Beyond the color pickers

Mon, 2014-10-27 04:24
KDE Project:

Andy, Thanks so much for picking up the topic of color pickers (pun intended).

I'd like to add to the topic by discussing cases when accuracy is not as important at results. In this case there's a problem of abundance of choice. You don't have time to quickly and correctly pick one from the 16777216 colors. Plus alpha value? Come on! Whenever you're confronted with a photoshop/gimp-like color picker you either choose random color, or single color that's globally predefined in a palette. I also understand that very few 'casual' users maintain own palettes for consistency.

What's worse, for subsequent choices of colors, the same difficulties repeat with various level or annoyance. I know advanced users sometimes add currently picked the color to a Custom Colors table of the color picker, but that's all.
(Andy covered the color swatches topic, that's a clear improvement). The table as it's present in KDE apps and other apps, is global per your OS account, so context-less, as if it was designed in hurry. It comes from old Windows software, early 90's. The context is not even at application level, and obviously not related to the project you're working on. (BTW, this is why I think the story of KDE Activities would better start at (smart) apps level not at desktop level)

I'd like to mention there are other approaches. I mean especially themes, explained on my blog 3 years ago:

So the themes can address the problem of abundance of choice. In one go you can pick a color set, and application can use it to apply defaults to your document title, heading, maybe some background. Possibilities depend on what the content is for given application.

Second thing is live previews, something that benefits from the power of themes. Without them you pick a color without seeing the context. Picking your selection in a 10 pixels box is not the same as observing it temporarily applied to the destination area (filling an object's backgound, setting text color, etc.). So very the same blog mentions Document themes selector picking MS Office 2010 as an example:

You try the selection by hovering your mouse pointer and you immediately see the live preview. As engineers and they say it's hard to implement. That shouldn't stop us. I believe such concept can play well with side context panels we have already documented in the HIG.

All that, naturally depends or application, but the usefulness is beyond of the color picking. One can imagine color theme for widget style can pick the colors (and paragraph settings, font settings, by the way) from the theme.

For all this to work, we need developers that are willing to apply the concept to their apps. And an organized effort to avoid dozens of app-defined, incompatible theme notations/definitions floating around. Ideally, the place of favourite theme(s) is the KDE system settings. For me that's not just a proposal without a follow up, Kexi will be applying it at one point.

Comments? Please share them on the VDG forum.

Categories: FLOSS Project Planets

Start your Season of KDE engines!

Mon, 2014-10-27 03:32

Season of KDE (#SoK2014) was delayed a bit, but we're in business now:

Please stop by the ideas page if you need an idea. Otherwise, contact a KDE devel you've worked with before, and propose a project idea.

Once you have something, please head over to the Season of KDE website: and jump in. You can begin work as soon as you have a mentor sign off on your plan.

Student application deadline: Oct 31 2014, 12:00 am UTC - so spread the word! #SoK2014

Go go go!

Categories: FLOSS Project Planets

Testing A11y in Plasma 5

Mon, 2014-10-27 03:09

I made the jump on all available computers, and am now running Plasma5 on the foundation of Kubuntu 14.10 everywhere. Once the upgrade work was done, I filed a few bugs, and then wanted to test accessibility (often abbreviated a11y), since Qt5 has a11y built-in.

Jpwhiting in #kde-accessibility found Frederik's blog:, where I found that the key was setting up the environment to expose KDE software to the mostly-GNOME a11y applications. For now this must be done via the commandline:

gsettings set org.gnome.desktop.a11y.applications screen-reader-enabled true

It is a work-around, but it works!

Once orca is installed, and the environment is set up, you will hear each letter as you type, and when you open menus, they are read aloud. I understand it will read IRC channels aloud, but I don't want this! Some people use this method to study while they do something else, which sounds cool.

KDE developers, please test your ported code for accessibility. If you don't have time, please ask for testers to file bugs.

Distro testers, please test your install screens and upgrade paths for, at the very least, successful screen reading. There is really is now no excuse to keep blind users from using our wonderful software.

Qt 5 is accessible! Are we using it to serve our blind users?

Categories: FLOSS Project Planets

KDE makes Qt

Sun, 2014-10-26 17:36

Recently I was trying some statistics on the qtbase-module (where QtCore, QtGui, QtWidgets and so on lives) and was wondering who made them.
Not based on their current paid affilation, like Thiago’s graphs, but if each commit was made by a person coming from KDE.

So, I got hold of Thiago’s scripts, a lovely mix of perl and zsh, and a QtBase git repository. First steps was to try to classify people as person coming from KDE or not. Of course, I’m a KDE person. Thiago is a KDE person. David Faure is a KDE person. Olivier Goffart is a KDE person. Lars Knoll is a KDE person.

By the help of the KDE accounts file, and some of the long time KDE contributors, I got after a half day of work a good list of it. Then next steps was trying to put it into Thiago’s perlscripts

All of it kind of succeeded:

So, KDE people makes up for 40-60% of the weekly commits to QtBase. This is again shows that KDE is important to Qt, just as the reverse is. So, let’s keep KDE healthy.

KDE is running a end-of-year fundraiser over here Go ahead and donate, and help KDE stay healthy. For your own sake. And for Qt’s.

Categories: FLOSS Project Planets

FOSDEM 2015 Desktops DevRoom Call for Talks

Sun, 2014-10-26 16:38

FOSDEM is one of the largest gatherings of Free Software contributors in the world and happens each February in Brussels (Belgium). One of the tracks will be the Desktops DevRoom (formerly known as “CrossDesktop DevRoom”), which will host Desktop-related talks.

We are now inviting proposals for talks about Free/Libre/Open-source Software on the topics of Desktop development, Desktop applications and interoperability amongst Desktop Environments. This is a unique opportunity to show novel ideas and developments to a wide technical audience.

Topics accepted include, but are not limited to: Enlightenment, Gnome, KDE, Unity, XFCE, LXQt, Windows, Mac OS X, software development for the desktop, general desktop matters, applications that enhance desktops and web (when related to desktop).

Talks can be very specific, such as the advantages/disadvantages of development with Qt on Wayland over X11/Mir; or as general as predictions for the fusion of Desktop and web in 5 years time. Topics that are of interest to the users and developers of all desktop environments are especially welcome. The FOSDEM 2014 schedule might give you some inspiration.

Please include the following information when submitting a proposal:

  • Your name
  • The title of your talk (please be descriptive, as titles will be listed with around 250 from other projects)
  • Short abstract of one or two paragraphs
  • Short bio (with photo)
  • Requested time: from 15 to 45 minutes. Normal duration is 30 minutes. Longer duration requests must be properly justified. You may be assigned LESS time than you request.

The deadline for submissions is December 7th 2014. FOSDEM will be held on the weekend of January 31st-February 1st 2015 and the Desktops DevRoom will take place on Sunday, February 1st 2015. Please use the following website to submit your proposals: (you do not need to create a new Pentabarf account if you already have one from past years).

You can also join the devroom’s mailing list, which is the official communication channel for the DevRoom: (subscription page for the mailing list)

– The Desktops DevRoom 2015 Organization Team

Categories: FLOSS Project Planets

Color Pickers

Sun, 2014-10-26 15:25

Hello there!

It sure has been a while since the last post that I shared. A lot has gone through but all for a good cause. KDE design team is maturing and keeping the conversation alive in the forums. This is really good, now we are moving to more specific ideas on design now that the main widget style is done. We have worked hard on offering guidelines and ideas to other developers that might want to apply the principles that the team is coming up with. This has led us to work more closely with developers. Many of them are very enthusiastic about the work that we do.

In this regard, I offered to propose a new way or method that we can use for the KDE Color picker. We have a few ways that this was done in the past and maybe it can be improved. KDE currently uses this from the KColor Chooser


I like the way that this works, depending on the color you choose on the left and vertical bar you can save, enter values, choose different palettes. However, this is not the “only” color chooser/picker out there. We can examine a few more to get an idea where UI design has taken the color picker in other platforms.

OSX: It has a few color choosing modes at the top, a dropper in the shape of a magnifying glass and also an extensible custom color saving area. You get value numbers but through the rest of the modules. A cool feature is the ability to pick out a color with the dropper from anywhere on the screen independently from the application you are in. A limitation that other color pickers have.

Windows: Sorry to post this here, but it has to be mentioned. It must be said that they don’t dive into color a lot. Their pickers are generally very stripped down. Win 8, for example offers this for  their theme selection. It is a very simple one, with pre-selected colors in the squares above, you have to just slide the knob to what shade you want and the system will give you a more targeted selection above.

Beyond working with a native OS color picker, there are many others that people use. I personally like using Adobe products that generally show a color picker that is a bit more complex to learn. It is not the same behavior across all their applications but it is something that can be learned. I also use color pickers that work with swatches. I feel that you can simplify your work so much more through the use of swatches. Inkscape, GIMP, the Adobe Creative suite and many others all use swatches. It is only natural, especially when you have commissioned design work that must stick to certain colors and you don’t want to enter each element’s color manually every time. But enough about me. Let’s take a sample case in which a casual user might want to take advantage of the color picker.

“BOB” works on the computer regularly, emails, browses the internet and has recently become adept at editing images for fun. He has been through a few family albums and this has also led him to work closely with color. Bob is by no means a power user, but likes configurability, simplicity and extensibility. Current color picker options have given Bob the ability to use the color wheel with all the pixels that can be represented on the screen in a 64 bit machine. He has been given a selection bar for the color family he is looking to work with and an area to enter his precise values as well as another area where to save them. He has not been given a universal swatch option or ways that he can bring in new swatches or palettes from the internet or even a method to publish the new ones he has created. But Bob has not really thought of the use that his creations could make so he doesn’t really feel the need to contribute his creations. He is happy where he is at and the color picker appears to be more than enough for what he uses it. Yet, there does not seem to be extensibility in this picker. Bob has used a few operating systems and apps that offer color selection and they all show similar conventions.

As we examine the case, I would say that the color picker generally feels that way. Like a tool that you adapt yourself to and generally does not feature a lot of extensibility. Its UI can’t be tweaked. But the variety in organization is different depending on the system.

In general, color pickers feature 4 areas for your work.

  1. Color wheel
  2. Color shade vertical bar (very few times horizontal)
  3. Color Saving area
  4. Color value entries

My perception is that these could fit Bob if they had these elements. But Bob has not thought of the extensibility features that could be introduced to the interface. I believe that as being part of an interconnected world, our color selections can be shared and appreciated by others. Adding a social element to the color picker would be great. Bob could for example, do a simple online search (from within the color picker) to choose color palettes or swatches that he might need for his next photo project. He might also discover new swatches that are exactly what he is looking for in the next composition. Maybe a friend of his has posted a new swatch at a central location from where Bob’s friend shares his creations.

Another cool idea would be to have the ability to rearrange the color picker as best you think. You don’t have to worry about pre-determined organizations that don’t match your workflow. Just like Dolphin is able to move bars and sections to different arrangements, this could also be possible with the picker. That way, you don’t conform or find the UI limitations that may be always present as you try to expand your color picking experience.

So, here is my idea

First, provide a central area and default arrangement where color is chosen

Or you can just decide to change all that and create something like this


Next, we need to think of how to show or present the social area. Given the space constraints and the way that you may want to develop your color picker begs the designer to simplify and abstract this particular area.

Here the idea is to be able to create your own swatches through the saving tool (it would need to feature an element to create the swatch) and later drag them into the social area for you to seamlessly share them with other users. You have a plus and minus button area where you can bring in new swatches from the internet and also a little element to show how popular or loved a certain swatch is.

Now, I presented this idea here is very simple terms and results so that we can think outside the box for how to keep core new ideas and update the design for the color picker.

Categories: FLOSS Project Planets

It’s that TIME again!

Sun, 2014-10-26 09:21

Twice a year i’m welcomed by a change in my time. Yes, it’s the stupid Daylight Saving Time. Or rather, it stops and kicks back in at the end of march.

In other terms: Summer time and Winter time. Why we – all of Europe – still even have this time weirdness is beyond me. I would kick summer time out and stay with winter time all year.

Since we don’t have one time yet, i’m stuck to fixing my clock twice a year. This time i saved the commands to do just that and share them with you.

All the commands below should be executed as root user!

First you need to sync your time using this command (you might need to install ntp or ntpdate):

This synchronizes your time. However, your hardware clock can still be wrong. Sync your new time to the hardware clock:
hwclock –systohc –localtime

That’s it.
Your time should work properly now. Both on linux and windows.

Categories: FLOSS Project Planets

Presenting DWD, a Candidate for KDE Window Decorations

Sat, 2014-10-25 15:11

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;


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.

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.

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.

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 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)

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 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!

Categories: FLOSS Project Planets

What if… KDE Used Windows 10 Design Components?

Sat, 2014-10-25 04:00

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.


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

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

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

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.

  • 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.
  • 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.

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!

Categories: FLOSS Project Planets

What if… Plasma Used Launchers from Other Systems & Enviornments? (Part 1)

Sat, 2014-10-25 03:00

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.


KDE and Plasma has several methods of launching programs; simple list menus, quick short-cuts, powerful multi-component menus, and task ‘pinning’… Command line. Plasmas’ default setup is to use two of these in tandem; ‘task pinning’ and multi-component menus.

Other environments tend to use the same methodology, but usually with far less configuration options. Windows, for example, often allows pinning applications as quick launchers, and a multi-component menu. Apples’ OSX takes a different approach, using a multi-component quick-launcher (the dock) and opening components via the file manager. Elementary OS takes a middle-road having a multi-component dock, and a simple launcher. Gnome uses a multi-component dashboard which serves as the ‘nerve centre’ for application launching and management.

For the sake of brevity (hahah! Like that’ll happen!), part one of this what-if will focus on Elementary OS; in addition to looking at launchers, the overall feel of the systems will also be briefly explored and discussed separately.

What if… Plasma Used Launchers from Other Systems & Environments Elementary OS?

Elementary OS is a distribution of Linux which makes used of a highly customised desktop shell called “Pantheon”, which originally started as a set of modifications to the Gnome desktop. It consists of a panel at the top, and a dock at the bottom. While visually similar to Apples’ OSX, Elementary aims for a mono-tasking approach on all actions, and has a simpler approach to task/application launching and management.

by Softpedia

I’m going to mention “Mono-Widgets“, “Compound Widgets” and “Multitasking Widgets” several times; this is because my analysis of KDE/Plasma and Elementary presented the need for some vocabulary.

  • When I refer to Mono-Widgets, I’m referring to a widget which performs only one operation. For example, the Elementary Launcher very strictly finds and launches applications. It does nothing else, and dismisses itself when the single task is complete.
  • Compound Widgets perform several functions, but when a user enters a compound widget they only do one thing, then the widget exits. They only ever use one part of the widget per invocation. KDE Launchers fall into this category, bundling power, application, search, recent documents, places, favourites, and other functions into one area; however you only ever do one at a time, and then the widget dismisses itself.
  • Multitasking Widgets are widgets where you’ll enter them, work on a task or two, and eventually dismiss them when you are finished. For example, the network widget will have you create, modify, update, select, and delete networks and basic network settings. Where this differs from Elementary is that Elementary will only list existing networks, opening a separate program to edit them.
Comparison to KDE/Plasma

EOS desktop components such as the Plank (the dock), and Slingshot (applications launcher) are extreme mono-tasking widgets, simplifying the work-flow substantially but also necessitating more individual widgets. A good example of this is the exclusion of power options in Slingshot, but the addition of a power widget on the far side of the panel. Ironically, KDE contains a much more comprehensive legion of widgets, many of which mono-task similarly to Elementary widgets – but instead Plasma defaults to compound widgets and multitask widgets.

Elementary supports minimal customization options out-of-box. Because they have chosen to avoid customization Elementary must approach their static configuration with much more discipline. Combined with their minimal approach, there’s a distinct feeling that every UI element added was harshly scrutinised before inclusion. Elementary almost never hides UI elements in their desktop environment; if a widget would not have space to include all the options necessary, it will instead attempt to include the options for most use-cases and provide access to a more comprehensive application. On the other side, Plasma widgets don’t tend to launch applications.

“An undiscovered feature really doesn’t exist to people who haven’t found it.”

“Simple by default, Powerful when needed”

The Plasma default layout tends to focus on displaying fewer compound widgets which rely on more robust configuration. Compound widgets come with all functionality enabled by default and tend to be “configured down” in a way that users must pick what they [i]don’t[/i] want; this is directly counter to “Simple by default”. Elementary on the other hand has exceptionally focused mono-tasking widgets, but no configuration options. In other words, Elementary meets the first half of the mantra (Simple by default), but the plasma desktop achieves neither (Powerful when needed)

KDE-style Plasma Panel, Elementary Launcher

Widgets in plasma which do focus on mono-tasking (such as the calendar) tend to have a higher focus on design, and are exceptionally intuitive. KDE developers could and should investigate the creation of more mono-tasking widgets for areas currently dominated by heavy-duty compound widgets. Developers could also re-investigate the default layout after mono-task widgets are complete to relegate much heavier widgets to configuration options. By packaging simple widgets into the default configuration and keeping heavier widgets as options KDE would further achieve the “Simple by default, powerful when needed” mantra.

The best example may be the Kickoff launcher which features favourites, applications, places, recently used files, account info, search, and other options. Some of these exist in other widgets, and the launcher could be forked into its remaining constituent parts; a launcher, a recent files widget, a computer widget, an account widget, etc. Plasma fails in intuitiveness when it packs this functionality into a widget and hides some components to keep the design clean such as hiding search in its launcher – where Elementary refuses to hide any feature. While this makes individual plasmoids powerful, it actually reduces the functionality because an undiscovered feature really doesn’t exist to people who haven’t found it.

Elementary styling takes over

Technical Challenges

Extra widgets would need to populate panels for a mono-widget design

If KDE were to attempt to lean towards an Elementary setup the largest hurdle would not be the addition of features or new monotasking widgets, but instead the streamlining of the desktop and its options into a functional, streamlined, and focused desktop without upsetting its user-base. This is less of a technical problem and more of an emotional one: KDE users tend to worry when applications become ‘dumbed down’ despite the fact that functionality remains. Granted, Marco Martin has done some fantastic work which eases operations like the swapping of widgets, so the road to quickly allow users to reconfigure to more complex setups has been paved.

  • Elementarys’ static structure requires far less cognative throughput on its users
  • Mono-widgets are lightweight, and visually more appealing. They have high discoverability.
  • Mono-widgets are simple to understand and intuitive. Search will want you to type something. Launching opens applications.
  • Configuration options which do exist are easier to understand, and will likely be better understood.
  • Elementarys’ highly disciplined approach packs similar functionality into a much smaller package
  • Mono-widgets are functionally a step back.
  • Each mono-widget requires a way to get to it, pushing complexity up the UI to areas like the panel.
  • Sometimes operations are complimentary or highly similar, and that is lost in mono-tasking. For example, a launcher search and a file search are highly complimentary.
  • Mono-tasking can result in a “good enough” experience where widgets get the job done, but sacrifice power and convienience.
  • Mono-tasking can make an otherwise capable tool feel oversimplified or underpowered.

Activities are an unknown hallmark of KDE

In Plasma, default widgets should enforce a minimal configuration by default to present core functionality first, then allow users to “configure up”. For widgets added to the system via configuration tools, we should remain with the “configure down” approach to expose functionality when a user adds a (presumably) unknown widget. This is much more in-line with the “Simple by default, Powerful when needed”.

While Elementary is considered Linuxs’ most “elegant” desktop, KDE has more technology to quickly and easily iterate. KDE5/Plasma5  makes far better use of text and design elements, and actually feels more “designed” compared to Elementary in some areas; when you inspect an individual widget in Elementary they can be surprisingly utilitarian and uninsipred. The calendar is a prime example of where KDE has more visually appealing design. When Elementary Freya is released, I have no doubt that if KDE/Plasma developers hunkered-down and focused on design, we could “out-Elementary” Elementary by their next release.

KDE always needs a menu widget for usability reasons

On the inverse, KDE developers tend to lean towards “proper” system-level design, making them less willing to make technical exceptions for strictly design reasons, or at least slow KDE design down while better methods are engineered. This is not a bad thing. For example (as far as I know) KDE will not kludge in code to make docks adjust their colours based on wallpapers; but when similar functionality eventually does hit, it will be done in a way that is technologically superior, where plasma theme designers could easily tap well-designed APIs. Often, this comes down to the “glue” libraries used by KDE when adding APIs to QML.

An icon-sized desktop switcher is easily embedded as a plasmoid.

Overall, technology-wise, KDE is capable of easily out-designing Elementary OS in a sustainable way; but where KDE has Technology Elementary has tenacious focus and dicipline we should learn from. They don’t try to please everybody, and perhaps KDE/Plasma shouldn’t try either. Focusing on a simpler default desktop enviornment and having power-users configure-in more powerful widgets where they want it may ultimately be a better model; power-users can be expected to “configure up”, but casual users won’t “configure down”.

Chime in!

What are your thoughts on Elementary OSs’ design merits? What did I miss, any addendums? Let us know!

Categories: FLOSS Project Planets

What if… KDE Started using Client-Side Decorations?

Sat, 2014-10-25 02:00

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.

This is also an older what-if, and since it has been written, work on different approaches to design highly dynamic decorations has advanced. This post is here more/less for posterity. More info will come later on other methods.


“Client-Side Decorations” (or “CSDs” for short) are a method of decorating windows where the application is responsible for the window frame. Commonly, Linux and Linux desktop environments have favoured “Server Side” decorations (SSDs for short), where it was up to the window manager to draw the window frames. In this “What if” scenario we’ll explore two hypothetical applications; a media player and a PDF viewer, programs which might benefit from CSD technology. Before the CSD-enabled mockup, here’s what the media player application might look li ke using KDEs’ current SSD method:

And here’s what it might look like using CSD:

In the CSD design, the various window buttons are moved down into the control bar of the media player. This saves vertical space, meaning an un-maximised video will always be slightly larger. In addition, the buttons can follow a separate theme from the main window; in this case a less distracting button is used. Additionally, the application could partially fade buttons in the bottom bar, or, if the bar was laid over the video the entire bar could be faded out (when the mouse leaves) for maximum display – though this is not in the mockup.

In this PDF reader, the CSD is on the left, and uses the thumbnail column as the decoration. As PDFs generally tend to be a series of portrait sheets, vertical space is at a premium.

Technical Challenges

The main technical challenges faced by KDE developers is ensuring application consistency will continue to work under various form-factors. When Kwin (the KDE window manager) controls window borders, it can quickly and gracefully adapt to multiple form-factors. For example, in Plasma active space is at such a premium KDE can hide window decorations and embed them into the workspace itself.

The other technical challenge is protocol and cross-enviornment consistency. It’s known that CSD-enabled applications can look extremly awkward when window borders are wrapped around an application not designed to use them. In addition, protocols for drawing CSDs on Linux are a mish-mash at best, and CSD code tends to be far less portable to other desktop environments. Compounding that, KDE has additional features (such as window tabbing) which are inherently incompatible with the feature.

If KDE were to use CSDs, it would likely be preferable for all applications to support CSDs as a secondary ‘upgrade’ and default to using SSDs until the window manager explicitly enables the CSD; meaning KDE apps with CSDs would need alternate layout code. KDE might also need to reserve the ability to revoke CSDs from an application or flag them to keep CSDs disabled; for example, it might only allow Wayland-composited environments to use CSDs, as Wayland has protocols for CSD-specific problems (such as application hangups). It might revoke the CSD layout if a user disabled it, or if an application is moved into a window-tab.

Application crashes are another significant issue; If applications are made responsible for their own close buttons you enter a situation where the close button on a crashing program will fail to function. There are several technical aspects to this which can defer the impact, but in a worst-case scenario the GUI of an application will become an non-responsive picture. Wayland has solutions to detect this, while Xorg is a hot mess; if Wayland/KDE used CSDs, a window manager overlay might need to be created in the event of a crash to retake the minimal window-level control of applications.

  • Applications would waste less space on screen; for small laptops this is a significant advantage.
  • The decoration can be placed on any side. Applications like a movie player could hide decorations completely.
  • Applications with a full-screen mode may just use the same chrome in full-screen, maintaining placement of close/minimise/maximise buttons.
  • A strong CSD protocol/library could ensure reliability[/list]
  • Outside of the extra code overhead, applications could more easily break in the future as technology changes.
  • Depending on the implementation, applications could be larger.
  • Kwin would need more code to recover, mark, or kill crashed CSD applications.
  • Consistency is lost; Windows might place buttons on the top, bottom, left, or right. Users would need to adjust to applications individually.
  • Poorly chosen widgets can interfere with window dragging, space meant for dragging windows might be lost.
  • Depending on implementation, polling mechanisms might falsely label applications as non-responsive.
Other Points
  • Applications can crash many ways, causing whole-system breaks. SSDs can’t police the whole system; Bad applications shouldn’t be the example.
  • Using an “SSD until otherwise permitted” model can still allow users who dislike CSDs to enforce SSDs.
  • KDE applications are beginning to ship with multiple layouts for convergence purposes; CSD layouts might piggyback on this.


On a personal level, I love applications which properly use CSDs. They’re more screen-efficent and applications can look much more professional. I also believe that CSDs will be inevitable, and that a strong KDE CSD library which enforces smart use of CSDs would be better now than applications inventing their own solutions later; especially when other environments are starting to make good use of it.  After looking at Gnomes solution, I do think CSDs as-an-upgrade would be ideal, as applications can behave “normally” until they get the go-ahead to be shiny. This will help KDE apps fit into environments like Windows, OSX, or Gnome without issues. Also, users might want to forcefully disable CSDs desktop-wide for consistency purposes, and having CSDs as-an-upgrade would assist in this.

I also think that CSDs should also be required to adhere to Kwin specifications will first and foremost; while it’s nice applications might ‘brand’ themselves using colours or unique styling, I believe allowing Kwin to dictate the style would be a usability win. In addition, KDE 5 is incredibly friendly to dark themes (or is increasingly getting better at it), and allowing CSDs to colour themselves would take away from user options. On the other hand, since windows would not necessarily display titles, colouring becomes an important identifier.

I also like the idea that a full-screen application could just continue recycling the same piece of chrome; often applications use entirely different UIs in full-screen mode, which reduces usability – especially when hot-keys are required to exit fullscreen.

Technology-wise, I’ve read impressive articles on Wayland in regards to how they’ve thought through many CSD specific problems – such as application crashes rendering windows unmovable. No matter how its sliced though, CSDs should be approached carefully and thoughtfully if they were to be implemented as a part of KDE in the future.

In terms of the “simple by default, powerful when needed” mantra, CSD decorations follow the pros and cons listed above; mainly by making more efficient use of screen-space and giving applications a more simple, less intimidating demeanour. On the other hand, it decreases the intuitivity of applications by potentially moving window controls, or causing issues in event of a hangup. I think CSD driven designs tend to be more simple and reserved (at least as Gnome has done it). Disabling the CSD desktop-wide for features like window tabbing is where “powerful when needed” kicks in; especially since its an uncommon and difficult to discover feature.

One Last Note;

This is actually a fairly old what-if, and since it has been published work on different approaches to design has advanced. This post is here more/less for posterity.

Chime in!

What are your thoughts on CSD; what did I miss, any addendums? Let us know!

Categories: FLOSS Project Planets

The Bug of the Month

Fri, 2014-10-24 21:29

The KDE Gardening Team had the idea to nominate one particular annoying bug as “The Bug of the Month”. While we have literally hundreds of bugs that would qualify, only one bug per month gets nominated.

To get the initiative going, I took the liberty to select the first “Bug of the Month”:
it is Bug 324975: Volume gets restored to 100% after each knotify event.

Reasons for the nomination:

  • the bug affects practically all users, because notifications are not only used by many KDE applications, but also by the KDE Workspaces itself,
  • the bug is severe, as it can damage hardware and ears in extreme cases,
  • the bug is annoying, which was also measured by the rapid growth of votes and comments,
  • the bug seems fixable, we just did not find someone who was able to do it.

If you are able to fix it, you will receive a honorable mention in the next issue of my blog post “The Bug of the Month” on Planet KDE.

We do not have a knotify maintainer. If the issue is in knotify, please suggest a patch with anything that fixes it and create a review request at and paste the link here. If the issue is in Phonon, its backends, in gstreamer, VLC, pulseaudio, or ALSA, please suggest a patch there.

Not all developers that would be able to fix it are subscribed to this bug. If you know someone, feel free to point him here.

If we receive multiple patches, we will have to decide which of them is best suited, and nominate one of them for the fix.

Categories: FLOSS Project Planets

Kubuntu Shirts are Back

Fri, 2014-10-24 11:51

Kubuntu T-shirts and Polo Shirts are available again. This time our supplier is HelloTux who are working with the Hungarian Ubuntu LoCo. $3 from each shirt goes to Kubuntu and $1.5 to the Hungarian LoCo team.

Categories: FLOSS Project Planets