Subscribe to Planet KDE feed
Planet KDE -
Updated: 5 min 12 sec ago

Going Wild With Animation

2 hours 10 min ago

We knew the animation plugin was something artists all over the world were really waiting for… What we hadn’t expected was the flood of cool little animations that suddenly appeared everywhere! Let’s take a look at a selection of them! And in another way, the release also helped find some issues. First: if onion skinning doesn’t work for you, check that you’re not trying to onion skin a completely opaque layer. Yes — white is also opaque! The best setup: create a white background layer, but paint on a transparent layer above that. That’s Krita’s default setup in any case. For some people with some combinations of graphics cards and drivers, the Instant Preview doesn’t work. There’s not much we can do about that, but we do need your reports! And finally, a couple of real bugs surfaced, and we’ll look at that next.

But here’s the animation gallery!
By Timothee Giet

Toothless dargon turning head and Horse galloping by JackTheVulture on tumblr.

Falling ball by はまの ‏@HaMoO0NoO0 on twitter.

exploding sparkles by Nahuel Belich on twitter

Dancing Gronky and did anyone say bitmap animation by SJ Bennet on twitter

Growing Tree by 雑賀屋鳶 ‏@tomB_saikaya on twitter.

walkcycle by JeffersonSN/Llama guy on twitter

walking dogman by Godzillu on twitter

by Степан Крани on youtube

by Немитько Николай on youtube

By Dileep N on youtube

Test gif of walking pruple alien man by Benjamin Mitchley on twitter

mouse hiding under pillows and
bird flying on tree by Vincent Sautter on twitter

By Popescu Sorin on youtube

hand smashing block/alarm clock By Pablo Mendoza on twitter

by Laura Sulter on youtube/twitter

Kubuntu: KDE: Munich Hackathon KDE CI work and Kubuntu workflow

Fri, 2015/11/27 - 10:52pm

Munich Hackathon sponsored by Limux

Munich Hackathon sponsored by Limux

First, a big thank you to the fine folks at Limux for hosting the event. Second, a big thank you to the Ubuntu Community Donations fund for getting me there!

I successfully crammed a ton of work into this short trip! We (Kubuntu) first sorted (mostly) a plan
for Xenial LTS release. We are going to sync with Debian as much as we possibly can this release as
stability is of utmost importance. Don’t fret, we (I) will still put newer KDE releases in a PPA for
those that want the newest of KDE, time permitting of course. We are still working out who will host our CI system, as we all agree that this is extremely important to our workflow. During the period that we are synced to debian will have time to fix our somewhat broken toolset so that we can function with less overhead. We bashed a few bugs, updated our to-dos.

On the KDE side, I worked on getting the docker workflow functioning on Unfortunately, ICU was updated so all of KDE will need a rebuild before this can go live. But the good news is we will have more than 2 slaves! And it will be fairly simple to extend in the future, fully clean builds, and we can utilize different OS version requirements. I also spent some time working on Phabricator permissions issues.

Overall this was an essential team building and work event that I could not have participated in without your help. So thank you to all of you that support Ubuntu community donations. Donate today!

With that said, my cry for help:

If you find any of my work useful, please consider a donation or become a patreon!
I can no longer sustain working without an income. If this works I can continue all of my
(K)ubuntu and KDE contributions ( a full time job in its current state + overtime!)
Patreon for Scarlett Clark (me)

Kubuntu: Ubuntu: The vote for UCC is in. I won?!?!

Fri, 2015/11/27 - 10:25pm

I would like to thank all of you for your support and votes for Ubuntu Community Council. I honestly did not think I could win. We had negative 24 hours to come up with a platform lol.
While I have done some major packaging contributions, I have mostly stayed away from the political side of the project. In my first few weeks I will catch up on current events and construct a plan of action. Hopefully, there is not too much! I do have a heavy load to carry with all of my other volunteering efforts. I do however, hope to be useful to the community in some way. I promise to all of you to put in everything I have.
Here’s to productive, useful, and friendly conversations to return Ubuntu and it’s flavors to their former glory, attracting new contributors and bringing back the bond of the current family of contributors.

If you find any of my work useful, please consider a donation or become a patreon!
I can no longer sustain working without an income. If this works, I can continue all of my
(K)Ubuntu and KDE contributions ( a full time job in its current state + overtime!)
Patreon for Scarlett Clark (me)

Resuming work on Yokadi

Fri, 2015/11/27 - 9:36pm

A few weeks ago we started working again on Yokadi, our command-line oriented, todo list. We are now finally ready to release version 1.0. This new version fixes a few bugs but does not bring new features. This lack of new features is actually a conscious decision: we wanted to make changes under the hood, and doing changes under the hood at the same time as adding new features is often a recipe for disaster.

What happened under the hood? I hear you asking.

Well, we finally ported Yokadi to Python 3. Mind you, it was not a straightforward port. The main pain point was SQLObject, the ORM we have been using since we started Yokadi. At the time we wanted to start porting Yokadi to Python 3, SQLObject had not been ported (the port is still not ready, only an alpha has been released) so we had to first switch to another ORM — we went with SQLAlchemy — before actually porting the application to Python 3. In fact I suspect Sébastien started the Python 3 port just to get rid of SQLObject, which he does not really like :)

The code is pretty much frozen by now, we have been using it for real-life todo-list work for quite some time: even if there are periods without active development, we still use and depend on Yokadi daily. We plan to get 1.0 out this weekend. Then we can start working on improvements and new features, a few of them are actually in progress, but I'll write more about them later.

Br-Print3D inside KDE:FINALLY

Fri, 2015/11/27 - 4:56pm

Well, after a few issues, i finally push the Br-Print3D code to the git on KDE Playground.

Click here to access the repository.

Screenshot from 2015-11-27 14-52-51Thanks a lot to KDE staff for this opportunity to have the Br-Print3D within this community!


screen config victory!

Fri, 2015/11/27 - 3:29am

kscreen wayland backend in action

kscreen wayland backend in action

That moment when the application “just works” after all your unit tests pass…

A really nice experience after working on these low-level bits was firing up the kscreen systemsettings module configured to use my wayland test server. I hadn’t done so in a while, so I didn’t expect much at all. The whole thing just worked right out of the box, however. Every single change I’ve tried had exactly the expected effect.
This screenshot shows Plasma’s screen configuration settings (“kscreen”). The settings module uses the new kwayland backend to communicate with a wayland server (which you can see “running” on the left hand side). That means that another big chunk of getting Plasma Wayland-ready for multi-display use-cases is falling nicely into place.


I’m working on this part of the stack using test-driven development methods, so I write unit tests for every bit of functionality, and then implement and polish the library parts. Something is done when all units tests pass reliably, when others have reviewed the code, when everything works in on the application side, and when I am happy with it.
The unit tests stay in place and are from then on compiled and run through our continuous integration system automatically on every code change. This system yells at us as soon as any of the unit tests breaks or shows problems, so we can fix it right away.

Interestingly, we run the unit tests live against a real wayland server. This test server is implemented using the KWayland library. The server runs headless, so it doesn’t do any rendering of windows, and it just implements the bits interesting for screen management. It’s sort of a mini kwin_wayland, the real kwin will use this exact same library on the server side, so our tests are not entirely synthetical. This wasn’t really possible for X11-based systems, because you can’t just fire up an X server that supports XRandR in automated tests — the machine running the test may not allow you to use its graphics card, if it even has one. It’s very easy to do, however, when using wayland.
Our autotests fire up a wayland server from one of many example configurations. We have a whole set of example configurations that we run tests against, and it’s easy to add more that we want to make sure work correctly. (I’m also thinking about user support, where we can ask to send us a problematic configuration written out to a json file, that we can then add to our unit tests, fix, and ensure that it never breaks again.
The wayland test server is only about 500 lines of relatively simple code, but it provides full functionality for setting up screens using the wayland protocol.

Next steps…

The real kwin_wayland will use the exact same library, on the server as we do in our tests, but instead of using “virtual screens”, it does actually interact with the hardware, for example through libdrm on more sensible system or through libhybris on ones less so.
Kwin takes a more central role in our wayland story, as we move initial mode-setting there, it just makes to have it do run-time mode setting as well.

The next steps are to hook the server side of the protocol up in kwin_wayland’s hardware backends.

In the back of my head are a few new features, which so far had a lower priority — first the core feature set needed to be made stable. There are three things which I’d like to see us doing:

  • per-display scaling — This is an interesting one. I’d love to be able to specify a floating point scaling factor. Wayland’s wl_output interface, which represents the application clients, only provides int-precision. I think that sucks since there is a lot of hardware around where a scaling factor of 1 is to small, and 2 is too high. That’s pretty much everything between 140 and 190 DPI according to my eyesight, your mileage may vary here. I’m wondering if I should go ahead and add the necessary API’s at least on our end of the stack to allow better than integer precision.
    Also, of course we want the scaling be controlled per display (and not globally for all displays, as it is on X11), but that’s in fact already solved by just using wayland semantics — it needs to be fixed on the rendering side now.
  • pre-apply checks — at least the drm backend will allow us to ask it if it will be able to apply a new configuration to the hardware. I’d love to hook that up to the UI, so we can do things like enable or disable the apply button, and warn the user of something that the hardware is not going to like doing.
    The low-level bits have arrived with the new drm infrastructure in the kernel, so we can hook it up in the libraries and the user interface.
  • configuration profiles — it would make sense to allow the user to save configurations for different situations and pick between them. It would be quite easy to allow the user to switch between setups not just through the systemsettings ui, but also for example when connecting or disabling a screen. I an imagine that this could be presented very nicely, and in tune with graphical effects that get their timing juuuuust right when switching between graphics setups. Let’s see how glitch-free we can make it.

Pursuing Awesomeness

Thu, 2015/11/26 - 9:23pm

Plasma 5.5 hasn’t even been released yet but work on the next version is already commencing.

Introducing U-Bahn

I’ve seen Plasma setups resembling Unity, or Gnome Shell, or OS/2, but I haven’t seen Windows 8 yet.

This is an experimental Metro-inspired (Metro, U-Bahn, get it?) sidebar. Its name kinda shows how serious I was about this :) Anyhow, it’s a nice showcase of Plasma’s flexibility. The whole thing took me just over an hour to get up and running. It incorporates KRunner/Milou for search results, the Purpose Framework for sharing, parts of Print-Manager and Device Notifier, as well as the icons from Plasma-PA (audio) and Plasma-NM (network) on the Settings page. The centre button was supposed to launch the Application Dashboard, without tiles, though.

While I’m not planning to finish this very project – it’s just too big of a hack the way it is –, I managed to get a discussion going. I’m looking forward to ideas our usability and design experts will come up with. It makes for an interesting concept on touch-enabled devices nonetheless. Also, I would love to see the Purpose framework embraced throughout the workspace rather than it living in the shadows within Kamoso and the Quick Share applet.

Jump Lists

Another feature I have wanted for years has finally landed: “Desktop Actions” aka Jump Lists. Basically, they are additional actions an application can offer to perform common actions or jump directly to a certain task from Task Manager. Common examples are “Open New Incognito Window” to open your browser directly in private mode, or “Compose Email” without launching the full-fledged Email client first.

If you’re an application developer, start assessing which actions to provide – only few applications on my system actually do: Chromium (Google Chrome only ships Ayatana Desktop Shortcuts), LibreOffice (its launcher enables you to jump into a specific app, like Calc or Impress) and Konsole.

LibreOffice launcher providing access to apps within the suiteLibreOffice launcher with access to apps within the suite Chromium providing handy shortcutsChromium providing handy shortcuts

The specification is pretty “dumb”, you can basically specify a name, an icon and a command to run – your application must then do the right thing™ eg. depending on whether an instance is already running or not.

More Convenient Plasmoid Install

While applets can be installed through “Get Hot New Stuff” and distribution repositories, there’s also the classic .plasmoid file. A feature suggested by one of my colleagues – fresh KDE Plasma user – was to drag .plasmoid files onto the desktop or panel and have them installed. After Marco Martin implemented the neccessary KPackage plumbing this is now possible.

(Sorry for the quality, I wanted to make a GIF out of this but it turned out to be 24 MiB, then I downsampled it using ffmpeg and it mashed the picture)

If the applet is already installed, it will update if neccessary but still add it to where you dropped. To uninstall use the Widget Explorer which gained a new “Uninstallable” applets filter. Also, its uninstall feature now follows the undo pattern where you have a grace period before it actually uninstalls. Uninstalling also removes all instances of the applet rather than leaving broken applets behind.

Miscellaneous Improvements

First of all, FFMpegThumbnailer will finally be released as KF5-based plugin in KDE Applications 15.12 meaning you get thumbnails for videos in Dolphin again.

Secondly, in the Power Management department, switching sessions should no longer unexpectedly send your computer to sleep. Moreover, inhibitions will only be enforced after 5 seconds – this should prevent Chrome waking up your screen just because it played a short “You got message” sound. Also, I’m planning to overhaul the Battery Monitor UI which was essentially just ported from Plasma 4, where it worked well, to Plasma 5, where its layout is out of place. I won’t promise that, though. :)

Finally, I ported the face / avatar gallery from the old user accounts KCM to the now used user manager. The Visual Design Group made some marvellous user pictures, like the Leonardo Da Vinci I’m using, it would be a shame if there was no UI to pick them.

Plasma 5.5 Release Party in Heidelberg

Thu, 2015/11/26 - 11:45am

This time we’ll celebrate early!

Date: Friday, 4 December 2015 (correct year this time around)
Time: 19:00
Place: Medocs Cafe am Bismarckplatz, Sofienstraße 7b, 69115 Heidelberg
Who: You! And fellow KDE developers and users
What we’re going to do: Have a few beers, a delicious dinner, talk, have fun, …

Please ping me, if you’re around and planning to come (contact info can be found in the Impressum, or tell kbroulik in #plasma on Freenode), so I can extend the reservation, if needed.

Marble Maps forking for SailfishOS

Wed, 2015/11/25 - 7:39pm

Marble, the swiss army knife for maps and globes, developed in the KDE community, this year has got an app variant added that is concentrating on maps and that is designed for today’s typical mobile devices with touch UI, called Marble Maps. It currently is in Beta state. Read “Announcing Marble Maps for Android Open Beta” for more info.

At this year’s Randa meeting for a few days I joined the people working on having KDE software run on Android. After all there are gazillions of such systems out there, and it only makes sense to have existing FLOS software, such as KDE ones, also run there, as a matter of dealing with realities. With the developers of Marble, KAlgebra and GCompris around, some experience could be shared, and I compiled what I learned into a small Hello KWorld example.

As a Marble fanboy, Marble Maps was my obvious toy project here when learning more about building Qt5-based software for Android. I had no Android device available, but a Jolla phone with SailfishOS. That one also has support for running Android apps, so I still could use it to test my self-built Marble Maps Android packages.

Now, it felt strange to run a Qt5-based application via Android emulation layer on an OS like SailfishOS which itself is using Qt5 and then some usual “Linux” software stack/middleware. Should it not simply run directly there?

So last week finally I gave it a try to build and to run Marble Maps natively on SailfishOS. And was presented with a problem: SailfishOS in the latest version is (still) at Qt 5.2 (with QML upgraded to 5.3 it seems) and, more important, has no QtQuick Controls. Which are used in Marble Maps for all controls. At least all the Marble C++ code was building fine after 2 small fixes, so that part was looking promising.

An option might have been to build a custom version of QtQuick Controls. But that somehow smelled like problems waiting. And I also was tempted to try to do some native UX to gather more experience with QtQuick and the SailfishOS ideas. So I forked the Marble Maps code and started to write a SailfishOS variant, using its Silica UI components. The code for Marble Maps is mainly the UI layer one, written in QML, with the actual business logic nicely in the shared Marble libs and components, so it is not that much logic which is duplicated here. Still it is not “Write once and run everywhere”. It’s up for discussion how much native multi-platform apps should go. For now I will play more with it.

Right now Marble Maps for SailfishOS almost has all current features of the “normal” Marble Maps implemented, modulo some small bugs:

 Editing a route  Adding a new point to a route

These days sadly many people hearing “marble” and “sailfishos” might rather think of “tombstone”, bad timing here. But until that OS is pushing up the water lilies I will play more with it, after all I can use the code on a working device of mine.

If you want to use the code on a device of yours, find first RPMs on
and the code in branch “sfos” in my Marble repo clone, see src/apps/marble-maps-sailfishos/ for the app code. Once it’s stable enough the code will be proposed for inclusion in the official Marble repo.

Also looking forward to see the “normal” Marble Maps and other Marble-based apps soon on Plasma Mobile hopefully.
And anyone looking into an Ubuntu Touch version? Would that work with stock Marble Maps, thanks to QtQuick Controls, or would more native UX be needed there as well?

Area51 updates (KDE on FreeBSD)

Wed, 2015/11/25 - 12:59pm

The area51 repository continues to update, even as the official ports tree for FreeBSD sticks with KDE4. Since the KDE-FreeBSD team is also responsible for the official ports, that basically means that not everything has been shaken out yet, and that the team doesn’t feel that it can provide a really good Frameworks5 / Plasma5 / Applications installation .. yet. I’ve been playing with ideas for a default desktop wallpaper (the upstream default gives me a headache; I’d really like to combine Flying Konqui by Timothée Giet with bubbles made from the BSD logo.

That said, Plasma5 and some Applications work very nicely on FreeBSD. They also produce plenty of .core files, so it’s not all wonderful, but it’s a usable desktop by all means (and of course, all your KDE4 and GNOME applications continue to work). I tried to install a Qt5-only (+Frameworks, of course) desktop and discovered a long-standing bug in gsettings, as well.

The KDevelop-KF5 beta is available as a port from area51 as well. There’s an interesting potential bug there, too: it uses LLVM 3.5 libraries while the Mesa libraries use LLVM 3.6 in the software renderer. So if you have a machine without hardware GL, you can end up with two LLVM libraries runtime-linked into an application, which means crashy-time. This is the first time that upgrading my graphics card has fixed my IDE.

Krita 2.9 Animation Edition Beta released!

Wed, 2015/11/25 - 6:18am


Today we are happy to announce the long awaited beta-version of Krita with Animation and Instant Preview support! Based on Krita 2.9, you can now try out the implementation of the big 2015 kickstarter features!

What’s new in this version? From the user point of view Krita didn’t change much. There are three new dockers: Animation, Timeline and Onion Skins, which let you control everything about your animation frames and one new menu item View->Instant Preview Mode (previously known as Level of Detail) allowing painting on huge canvases. For both features, you need a system that supports OpenGL 3.0 or higher.

But under these visually tiny changes hides a heap of work done to the Krita kernel code. We almost rewritten it to allow most of the rendering processes run in the background. So now all animated frames and view cache planes are calculated in the moments of time when the user is idle (thinks, or chooses a new awesome brush). Thanks to these changes now it is possible to efficiently work with huge images and play a sequence of complex multi-layered frames in real time (the frames are recalculated in the background and are uploaded to you GPU directly from the cache).


So, finally, welcome Krita 2.9 Animation Edition Beta! (Note the version number! The final release will be based on Krita 3.0, this version is created from the 2.9 stable release, but it is still beta. We welcome your feedback!

Video tutorial from Timothee Giet:

A short video introduction into Krita animation features is available here.

Packages for Ubuntu:

You can get them through Krita Lime repositories. Just choose ‘krita-animation-testing’ package:

sudo add-apt-repository ppa:dimula73/krita sudo apt-get update sudo apt-get install krita-animation-testing krita-animation-testing-dbg Packages for Windows:

Two packages are available: 64-bit, 32-bit:

You can download the zip files and just unpack them, for instance on your desktop and run. You might get a warning that the Visual Studio 2012 Runtime DLL is missing: you can download the missing dll here. You do not need to uninstall any other version of Krita before giving these packages a try!

User manuals and tutorials:

A clockwork carrot

Tue, 2015/11/24 - 10:32pm

This weekend I had the opportunity to travel to the yearly LiMux sprint to spend some time with my fellow kubuntu devs and talk about the potential issues we’re facing with the CI system and improving the Debian CI system to be more robust.

Some of the more important issues that were discussed included figuring out a way to improve file tracking in packages, so that the CI can detect file conflicts without having to actually install all the packages. Another important topic that was bought up was using the packagekit and appstream with Muon. This is apparently being held back on account of Ubuntu Touch, but is slated to be resolved soon. Once the necessary packagekit packages are updated, we can play around with the idea of perhaps shipping a muon using the packagekit backend on the next Kubuntu release.

As usual, the LiMux folks are a great bunch to hang out with, and I happened to notice something on the wall of their office while lunching with them. It was a clock. Not just a regular clock though, a timey wimey clock. I’ll let a picture do more of the talking here :


Timey Wimey clock

Timey Wimey clock


Told you. Timey Wimey.

I got quite the headache looking at the clock, but my fascination with it stuck. So once I was back home, I hacked up the regular Plasma 5 analog clock and made it timey-wimey too ;)

Timey Wimey clock

You can download and install the clock from here. Clocks and Carrots, a weekend well spent I say. As usual, you can find me and the other kubuntu devs in #kubuntu-devel on IRC or on in case you want to reach out to us about Kubuntu, Clocks or Carrots.

Krita 2.9 Animation Edition beta

Tue, 2015/11/24 - 9:23pm

I’m very happy to tell you, finally, a version of Krita supporting basic animation features is about to be released!

This is still in early stage, based on latest 2.9 version, with lot of additional features to come later from version 3.

If you want to have fun with it, here is a little introduction tutorial to get started, with some text and a video to illustrate it.

-Load the animation workspace to quickly activate the timeline and animation dockers.

-The timeline only has the selected layer. To keep a layer always visible on it, click on the plus icon and select the corresponding option (Show in timeline to keep the selected layer, or Add existing layer and select one in the list …)

-To make a layer animated, create a new frame on it (with the right-click option on the timeline, or with the button on the animation docker). Now the icon to activate the onion skins on it becomes visible (the light bulb icon), activate it to can see previous and next frames.

-The content of a frame is visible in the next frames until you create a new one.

-After drawing the first frame, go further in the timeline and do any action to edit the image (draw, erase, delete all, use transform tool, …). It creates a new frame with the content corresponding to the action you made.

-If you prefer to only create new frames manually, disable the auto-frame-mode with the corresponding button in the timeline (the film with a pen icon).

-In the animation docker, you can define the start and end of the animation (used to define the frames to use for export, and for the playback loop). You can also define the speed of the playback with the Frame rate value (frames per second) and the Play speed (multiplier or the frame rate).

-In the Onion Skins docker, you can change the opacity for each of the 10 previous and next frames. You can also select a color overlay to distinguish previous and next frames. You can act on the global onion skins opacity with the 0 slider.

-To export your animation, use the menu entry File – Export animation, and select the image format you want for the image sequence.

Have fun animating in Krita, and don’t forget to report any issue you find to help improve the final version ;)

digiKam Recipes 4.9.7 Released

Tue, 2015/11/24 - 10:40am

A new release of digiKam Recipes is ready for your perusal. This version features the new Use Exposure Indicators recipe along with the updated Find the Shutter Count Value with digiKam recipe. Astute readers will also notice the new cover. That's all there is to it this time around.


Continue reading

read more

Game Art Quest Kickstarter!

Mon, 2015/11/23 - 4:21pm

Today an exciting new crowdfunding campaign kicks off! Nathan Lovato, the author of Game Design Quest, wants to create a new series of video tutorials on creating 2D game art with Krita. Nathan is doing this on his own, but the Krita project, through the Krita Foundation, really wants this to happen! Over to Nathan, introducing his campaign:

“There are few learning resources dedicated to 2d game art. With Krita? Close to none. That is why I started working on Game Art Quest. This training will show you the techniques and concepts game artists use in their daily work. If you want to become a better artist, this one is for you.”

“We are developing this project together with the Krita Foundation. This is an opportunity for Krita to reach new users and to sparkle the interest of the press. However, for this project to come to life, we need your help. A high quality training series requires months of full-time work to create. That is why we are crowdfunding it on Kickstarter.”

“But who the heck am I to teach you game art? I’m Nathan, a professional game designer and tutor. I am the author of Game Design Quest, a YouTube channel filled with tutorials about game creation. Every Thursday, I release a new video. And I’ve done so since the start of the year, on top of my regular work. Over the months, my passion for open source technologies grew stronger. I discovered Krita 2.9 and felt really impressed by it. Krita deserves more attention.”

“Long story short, Game Art Quest is live on Kickstarter. And its existence depends on you!”

“Even if you can’t afford to pledge, share the word on social networks! This would help immensely. Also, this campaign is not only supporting the production of the premium series. It will allow me to keep offering you free tutorials for the months to come. And for the whole duration of the campaign, you’re getting 2 tutorials every single week!”

Check out Nathan’s campaign:


Looking at the security of Plasma/Wayland

Mon, 2015/11/23 - 10:13am

Our beta release of Plasma 5.5 includes a Wayland session file which allows to start in a Plasma on Wayland session directly from a login manager supporting Wayland session. This is a good point in time to look at the security of our Plasma on Wayland session.

Situation on X11

X11 is not secure and has sever conceptional issues like

  • any client connected to the X server (either remote or local) can read all input events
  • any client can get information about when another window rendered and get the content of the window
  • any client can change any X attribute of any other window
  • any window can position itself
  • many more issues

This can be used to create very interesting attacks. It’s one of the reasons why I for example think it’s a very bad idea to start the file manager as root on the same X server. I’m quite certain that if I wanted to I could exploit this relatively easily just through what X provides.

The insecurity of X11 also influenced the security design of applications running on X11. It’s pointless to think about preventing potential attacks if you could get the same by just using core X11 functionality. For example KWin’s scripting functionality allows to interact with the X11 windows. In general one could say that’s dangerous as it allows untrusted code to change aspects of the managed windows, but it’s nothing you could not get with plain X11.

Improvements on Wayland

Wayland removes the threats from the X11 world. The protocols are designed in a secure way. A client cannot in any way interact with windows from other clients. This implies:

  • reading of key events for other windows is not possible
  • getting window content of other windows is not possible

In addition the protocols do not allow to e.g. position windows themselves, or raise themselves, change stacking order and so on.

Security removed in Plasma

But lots of these security restrictions do not work for us in Plasma. Our desktop shell need to be able to get information of other windows (e.g. Tasks applet), be able to mark a panel as a panel (above other windows) and need to be able to position windows itself.

Given that we removed some of the security aspects again and introduced a few custom protocols to provide window management facilities and also to allow Plasma windows to position themselves. At the moment we have no security restrictions on that yet which gives this functionality to all clients.

We will address this in a future release. There are multiple ways how this could be addressed, e.g. using the Wayland security module library or use systemd in some way to restrict access. Overall I think it will require rethinking security on a Linux user session in general, more on that later on.

Security added in Plasma compared to X11

The most important change on the security front of the desktop session is a secure screen locker. With Plasma 5.5 on Wayland we are able to provide that and address some long standing issues from X11. The screen locks even if a context menu is open or anything else grabbing input. The compositor knows that the screen is locked and knows which window is the screen locker. This is a huge change compared to X11: the XServer has no concept of a screen locker. Our compositor can now do the right thing when the screen is locked:

  • don’t render other windows
  • ensure input events are only handled in the lock screen
  • prevent access to screen grabbing functionality while screen is locked

As a matter of fact the Wayland protocol itself doesn’t know anything about screen locking either. This is now something we added directly to KWin and doesn’t need any additional custom Wayland interfaces.

How to break the security?

Now imagine you want to write a key logger in a Plasma/Wayland world. How would you do it? I asked myself this question recently, thought about it, found a possible solution and had a key logger in less than 10 minutes: ouch.

Of course there is no way to get a client to act as a key logger. The Wayland protocol is designed in a secure way and also our protocol additions do not weaken that. So the key to get a key logger is to attack KWin.

So what can an attacker do with KWin if he owns it? Well pretty much anything. KWin internally has a very straight forward trust model: everything is trusted and everything can access anything. There is not much to do about that, this is kind of how binaries work.

For example as a Qt application each loaded plugin has access to the QCoreApplication::instance. From there one could just use Qt’s meta object inspection to e.g. get to the InputRedirection model and connect to the internal signal on each key press:

<code>void ExamplePlugin::installKeyLogger() { const auto children = QCoreApplication::instance()-&gt;children(); for (auto it = children.begin(); it != children.end(); ++it) { const QMetaObject *meta = (*it)-&gt;metaObject(); if (qstrcmp(meta-&gt;className(), "KWin::InputRedirection") != 0) { continue; } connect(*it, SIGNAL(keyStateChanged(quint32,InputRedirection::KeyboardKeyState)), this, SLOT(keyPressed(quint32)), Qt::DirectConnection); } } void ExamplePlugin::keyPressed(quint32 key) { qDebug() &lt;&lt; "!!!! Key: " &lt;&lt; key; } </code>

But Martin, why don’t you just remove the signal, why should any other aspect of KWin see the key events? Because this is just the example of the most trivial exploit. Of course it’s not the only one. If you have enough time and money you could write more sophisticated ones. For example look at this scenario:

KWin uses logind to open restricted files like the input event files or the DRM node. For this KWin registers as the session controller in logind. Now a binary plugin could just send a DBus call to logind to also open the input event files and read all events. Or open the DRM node and take over rendering from KWin. There is nothing logind could do about it: how should it be able to distinguish a valid from an invalid request coming from KWin?

How to secure again?

As we can see the threat is in loading plugins. So all we need to do is ensure that KWin doesn’t load any plugins from not trusted locations (that is not from any user owned locations). This is easy enough for QML plugins where we have the complete control. In fact it’s easy to ensure for any of KWin’s own plugins. We can restrict the location of all of them.

And even more: by default a system is setup in a way that no binary plugins are loaded from user’s home. So yeah, no problem after all? Well, unfortunately not. During session startup various scripts are sourced which can override the environment variables to influence the loading of plugins. And this allows to also use the well known LD_PRELOAD hack. My naive approach to circumvent this issue didn’t work out at all as I had to learn that already the session startup and the PAM interaction source scripts. So your session might be owned very early.

An approach to black list (unset) env variables is futile. There are too many libraries KWin relies on which in turn load plugins through custom env variables. Most obvious examples are Qt and Mesa. But there are probably many more. If we forget to unset one variable the protection is broken.

A different approach would be to white list some known secure env variables to be passed to KWin. But this also requires that at the point where we want to do the restriction the session is not already completely broken. This in turn means that neither PAM nor the session manager may load any variables into the session before starting the session startup. And that’s unfortunately outside what we can do in our session startup.

So for Plasma 5.5 I think there is nothing we can do to get this secure, which is fine given that the Wayland session is still under development. For Plasma 5.6 we need to rethink the approach completely and that might involve changing the startup overall. We need to have a secure and controlled startup process. Only once KWin is started we can think about sourcing env variables from user locations.

So how big is the threat? By default it’s of course secure. Only if there is already a malicious program running in the system there is a chance of installing a key logger in this way. If one is able to exploit e.g. a browser in a way that it can store an env variable script in one of the locations, you are owned. Or if someone is able to get physical access to your unencrypted hard disk, there is a threat. There are easy workarounds for a user: make all locations from where scripts are sourced during session startup non-writable and non-executable, best change ownership to root and encrypt your home location.

Overall it means that Plasma 5.5 on Wayland is not yet able to provide the security I would have liked to have, but it’s still a huge improvement over X11. And I’m quite certain that we will be able to solve this.

Interview with Christopher Stewart

Mon, 2015/11/23 - 8:22am
Web Could you tell us something about yourself?

My name is Christopher, and I am an illustrator living in Northern California. When I’m not in a 2d mindset I like to sculpt with Zbrush and Maya. Some of my interests include Antarctica, Hapkido and racing planes of the 1930s.

Do you paint professionally, as a hobby artist, or both?

I have been working professionally for quite some time. I have worked for clients such as Ubisoft, Shaquille O’Neal and Universal Studios. I’m always looking for new and interesting work.

What genre(s) do you work in?

SF, Fantasy, and Comic Book/ Sequential art. This is where the foundation of my work lies – these genres have always been an inspiration to me ever since I was a kid.

Whose work inspires you most — who are your role models as an artist?

Wow, what a tough question! So many great artists out there.. Brom- definitely, N.C. Wyeth, George Perez, and Alphose Mucha. Recently I have revisited the background stylists of Disney with their immersive environments.

How and when did you get to try digital painting for the first time?

About 9 years ago. Until then my work was predominantly traditional. I wanted to try new mediums, and I thought digital painting would be a great area to explore.

What makes you choose digital over traditional painting?

Time and space.

Alterations and color adjustments can be done quickly for a given digital piece.

The physicality of traditional medium has different challenges, and usually the solution will take longer to accomplish with traditional mediums in general.

Digital painting doesn’t take up a lot of space, a few decent sized stretched canvases..

How did you find out about Krita?

I had tried Painter X and CS and they were unsatisfying, so I was looking for a paint program. Krita was recommended by a long-time friend who liked the program, and I was hooked.

What was your first impression?

It was very intuitive. It had a UI that I had very few difficulties with.

What do you love about Krita?

I really really liked the responsiveness of the brushes. With other applications I was experiencing a “flatness” from the tablet I use to the results I wanted on screen, Krita’s brushes just feel more supple. The ability to customize the interface and brushes was also a huge plus.

What do you think needs improvement in Krita? Is there anything that really annoys you?

I haven’t been using Krita very long (less than 6 months) but I would like to be able to save and import/export color history as a file within an open Krita document.

What sets Krita apart from the other tools that you use?

When a company makes an application as powerful as Krita available for free, it’s a statement about how confident they are that artists will love it. And judging from the enthusiastic and knowledgeable people in the forums, they not only love it they want others to be able to love it and use it too. Developing and experienced artists need to evaluate new tools easily. Access to those tools should never be so prohibitively costly as to turn them away. Krita doesn’t get in the way of talent being explored, it supports it.

What techniques and brushes do you prefer to use?

I use a lot of the default brushes especially the Bristle brushes, a semi transparent texture to add to a plein air look as a final layer. I use some of David Revoy’s brushes, specifically the Splatter brushes. I recently made a new custom brush that I tried out on my most recent illustration.

Where can people see more of your work?

My website is You can reach me there!

Anything else you’d like to share?

Thank you so much for the interview and a special thanks to the developers and community that make Krita work!

Linux-Stammtisch Munich

Sun, 2015/11/22 - 9:47pm

For all Ceph interested people in Germany, especially Bavaria: There will be a Linux-Stammtisch next week on 24.11.2015 in Munich. I will present about "Ceph - Overview, Experiences and Outlook". If you are interested, the meeting starts at 19:00 (CET) at the Paulaner Bräuhaus. You find more information and can register here.

There will be also a talk held by Andreas Pöschl from BMW. The topic is: "Erfahrungen bei der Integration von Open Stack in eine Enterprise-Umgebung". And for sure there will be time for networking and beer after the talks and discussion.

Muon 5.5 and Carrots

Sun, 2015/11/22 - 4:11pm


Jonathan Riddell, Leader of Flies, kept holding me until I write a blog post, so here is one.

After 2 days of obscenely unsubsidized drinking and vicious discussions about carrots, the KDE and Kubuntu developers here at the developer sprint in Munich decided to release the Debian package manager Muon in version 5.5.0.

A very prominent thing to take away from this sprint is “oops”. I am not sure that is good, but oh well.

Hearts and kisses!

Divide and Conquer

Sun, 2015/11/22 - 3:54am


To start: Why the name of this post is Divide and Conquer?

Well… A few weeks back, I receive a feedback about the main class of the Br-Print project. This main class was friendly called a God Class. The God Class complex is when a class knows too much and does too much. Well, when a problem on this project is shown to me, starts to bug’s me. So I start the Divide and Conquer branch. Breaking the main class in others minor classes, to increase the level of abstraction and make the code more easy to read.

Today I push to the git this new version. With 5 new classes to manage specific controls on the code. Also solved a few layout issues, remove a lot of unnecessary code and simplify others parts.

With this challenge and Tomaz feedbacks and some tips from the internet, I could learn much more about Qt programming, OOP and about my limits.

Several times I had thoughts that I couldn’t do something. And today, when opened the statistics of this blog, I realize that I’m proud about my work. Proud about the places he has achieved.

Are 7 months working on this project, and I don’t figured out that the extension would be this great! Germany, United Kingdom, Switzerland, Belgium, USA. These are some of the countries that are accessing this page. Sometimes I really don’t believe! =D

The propose of this post is show my gratitude to all of you. To all people around the world that who are believing in this project!

If you wants to know more please reach us on our Facebook Page , because there we post photos and more info about this project!
Well, if you want to contribute or test the Br-Print3D just click here to go to the GitHub.

My best regards!


Ps.: If exists some error about my english write, sorry about that. =D