Category Archives: Netrunner

Discover more in 2017

With 2017 starting, we’re getting ready for the next Plasma 5.9 release and with it a new Discover release.

This will be a special release for two main reasons: further add-ons integration and Kirigami.

New Stuff

One thing pending for a long time was to actually better integrate the different parts of the system that can be integrated. To do so, Discover now will automatically import all knsrc files present on the system and offer them as categories.
We’ll be able to go beyond Plasmoids and Comics (!) and make it possible to explore: Plasma Look and Feel themes, cursors, icon themes, window manager add-ons and different application-specific resources.

This won’t have a big impact on Discover’s performance because the backend code was refactored to be able to have several backends loaded even without knowing all of the resources available. Queries are now asynchronous and parallel.

Discover KNS Addons


Kirigami was adopted in the previous release already, and this release will use Kirigami 2, the port to which did not require much work.

The most significant improvement is the inclusion of keyboard navigation, which was requested by several people and is now finally available. Do you hate it when you’re required to use the mouse? Rejoice!

Extra: Snappy support

It’s 2017, not all of the applications are coming from your distribution anymore. To start getting things in place for different software distribution sources I started working on a Snap backend, which allows us to manage applications coming from this system.
Some work will still be required and it won’t be included by default, since it doesn’t yet support AppStream (although we discussed it and it seems it will happen soon), but if you’re curious feel free to take a look and give your feedback!

Plasma Mobile SDK

Where are the giants?

When approaching this issue I had been thinking about the issue for a while. I had mainly 2 problems: I was rather frustrated with previous Linux-based systems so far and the one I liked didn’t really scale for us. One thing was clear: We had to stand on the shoulder of giants.

  • The first one to think about was the N9 SDK (and by extension N900). It used to have a scratchbox-based system that emulated the one on the phone. It was useful for testing the applications locally on the device (although I actually never used that), I think that this one had both cross-compilation toolchain and base system, as well as the host and it used QEmu if a host executable was run. It felt weird because it shoved you in a weird system and you had to pull your code in weird ways to fetch it. Otherwise it worked great. Afterwards, madde came. It’s what I was looking for really and played quite well with cmake, actually when I published the steps on how to develop for the N9 it’s what I used back then, but it probably was too late for it to become a thing I guess. Also many people weren’t too fond of it, as I learned after some time.
  • The Android NDK is the other I took into account. I don’t think it would be fair to compare anything we could do with the actual Android SDK, so I’ll limit myself to this one. This one ships the complete cross-compilation toolchain and runs native (similar to the BBX SDK, IIRC).

For the N9 approach, I would have had to concentrate on figuring out technologies that were long dead (and probably should remain). For the Android approach I found 2 big problems: We have to actually work on generating the actual binaries (which means, from any platform to a specific ubuntu-vivid-arm target) plus all the dependencies. This meant, creating a new distro, and we already had debian/ubuntu for that, let’s use debootstrap! Oh, wait…

Old school

For a start, I took what sebas already started, in fact. Using debootstrap to create a chroot jail that could cross-compile the projects into our platform. This started to prove feasible really soon, as 2 or 3 days after working on it (and after fixing some issues that kept arising, mostly on KF5 itself and packaging), I already started to output binaries that could be deployed on the device.


  • My IDE is outside of the jail, so there isn’t much we can do to integrate at all (we can’t access the build directory, and most of the data in it isn’t too meaningful for the outside anyway). A solution would be to ship and run the IDE from within the SDK though.
  • You need to be root. Not only to generate the system, but also to run it.

New school

An idea I wanted to approach was docker. Everyone on the web world is shit-crazy about it and it’s deeply based on traditional Linux, so there’s quite in common already. Doing something similar to the deboostrap there was a piece of cake, and I managed to re-use the set up code I already had for the previous version.


  • Also everything is inaccessible from the IDE
  • I’m less aware of the limitations I’ll find.

Still, this second approach feels lighter and it’s quite fun to investigate something new like that.


It seems that the jailed systems are the way to go, at least for now, so the tools I’ve created so far assume that they live in the jail as well. So, what do we have?

  • createpkg: Makes it possible to create a deb package that can be sent to the device for testing. It’s much simpler than the simplest deb package ever, but it works. Much better than sending executables over, much better than learning how to package for Debian.
  • deploypkg: sends the deb file, installs it and starts the application.
  • click-get: Downloads a click file from the Ubuntu Store, it’s harder than you’d think.
  • kdev-debdeploy: Does it all, inside your good ol’ IDE.

To be done

  • Workflow: Figure out a way to deploy KDevelop within either jail, but then we’ll also be able to use kde-debdeploy, that does mostly the same as these tools, integrated on the IDE.
  • Emulation: Testing: QEmu + docker anyone?

Suggesting new ways: Kamoso 3.0 Technology Preview

The world changes, and with it, we change too. For this new version of Kamoso we wanted to iterate what we’re presenting.

The Camera

Since we’re using GStreamer, we could take advantage of newer technology available there. Now we’re using camerabin for the video capture (in contrast to using v4l2src directly).
This will offer a better experience, with less tweaks on our side, that will definitely improve the end-user experience.

User Interaction

The whole application wasn’t rewritten, but all the UI was. We have a re-designed interface that integrates some really lean and meaningful animations and sorts the components so that we can get a simple, dialog-free UI.


Sharing is probably the most important feature in Kamoso besides video capture, and we took special care of it. We adopted the new Purpose technology that is seeing its light for the first time with this Technology Preview. We want to make sure that we can offer the best solution by making sure it integrates properly on our UI and it can also be integrated on other parts of KDE. This way we’ll be able to come up with an adequate set of plugins and enjoy them all in community. For now, we have: KDE Connect, Imgur for images and YouTube for videos.

Where to find it?

I put together this little list, so everyone can find the tarballs and packages (on the distributions that managed to package it):

We need you!

We need special help with:

  • Testing, on more cameras, more hardware.
  • Artwork, especially icons.
  • Coding, especially Purpose sharing plugins (Facebook? Twitter? ownCloud?)

But anything else is welcome, as always. Please get in touch!

Identities, I usually don’t stop being myself

One of the most interesting developments I’ve seen recently inside KDE is KAccounts (or Web Accounts, as it used to be called). It’s not even a KDE project, but a project Nokia started some years ago, I’m guessing that on MeeGo days.

Why do I care?

As a developer it’s always very important to know what resources you have available. The more you have, the richer the users’ experience will be. Resources are not only hardware but often just semantically-structured information. For example, KPeople helps us tell apart the contact list and offers us people instead or Solid, that turns the different ways of exposing the hardware information into something easily consumable by front-end applications.

Now we’re talking about identities. We don’t exclusively rely on local data anymore, I think that’s a fact nowadays (and even 5 years ago). Our disks are just another place where we store some of our data. KDE projects must be prepared to easily offer such workflows. One of the important parts to do it properly is authentication:

  • We need a list of available services we can use.
  • We don’t want our users requested identity authentication all the time.
  • We don’t want each application to implement the N authentications algorithms of the N different providers our users will eventually have.

Why do you care? (as a KDE software user)

First of all, you want your developers to have the best tools (GOTO: “Why do I care?”).

There’s a more important issue to figure out, more ideological than technical: We ask service and software providers to use standard specifications to improve interoperability, but then in practice we are seldom leveraging it. The case-by-case set up burden makes it hard for users to have everything configured properly. An example for this is ownCloud integration. I know a couple of people running an instance, but they seldom integrate it in Dolphin, but even if they did they’d still need to integrate the rest of provided services, such as calendar, contacts, etc.
We want to tell our software what providers we have available, those providers will provide different services. The software should integrate as much as possible with those services.

How can I help?

  • Testing: There’s a lot going on, thorough testing and ideas is important. Both when it comes to making sure everything works as expected as well as what software should adopt KAccounts. It will already be available with KDE Applications 15.04.
  • Developing: Make sure your application of choice uses KAccounts to figure out the configured services. Here’s a good place to find documentation: API, and an example use-case.
  • Promotion: It’s important to reach out to service providers, make sure they know there’s such possibility and hopefully they can help us work better with their services (hey! by the book example of a win-win situation!).

Nowadays our computation experience is spread among different services and we need to be smart enough to understand how our users will adopt them and make it as transparent as possible.
AccountsSSO and KAccounts are a solid step forward in this direction, let’s get back in control of our data!

Communicating from Plasma 5

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.

Porting Muon Discover to KF5

Muon has been a project that I’ve been very eager to port and iterate for a longtime. I’m happy with the 2.0 series, lots of changes were made and it has served us well. More importantly though, we have a solid technology to keep pushing our work on.


Now the first change has been the port to Qt5 and KF5 and adoption of QtQuick 2. This has been one of the few projects that have suffered from it, especially because we did a couple of hacks so that Muon Discover would integrate with the rest of applications’ look and feel. In any case, it’s sorted out now, we adopted the new QtQuick Controls and it works quite good, only problem being the usage of QQuickWidget, but that will be solved eventually, when we have everything we need in place to take the next step towards better integration between KXmlGui and QtQuick.

What to expect?

The most important news is that it will be as good and fresh as it used to be, integrated with the newer look and feel themes, capable of offering different sorts of data, such as applications, wallpapers and plasmoids.

Furthermore, some new features will be introduced with the forthcoming Muon 3.0 that will change how we integrate Muon on our systems. First of all, Appstream is being adopted for good. Now it will be possible to get a useful PackageKit backend, which has been adopted recently.

  • Additionally, for the ArchLinux fans, I did some fixing on the PackageKit libalpm backend so now it can be used again. πŸ˜€ Still, work on the Appstream set up is needed and help is very welcome.
  • Since I wanted to use a good PackageKit reference implementation, I looked into Fedora. I’ve been trying to get it working, but haven’t succeeded that much yet. I expected Appstream to be a first class citizen there, and things keep falling apart. We’ll have to work more in this area.
  • Kubuntu will remain using QApt for now. It seems to be working properly and there’s no intentions to change. Debian has also been ported to use use the same backend, we are pending though on some decisions to be taken with regards of metadata sources, that is, Appstream again.

**shrug** Looks like we’ll have to give a good push to Appstream!


I would like to see different Plasma-oriented distributions embracing Muon as a resource management front-end. So far, resource management hasn’t been part of our user experience, with the exception of KNewStuff.

Additionally, there’s a forum thread where a new graphical design is being worked on so it doesn’t look all that clunky (especially managing to make QtQuick Controls applications look good).

All this is already available on our Git repositories. A final version will be released early 2015 together with Plasma 5.2, although I’d like to roll a stable version first, so distributions can start adopting it.

Plasma Next: All for one, and one for all

I haven’t been directly involved in Plasma development in the past a lot, only since very recently, because of my job at BlueSystems. Ever since I started working on the Plasma Desktop Shell, I’ve had 2 important concepts in mind that I’ve tried to follow:

  • The desktop is the place people go when they want to be performant.
  • Let the user focus by offering simple concepts that just work.

So far it’s looking good, I’ve been using it on my system daily and I haven’t had many important problems. Interestingly enough, one of the things I like about Plasma 5 is how it doesn’t try to get you in a spaceship. It does what you expect a shell to do, we’ve focused on making sure this is done properly and that all the tools to extend it are there, in case you want to go crazy. But the Plasma Shell, Plasma is solid.

Going crazyEnhancing Plasma UX

I think we need to, we want to. We thrive on it. The reason we’re developing software is to blow your minds, our mind. On the other hand it’s harmful, it’s much easier to go crazy than to provide a meaningful set of polished features. And we want polished.

But we want features, I want to take advantage of our frameworks and integrate the technologies that drive our lives, everyday, more and more. That’s why I think we want to start working on the services and applications that will complete that Plasma experience that, in the end, will be slightly different for many of us. Because we’re not all the same.

Now let me list some technologies that I’d like to see grow and hopefully help push in the following months.


If you think about it, the ways we communicate over the Internet today and the ways we did 10 or even 15 years ago are essentially the same: we still chat through test, audio and video; we still send e-mails and we still exchange files in unreasonably broken ways. On the other hand it feels different, I think mostly because of using many devices with different sizes.
We want our software to understand these concepts. Different people and even groups of people offer us very rich and colorful semantics we want to be able to embrace both from Plasma and applications.

Having the people around us easily accessible is very important to be performant while still remaining as a simple concept we all understand, we don’t talk to an e-mail account, we talk to a person; only in many different ways.

KDE Connect

If talking to others is important, talking to us is even more important. Everybody I know, works with his phone on the desk and some of them with a tablet in the bag. I don’t think it’s easy getting to be performant if we have to keep checking what’s up on different devices. Furthermore, there’s no technical reason for that, we have KDE Connect. It needs polishing, it needs love but it has huge potential.
One of the things I like the most about KDE Connect is that it’s really easy to adopt. You have it available today on Android (and therefore BBX, Jolla, Ubuntu Phone and a couple others that support android apps), it’s in the way to be on iOS and we have a library you can re-use to take it to your favorite platform, that is obviously supported by Qt 5.

There’s lots of barriers to break there, we want a cloud-based client so you don’t need to have all devices in the same room; we want to break the barrier and see it developed in those new platforms we would never expect to find them. Also we want you to explore with us and find the synchronization nirvana.

My Conclusion

Finding a balance between making something simple and solid, KISS style, and going creative doesn’t go well together, on the other hand Qt and Plasma offers us lots of flexibility, so we have ways to do so.

I decided to go with this Musketeers (or I thought) slogan because it depicts quite well how I see myself using my laptop in some time. Every time less about those little windows and more about aggregating my people and my self, through the different gadgets I carry.


Last, but not least, as usual I’d like to remind you that want to help ensure all this happens in the best of the conditions, you can consider donating to the Randa fundraiser, where KDE will gather and come up with many tools that will render this possible, in the best of the conditions.

Muon Discover, new version, new features, new look

A new Muon release is approaching and I wanted to use this occasion for sum up a little what happened in the Muon area, in view of the forthcoming 2.0 version.

The first thing you’ll notice is the version bump from 1.5 to 2.0. This is because the whole suite had 2 big changes. Firstly, Jonathan reworked libqapt which will be seeing a 2.0 version as well, and I refactored Muon’s internals so that we could have different back-ends in it.

I’m excited about this last change; not only for the features it’s already providing, like the KNS and Bodega backends, but for where I’d like it to go in the near future. We’ll know more about it soon though. πŸ™‚

Another important change, was that we moved some of the Discover UI from QML to better integrate with the rest of KDE applications, specially by using a native scroll bar and prefer the main window’s toolbar to our custom buttons. I’m not much of a graphical person, but I’m quite happy about the result. I hope you are as well.

Here there’s a small video I made for you to see what’s going on in Muon Discover 2.0. I hope you like it and I hope you want it. πŸ™‚

Cheers! \o/

My first year at BlueSystems

About one year ago, the 1st December 2012 I graduated, and by the same dates I started working for BlueSystems. Since we usually consider year periods like achievements, I thought it was a good occasion for a flashback, so there we go!

blue systems logo

  • The KDE GTK Config KCM was my first assignment. It was something new for me but still interesting otherwise. I was more used to work into making applications, there I worked right into helping integrate an important part of the software we have available to KDE. I think it was successful in the sense that many people are starting to take advantage of it and hopefully enjoying the possibility to fully customize the look of all applications, haven’t you tried it already?
  • The second project I worked on was Muon Discover. There I spent most of my time this year, by bringing to KDE a new way to see what you have available for enjoying on your system. I think it’s a very interesting project and I’d like to keep working on it regularly since I think there’s much we can offer there. Of course my work on Muon hasn’t been limited to creating Discover, but I’ve also pushed many different internal changes in order to get different backends. Backends for OCS/KNS and Bodega, will be available from the next Muon version.
  • Furthermore, I’ve tried most of all to help KDE wherever I could. We organized the Pineda sprint, I’ve worked on bringing life to Plasma wallpapers, I’ve committed many fixes in the lower stack of KDE and Plasma Components to make sure everything worked and I put my grain of sand to push the People Framework.

All in all, I’m happy of what we’ve been doing from BlueSystems. I think it’s just starting, we’re doing great work, so keep tuned!

**sigh** When you have fun, time flies!

Cheers, and have happy holidays if you’re having them!

PS: … and this was only what I worked on while sponsored, it’s been a great year indeed. πŸ™‚

Changing wallpapers

The fresh air of the Swiss Alps is good for many things. I came here to work on KDE Edu mostly but I’ll be reporting first about some contribution to Plasma. During the last weeks I’ve been working, during my BlueSystems time, on a new plugin that will let you have a wallpaper written in QtQuick. I think it’s a very interesting step because it will provide a simpler way to draw KDE Plasma Wallpapers that can react to things. For now I created a couple of wallpapers: One that’s really ugly and another one that fetches ASCII animals from the interwebz and makes it move randomly from time to time. The good news is that it just works, that it has not a noticeable performance impact 1, that it’s terribly easy to write one and that it’s incredibly fun to play with them. πŸ™‚

1 if you don’t make expensive stuff in the script, of course PS: if anybody is interested in having such wallpapers working on KDE 4.9, please tell me and we’ll manage it πŸ˜‰