Subscribe to Planet KDE feed
Planet KDE -
Updated: 51 min 22 sec ago

KDE Developer Meetings are Not Easy

Fri, 01/30/2015 - 07:09

You thought you had seen every post about Randa Meetings in 2014, right? Or perhaps you posted about Randa and thought you were super late? Well, abandon all hope: this is the definitive latest post about Randa Meetings 2014 :D

The title may not be surprising to you if you have organized a developer meeting before or if you have attended one in which you are close to the ogranizers (e.g. as a volunteer or as a curious person). But coming from a country in Latin America where no serious developer meetings happen, and reading about KDE sprints here and there all the time, you might have an impression that those things happen out of the blue. In my case, I thought there was some sort of machine sprint organizers turned on, put in some money and it would spit out a sprint. Notice that I don’t consider Akademy a developer sprint, so I was very much aware Akademy is an organizational nightmare challenge.

But attending Randa Meetings 2014 changed my perspective about organizing sprints. Starting with the fundraiser, then the coordination of arrivals, and other things we could follow through e-mail and blogs, I was able to see that this organization was big. But that was just part of it. You would have to arrive to Randa and see how the organizers were taking care of details like network access, food, name tags, food, coordination of visit days, food, our field trip and most importantly, and I think I have not mentioned this before… food. This was, of course, the result of the collaboration of many, not only Mario Fux, who is the usual name associated to Randa Meetings. In particular, I have to thank Mario’s family for all the food, which I think was an important part of the meeting and I haven’t mentioned it. I was able to discuss many matters of the organizational details with Mario while we walked from Zermatt to Randa, and this helped me understand the dimensions of organizing a sprint like that one.

KDE has many sprints throughout the year and my experience in Randa has helped me appreciate both the importance and the challenge of organizing these. BlueSystems office in Barcelona has been really helpful in making it easier for people to organize these sprints, but there is still a lot of manual work organizers need to do. You can help and be part of this by donating to KDE.


Getting ready to leave for FOSDEM 2015

Thu, 01/29/2015 - 20:08

It’s almost time to leave and I can’t wait to see my friends from the OpenSource world again and for my first experience at FOSDEM.

I’ve gotten my luggage ready and I’m (almost) ready to leave.


The KDE T-shirts packed and ready for the road.


Route to FOSDEM.


And I’ve prepared my best and most representative T-shirts.


FOSDEM, Here I come!


The Initiation

Thu, 01/29/2015 - 10:30

Hello guys,

It has been almost 2 months since I last wrote about my experiences. The past two months have been quite hectic as I was trying my best to learn and implement the various languages which were suggested by my KDE mentors. Today, I would like to write about what new concepts and languages I have learnt. 

Qt and Qml

Qt and Qml are language for designing user interface–centric applications like different types of games. Qml is majorly used to design the front-end of an application whereas Qt is required for the back-end part.

My mentors at KDE introduced me to these exciting concepts. Qt and Qml were the main things that are required to complete my SoK project in Kanagram. 

When I got to reading about these languages the two best sources were relevant videos on youtube(qt viodrealm channel) and qtporjects.It was pretty obvious from the beginning that I was going to face some serious problems. Problems like not being able to implement the things that I was learning but my mentors at KDE came to my rescue and guided me through the process. 

At this point it is imperative that I write a few things about my mentor Jeremy, Debjit and the KDE community.

The mentors

Jeremy has been contributing to the community for the past few years. He is one of the major contributors and maintainers of Kanagram and many more. Although, I was very interested in what he did in real life but I could ask that question because that would be a severe violation of the "code of conduct"(whatever that is!). He provided me with useful sources like books and links to useful websites. He guided me through the entire process and it would have been truly impossible to do what I did without his help. I am sure that he must be a very busy man but the way he selflessly taught me from scratch was quite amazing. Thanks Jeremy! :)

I was also helped by the KDE community which is harbors some of the most talented people I have ever seen. One of these members is Debjit Mondol,the guy who had been appointed as my mentor for the SoK 2014. He is a major contributor of Kanagram. Incidentally Debjit is a student of Jeremy and since Jeremy was already mentoring few other guys he transferred some of his responsibilities to Debjit and I ended up being mentored by him.

My contributions

  • I have converted the anagram letters to clickable objects for better user interface.
  • The answer field was also made clickable so that the user need not type anything for better user interface. 

The future of Kanagram- Kanagram 15.04
After my SoK completion the Kanagram will be entirely transformed into a user interactive application where the users are given more flexibility. They will be able to click on the letters rather than typing and erasing again and again. 

Final thoughts

I have thoroughly enjoyed the SoK program and it has opened up new avenues for me. It introduced me to things which were previously unknown to me and helped me to enhance my knowledge. This is just the beginning of something which I hope would prove fruitful in the near future. I have a lot more to learn and I am looking forward to working with these amazing people and contributing more and more to this community. 

Plasma 5.2 arrives to Fedora

Wed, 01/28/2015 - 21:01

It’s here! Plasma 5.2 has been released just yesterday and you don’t have to wait a single minute longer to update your beloved Fedora boxes :-)

I won’t go into detail here about all the new awesome things that are waiting for you in Plasma 5.2, but I totally recommend that you go and read Plasma 5.2: The Quintessential Breakdown by Ken Vermette while you are waiting for your package manager to wade through the update. You can also read the official Plasma 5.2 release announcement, it has fancy animated screenshots ;).

And there’s other news related to Plasma 5.2 and Fedora: Fedora rawhide has bee updated to Plasma 5.2 too. This means that KDE SIG will ship Plasma 5 in Fedora 22! Of course we will still maintain the Copr repository for our Fedora 20 and Fedora 21 users.

So, how to get Plasma 5.2 on Fedora?

On rawhide, just do dnf update. On Fedora 20 and Fedora 21, if you are already running Plasma 5.1.2 from dvratil/plasma-5 Copr, then all you need to do is to run dnf update. If you are running Plasma 5.1.95 (aka Plasma 5.2 beta) from dvratil/plasma-5-beta Copr, then it’s time to switch back to stable:

dnf copr disable dvratil/plasma-5-beta dnf copr enable dvratil/plasma-5 dnf update

If you are still running KDE 4 and you want to update to Plasma 5.2, just follow the instructions on dvratil/plasma-5 Copr page.

And if you don’t feel like installing Plasma 5 on your production box right away and would like to just try it out, there’s a live ISO for you. This time I did not forget to add Anaconda, so once you decide that Plasma 5 is good enough for you, you can just install it right from the ISO ;-)

Oh, and if anyone is around in Brno next week for DevConf, let us know and we can informally meet for ceremonious consumption of beer to celebrate the Plasma release ;)

Plasmoid Tutorial 1

Wed, 01/28/2015 - 20:36

With Plasma 5.2 out I wanted to update the tutorials on how to write a Plasmoid. Going through all of the steps from hello world, to using Plasma Components to configuration through to differing form factors.

It made sense to publish them as blog posts before I copy them to the wiki.

Behold, the first rather wordy blog post in a series of 7.


With Plasma5 we have embraced QML as our technology of choice. It is the only method of writing the UI for plasmoids.

Whilst Plasma4 offered a range of language, QML is the only way of interacting with QtQuick, the technology that powers the Plasma Shell. By using this we we get to provide a better developer experience as there is a wealth of existing QML resources. Some of the best links are:

Before you get started with writing plasmoids, it is recommended to read through the basics of these and have a bit of playing to get used to the language.

Writing plasmoids is effectively the same as writing any other QtQuick QML, with a few extensions:

  • We have a specific folder structure with metadata for our plasmashell to be able to load the files.
  • We provide a massive collection of libraries that extend the QtQuick library both with functionality and widgets that blend in with the Plasma theme.
  • Special API exists to interact with the shell, allowing you to save configurations or set default sizes.

In this series of tutorials we'll go through the steps of writing a real plasmoid from scratch, using some of the plasma libraries.

By the end we should have a completely working, deployable RSS reader.

Hello world

Initial Folder Structure

Plasmoids follow the simple KPackage structure. In the top-most folder there should be a file titled metadata.desktop and a single folder called "contents".

Inside the contents folder we place all our QML, assets and other additional files. We split the contents into subdirectories: config, data and ui to make things easier.

The basic directory structure should be as follows:

In our tutorial we will be making an RSS reader so everything is named appropriately to that.


Metadata.desktop [Desktop Entry] Name=RSS Plasmoid Comment=Shows RSS Feeds Encoding=UTF-8 Icon=applications-rss ServiceTypes=Plasma/Applet Type=Service X-KDE-PluginInfo-Author=David Edmundson X-KDE-PluginInfo-Name=org.example.rssplasmoid X-KDE-PluginInfo-License=LGPL X-KDE-PluginInfo-Version=1.0 X-KDE-PluginInfo-Website= X-Plasma-API=declarativeappletscript X-Plasma-MainScript=ui/main.qml

Most of the fields here should be fairly self explanatory.
If in doubt, copy this and change the relevant fields.

main.qml import QtQuick 2.0 Item { Text { anchors.centerIn: parent text: "Hello World!"; } }

Providing you have followed the recommended reading this should be fairly self-explanatory, we have a text item in the middle of the plasmoid which will say "Hello World".

Over the next few tutorials this will get somewhat larger, we will also see some of the problems with this example; here translations aren't implemented and the text won't match the Plasma theme colour.


From the directory above run

plasmapkg2 --install myrssplasmoid

It should now be visible in the plasmashell in the "Add widgets" option along with every other plasmoid.

We can then it to our desktop or panel like any other installed plasmoid.

You will see that that the border and handles are automatically added, and that it is automatically sized to fit the implicit size of the text.


Next tutorial, we will cover getting data from external sources.

Plasma 5.2 Released

Wed, 01/28/2015 - 20:07

Packages for the release of Plasma 5.2 are available for Kubuntu Plasma5 14.10 and our development release. You can get them from the Kubuntu Next Backports PPA.

It includes updates to Qt 5.4 which will remove any Unity packages.

Bugs in the packaging should be reported to kubuntu-ppa on Launchpad. Bugs in the software to KDE.

Planet KDE Theme from Season of KDE

Wed, 01/28/2015 - 18:57

Season KDE is KDE’s annual project to give helpers a more structured way to take part in KDE.  It’s inspired by Summer of Code of course.

Today I had the pleasure of launching the new Planet KDE website theme done by Ranveer Aggarwal.  It looks very lovely and importantly makes the site a pleasure to browse on your phone.  Everyone hug him and do report any bugs to bugzilla.


facebooktwittergoogle_pluslinkedinby feather

Disabling downloadable fonts

Wed, 01/28/2015 - 18:33

We have a nice new style for I think it is generally an improvement over what we had, but sadly it decides to force the oxygen font over my browser selected font.

If you're like me and can stand the oxygen font being forced over the font you chose on your configuration have a look at this article to see how to disable downloadable fonts.

Marble experience in GCI-2014

Wed, 01/28/2015 - 17:49

Hello, guys!

Last post was about my Google Code-in experience in general. This time I want to tell you about my work with Marble.

First of all, what is Marble? Marble is a virtual globe application which allows the user to choose among the Earth, the Moon, Venus, Mars and other planets to display as a 3-D model. It is free software under the terms of the GNU LGPL, developed by KDE for use on personal computers  and smart phones.

(here is a screenshot of Marble)image

So, what did I do for Marble during GCI-2014?

There were different kinds of tasks such as porting different widgets and plugins, I did two such tasks. The tasks I liked most were about creating my own game based on MarbleWidget.

(here is a screenshot of my Marble game)image

One task, which I liked, too, was about creating my own historical map for Marble(in mercator projection). It is based on Baur map from 1870. 

(here is a screenshot of my map run in Marble)image

And the last three tasks were about creating my tour, which can take you to places all over the world. You can watch one here:

Last things I want to say are: special thanks to Torsten Rahn, Abhinav Gangwar and Jonathan Riddell(not from Marble team). These people are the best mentors ever!

 Thanks for attention, use Qt and love KDE!

KDE: SoK Project Final Update

Wed, 01/28/2015 - 00:17

KDE Jenkins DSL Job

KDE Jenkins DSL Job

This will be the last post on this subject with the SoK tag, as the program comes to a close this week. I will however be contining
my efforts past the program dates. With that said..
I have been busy! The last couple weeks I have worked out the job DSL from scratch in Java/Groovy for the job-dsl-plugin.
This of course entailed, dusting off the bits of programming I took in university and learning much more.
My DSL takes a json config file and reads the variables in and proceeds to generate a full fledged job in Jenkins. This
makes job creation much simpler!
Due to the complexity of the task, and the extra effort put in to getting windows and OSX builds to
actually build (beyond the scope of the task) Ben has been nice enough to extend my project beyond the initial sok dates.
I plan on continuing my work with this for as long as necessary, and will maintain it if they allow.
As a student, this opportunity has been invaluable and I encourage anyone in the future that wants that extra experience to
refine your skills to participate in KDE’s Season of KDE! You do not have to be a full time student to apply, I graduated years ago.
My new skillset includes:
Building Qt5 + apps on 3 platforms (Linux, Windows, OSX)
KDE infrastructure

To say the least it has been a wild ride!

Star-Hopper for KStars

Tue, 01/27/2015 - 18:57

Part of my project for Season of KDE was to make a UI for the existing Star-Hopper feature in KStars. I recently got to finishing it and decided to document it.

The Star-Hopper is an amazing feature present in KStars which allows you to find a path between two points in the sky. It is very commonly used in astronomy. If you have a bright star as a reference and you want to find an object in it’s vicinity, you start from your reference star and trace a route to the destination traversing a sequence of stars/pattern of stars.

Here are steps on how to use the Star-Hopper feature in KStars :

  1. Right click on your reference object on the Skymap to get a drop down menu. This object is your start point.
  2. In the drop down menu, select “Starhop from here to” option.
  3. A dotted line will appear. Move the mouse to your destination object and right click on it.
  4. A dialog box requesting for FOV appears. If you have already selected FOV symbols. you will get a drop down menu to select within those FOV symbols. Otherwise you will be asked to enter the FOV in arcminutes.
  5. Upon entering the FOV and clicking okay, you will either be presented with a dialog box containing list of objects in the Starhop route or an error dialog box if the Starhop route couldn’t be computed (mostly because of small FOV)
  6. The dialog box has options to produce details of the object, center the object in the map and go to the next object and center it in the map. It also gives directions to the current selected object below the list of objects.

Hope this blog post helps in using the Star-Hopper features. Any questions, feel free to drop into #kde-kstars

PS : Screenshots aren’t getting uploaded. Shall trying again later.

Cheers! :)

AppStream 0.8 released!

Tue, 01/27/2015 - 16:48

Yesterday I released version 0.8 of AppStream, the cross-distribution standard for software metadata, that is currently used by GNOME-Software, Muon and Apper in to display rich metadata about applications and other software components.

 What’s new?

The new release contains some tweaks on AppStreams documentation, and extends the specification with a few more tags and refinements. For example we now recommend sizes for screenshots. The recommended sizes are the ones GNOME-Software already uses today, and it is a good idea to ship those to make software-centers look great, as others SCs are planning to use them as well. Normal sizes as well as sizes for HiDPI displays are defined. This change affects only the distribution-generated data, the upstream metadata is unaffected by this (the distro-specific metadata generator will resize the screenshots anyway).

Another addition to the spec is the introduction of an optional <source_pkgname/> tag, which holds the source package name the packages defined in <pkgname/> tags are built from. This is mainly for internal use by the distributor, e.g. it can decide to use this information to link to internal resources (like bugtrackers, package-watch etc.). It may also be used by software-center applications as additional information to group software components.

Furthermore, we introduced a <bundle/> tag for future use with 3rd-party application installation solutions. The tag notifies a software-installer about the presence of a 3rd-party application bundle, and provides the necessary information on how to install it. In order to do that, the software-center needs to support the respective installation solution. Currently, the Limba project and Xdg-App bundles are supported. For software managers, it is a good idea to implement support for 3rd-party app installers, as soon as the solutions are ready. Currently, the projects are worked on heavily. The new tag is currently already used by Limba, which is the reason why it depends on the latest AppStream release.

How do I get it?

All AppStream libraries, libappstream, libappstream-qt and libappstream-glib, are supporting the 0.8 specification in their latest version – so in case you are using one of these, you don’t need to do anything. For Debian, the DEP-11 spec is being updated at time, and the changes will land in the DEP-11 tools soon.

Improve your metadata!

This call goes especilly to many KDE projects! Getting good data is partly a task for the distributor, since packaging issues can result in incorrect or broken data, screenshots need to be properly resized etc. However, flawed upstream data can also prevent software from being shown, since software with broken data or missing data will not be incorporated in the distro XML AppStream data file.

Richard Hughes of Fedora has created a nice overview of software failing to be included. You can see the failed-list here – the data can be filtered by desktop environment etc. For KDE projects, a Comment= field is often missing in their .desktop files (or a <summary/> tag needs to be added to their AppStream upstream XML file). Keep in mind that you are not only helping Fedora by fixing these issues, but also all other distributions cosuming the metadata you ship upstream.

For Debian, we will have a similar overview soon, since it is also a very helpful tool to find packaging issues.

Plasma 5.2 for openSUSE? You bet!

Tue, 01/27/2015 - 15:27

The ever-amazing Plasma team from KDE just put out a new release of Plasma. I won’t spend much describing how big of an improvement it is – the release announcement at KDE has all the details needed to whet your appetite.

And of course, now it’s the turn of distributions to get out packages for the users at large.

This is also the case for openSUSE. The KDE:Frameworks5 repository hosts the new 5.2 goodness for released distributions (13.1 and 13.2) and Tumbleweed. Packages have also been submitted to Tumbleweed proper (pending legal review, so it will take some time).

Don’t forget the rule of thumb, in case you find problems: bugs in the packages should be directed towards the openSUSE bugzilla, while issues in the actual software should be reported to KDE. You can also discuss your experience on the KDE Community Forums.

Why screen lockers on X11 cannot be secure

Tue, 01/27/2015 - 11:49

Today we released Plasma 5.2 and this new release comes with two fixes for security vulnerabilities in our screen locker implementation. As I found, exploited, reported and fixed these vulnerabilities I decided to put them a little bit into context.

The first vulnerability concerns our QtQuick user interface for the lock screen. Through the Look and Feel package it was possible to send the login information to a remote location. That’s pretty bad but luckily also only a theoretical problem: we have not yet implemented a way to install new Look and Feel packages from the Internet. So we found the issue before any harm was done.

The second vulnerability is more interesting as it is heavily related to the usage of X11 by the screen locker. To put this vulnerability into context I want to discuss screen lockers on X11 in general. In a previous post I explained that a screen locker has two primary tasks:

  1. Blocking input devices, so that an attacker cannot interact with the running session
  2. Blanking the screen to prevent private information being leaked

From the first requirement we can also derive a requirement that no application should get the input events except the lock screen and that the screen gets locked after a defined idle time. And from the second requirement we can derive that no application should have access to any screen content while the screen is being locked.

With these extended requirements we are already getting into areas where we cannot have a secure screen locker on X11. X11 is too old and too insecure to make it possible to fulfill the requirements. Why is that the case?

X11 on a protocol level doesn’t know anything of screen lockers. This means there is no privileged process which acts as the one and only screen locker. No, a screen locker is just an X11 client like any other (remote or local) X11 client connected to the same X server. This means the screen locker can only use the core functionality available to “emulate” screen locking. Also the X server doesn’t know that the screen is locked as it doesn’t understand the concept. If the screen locker can only use core functionality to emulate screen locking then any other client can do the same and prevent the screen locker from locking the screen, can’t it? And yes that is the case: opening a context menu on any window prevents the screen locker from activating.

That’s quite a bummer: any process connected to the X server can block the screen locker. Even more it could fake your screen locker. How hard would that be? Well I asked that question myself and needed about half an hour to implement an application which looks and behaves like the screen locker provided by Plasma 5. This is so trivial that I don’t see a point in not sharing the code:

#include <QGuiApplication> #include <QQuickView> #include <QQmlContext> #include <QScreen> #include <QStandardPaths> #include <QtQml> class Sessions : public QObject { Q_OBJECT Q_PROPERTY(bool startNewSessionSupported READ trueVal CONSTANT) Q_PROPERTY(bool switchUserSupported READ trueVal CONSTANT) public: explicit Sessions(QObject *parent = 0) : QObject(parent) {} bool trueVal() const { return true; } }; int main(int argc, char **argv) { QGuiApplication app(argc, argv); const QString file = QStandardPaths::locate(QStandardPaths::GenericDataLocation, QStringLiteral("plasma/look-and-feel/org.kde.breeze.desktop/contents/lockscreen/LockScreen.qml")); qmlRegisterType<Sessions>("org.kde.kscreenlocker", 1, 0, "Sessions"); QQuickView view; QQmlContext *c = view.engine()->rootContext(); c->setContextProperty(QStringLiteral("kscreenlocker_userName"), QStringLiteral("Martin Graesslin")); c->setContextProperty(QStringLiteral("kscreenlocker_userImage"), QImage()); view.setFlags(Qt::BypassWindowManagerHint); view.setResizeMode(QQuickView::SizeRootObjectToView); view.setSource(QUrl::fromLocalFile(file));; view.setGeometry(view.screen()->geometry()); view.setKeyboardGrabEnabled(true); view.setMouseGrabEnabled(true); return app.exec(); } #include "main.moc"

This looks like and behaves like the real screen locker, but it isn’t. A user has no chance to recognize that this is not the real locker. Now if it’s that simple to replace the screen locker why should anyone go a complicated way to attack the lock screen? At least I wouldn’t.

And is there nothing which could be done to protect the real locker? Well obviously a good idea is to mark the one and only screen locker as authentic. But how to do that in a secure way on X11? We cannot e.g. show a specific user selected image. This would conflict with another problem with screen lockers on X11: it’s not possible to prevent that other windows grab screen content. So whatever the screen locker displays is also available to all other X11 clients. Also the window manager cannot help like preventing fullscreen windows to open fullscreen as can be seen in the code fragment above: it’s possible to bypass the window manager. Built in feature by X11.

Many of these issues could be considered as non-problematic using the old pragma of “if it runs, it’s trusted”. While I personally disagree, it just doesn’t hold for X11. If only clients of one user were connected to the X server one could say so. But X11 allows clients from other users and even remote clients. And this opens a complete new problem scope. Whenever you use ssh -X you open up your local system to remote attack vectors. If you don’t control the remote side it could mean that the client you start is modified in a way to prevent your screen from locking or to install a fake locker. I know that network transparency is a feature many users love, but it’s just a security night mare. Don’t use it!

Overall we see that attacking a screen locker or preventing that it opens up is really trivial on X11. That’s an inherent problem on the architecture and no implementation can solve them, no matter what the authors tell how secure it is. Compared to these basic attack vectors the vulnerability I found is rather obscure and it takes a considerable amount of understanding how X11 works.

Nevertheless we fixed the issue. And interestingly I chose to use the technology which will solve all those problems: Wayland. While we don’t use Wayland as the windowing system we use a custom domain-specific Wayland-based protocol for the communication between the parts our screen locker architecture. This uses the new libraries developed for later usage in kwin_wayland.

As we are speaking of Wayland: how will Wayland improve the situation? In the case of Plasma the screen locker daemon will be moved from ksmserver to kwin, so that the compositor has more control over it. Screen locking is a dedicated mode supported by the compositor. Whether a context menu is open or not doesn’t matter any more, the screen can be locked. Also the compositor controls input events. If it has the knowledge that the screen is locked, it can ensure that no input goes to the wrong client. Last but not least the compositor controls taking screenshots and thus can prevent that clients can grab the output of the lock screen.

Richard 'RichiH' Hartmann: KDE battery monitor

Sun, 01/25/2015 - 20:44

Dear lazyweb,

using a ThinkPad X1 Carbon with Debian unstable and KDE 4.14.2, I have not had battery warnings for a few weeks, now.

The battery status can be read out via acpi -V as well as via the KDE widget. Hibernation via systemctl hibernate works as well.

What does not work is the warning when my battery is low, or automagic hibernation when shutting the lid or when the battery level is critical.

From what I gather, something in the communication between upower and KDE broke down, but I can't find what it is. I have also been told that Cinnamon is affected as well, so this seems to be a more general problem

Sadly, me and anyone else who's affected has been unable to fix this.

So, dear lazyweb, please help.

In loosely related news, this old status is still valid. UMTS is stable-ish now but even though I saved the SIM's PIN, KDE always displays a "SIM PIN unlock request" prompt after booting or hibernating. Once I enter that PIN, systemd tells me that a system policy prevents the change and wants my user password. If anyone knows how to get rid of that, I would also appreciate any pointers.

A new year and a whole lot of stuff (part 1 of 2)

Sun, 01/25/2015 - 19:44
KDE Project:

It's been an awful while since I last blogged, we all go though periods where things get rather crazy all at once or boring, mine went though both.

It took awhile (try 9 months!), but I started one job but decided to resign half a year later when I felt things didn't connect well. I still wish them all the best, they were nice people. Now, I work at a great Open Source company, Remote Learner, we focus on Moodle and provide upstream patches, new features and addons. I spend my time in the DevOps/Infrastructure side of things with Puppet and random scripts. I have a great team and we do awesome things with git too.

I took some night school classes while among the unemployed, aced them and brought my overall GPA way up, quite pleased about that.

Unexpected Trip
Spent a month in Cape Town, South Africa, went up Table Mountain, climbed down it (using wrong shoes lead to some scary moments!), had a wonderful experience there, and met some people along the way.

Open Source
I didn't run away from the FLOSS community, I've been helping the Fedora QA Team for a couple releases, mostly thrashing Anaconda to improve our installation experience after seeing Fedora 18 and the horror of installation, I jumped in and have helped since.

As for KDE, I'm waiting for Plasma 5.x to be officially released before I look at moving any of my code over (if it's still applicable).

I never usually buy from the TV but picked up a nifty vacuum that even has a reverse blower so I can clean dust out of computer parts, thanks mom! :)

More to come..

[ Part 1 / 2 ]

Help test KDE Bomber game

Sun, 01/25/2015 - 17:57

As Laurent mentioned we are moving some KDE games from kdelibs4-based to kf5-based for the next KDE Applications 15.04 relase.

Today we just switched libkdegames, libkmahjongg and bovo. Next target is bomber, so if you have some time grab the master branch of libkdegames and the frameworks one of bomber, give it a try and make sure we're not regressing somewhere we didn't realize.

The Most Exciting Release in a Long Time

Fri, 01/23/2015 - 12:30

Softpedia writes about our new Alpha 2 release

Kubuntu 15.04 Alpha 2 Is the Most Exciting Release in a Long Time

The first thing people will likely notice is the new look of the distribution and they won’t be disappointed.

An even more impressive review, this time of Plasma 5 on Utopic, is from Ken Vermette.

Plasma 5.2 – The Quintessential Breakdown


digiKam Quick Tip: Transfer Photos from digiKam Directly to a Mobile Device

Fri, 01/23/2015 - 08:51

Provided that you use KDE, you can push photos from digiKam directly to a mobile device that supports the MTP protocol (e.g., most Android devices) using the KioImportExport Kipi plugin.


Continue to read

Season of KDE 2014 Post #2: Nearing Completion

Fri, 01/23/2015 - 00:00

With the season nearing its end, the project I have been on for the past couple of months is almost ready to be deployed. What was the project? Good question! My project was to upgrade, rejuvenate and beautify the very platform on which this post is supposed to be aggregated (I guess if you're reading this, you already know what I'm talking about), our very own Planet KDE. Here's a description of what I was supposed to do in a previous blogpost:


I'm going to highlight the key changes I've made:

  • Flattened the design: Gradients? Marquees? Our friends of the 90's. It's the age of flat-ism and minimalism. Adapting the design philosophy compliant with today's, I have tried to keep things minimalistic, using CSS from several open-sourced sources (No, I do not wget!), and also writing some myself.
  • Mobile-first design: With the number of mobile internet users growing exponentially by the day, why not make something that looks good on your handset? Nobody likes to pinch and scroll in all sorts of directions possible to view the content they want. So, the new design takes care to remove the horizontal scroll to the extent possible and wrapping as much content as possible on your mobile screen. Even the images! Yes, you heard it right. Your images contract with the device size. All this was made possible through the sincere efforts of the creators of CSS3 and also, the developers of Twitter Bootstrap.
  • Cards: Google+ does it. Material design has it. It looks good. Why not PlanetKDE. Well, your posts are now cards. Non-swipe-able, sadly, but they do a good job of separating content.
  • Popups: Not a very ingenious idea, it's been around for quite some time. The point being, group content of relevance - separate irrelevant content.

Basically, the whole thing has a new look. Why isn't it up yet? Well, since it's going to be used by the community, I figured, why not let the community decide what more can be done with it?

To Do
  • Add microblogging feed
  • Support for multiple languages
Pics or it Didn't Happen! (The Screenshots)

Here are a few screenshots from the desktop version:

Also, a few screenshots from the mobile version:

Any reviews/suggestions would be appreciated :)

Experience with KDE till now

I'm being mentored by Jonathan Riddell. He and other members of the community have been really helpful. There were times when I got stuck, and didn't know what to do. I could log into IRC anytime and ask people for help and they readily did. This process has been a great learning experience.