The first results of porting Plasmate to KDevPlatform

In my previous blog post I explained the reasoning behind the port of Plasmate to KDevPlatform but I didn’t mention anything about the progress so far, so here we are 🙂

Plasmate’s UI consists of two different views. The first one is the startpage which serves the purpose of creating new packages and loading existing ones and the second one is the main window with the appropriate editor and the various dockwidgets that can be used for the specific package.

KDevPlatform offers an empty main window which gets populated with plugins. Which offers all the features that plasmate needs, so the decision was to reuse the main window from KDevPlatform and to drop the plasmate one. Which is great because we don’t have to maintain our own and of course we could improve the KDevPlatform’s one if we need to.
Also when the port gets finished we won’t offer all the plugins that are available we will only offer the ones that can be used for the development of plasma packages.  So here we have the plasmate’s main window


Reusing KDevPlatform’s main window means that some changes were required in the startpage in order to integrate it with the main window but the UI hasn’t changed as you can see 🙂


Also as I mentioned before, the main window gets populated with plugins. So the first plugin that I had to implement was the replacement of the plasmate’s file manager. This new plugin is called “Package” in the UI. The main characteristic of the “Package” plugin is that it presents the files of the package with their semantic names. Here we have a plasmoid package and a theme package



From a technical point of view, the plugin is using the KDevelop::ProjectModel which is a QAbstractItemModel and I have just used the QIdentityProxyModel in order to change the names of the files.

Note that the port is in progress so by the end a lot of things will be polished.

Stay tuned! 🙂

Porting plasmate to kdevplatform

The original Plan

Plasmate’s goal is to help people create/test and deploy plasma packages. Originally in KDE4 we offered a clear way on how to use the plasma tools like the embedded plasmoidviewer.  But we were aware that people might not want to use plasmate and instead  use the plasma tools as standalone applications like they used to before the release of plasmate so we were still offering the option of using another IDE and the plasma tools.  Also for every single new feature that we added to plasmate(like the kconfigxteditor) we also provided a standalone application because we wanted to give people the option to continue use their favorite IDE and the new plasma tools. In my opinion the purpose of a software application is to make the life of its users(people) easier. For the ones who don’t use plasmate if we didn’t offer those tools as standalone applications we wouldn’t fulfill our purpose. But it can also get better 🙂

The plan in practice

Personally while I like the original plan I am not happy with the results because  of the maintenance burden and the lack of collaboration, plasmate isn’t alone in the universe. What I didn’t have realized back then was that it takes so much time to maintain a plasmate and also to develop/improve the tools that it offers.  The struggle was real in KDE4 and while we were porting plasmate to KF5.
Plasmate isn’t alone in the universe, its not like people used to code using plasmate in the past years. But there is one IDE which fulfilled that for years, KDevelop 🙂 Until now people were able to use KDevelop and also to switch to the standalone application like plasmoidviewer, but this isn’t the best that plasmate can provide to KDevelop.


KDevelop isn’t a monolithic IDE. KDevelop is an IDE with a lot of plugins which are based on KDevPlatform. Even KDevPlatform isn’t a library, it’s a set of libraries. So extending KDevelop is possible. So this year I was accepted at Google Summer of Code with the project of porting plasmate to kdevplatform.

The benefit

Here we have a win-win situation. All the tools/features of plasmate will be also given as KDevPlatform plugins so KDevelop will be able to use them. In addition to that plasmate will reuse from KDevPlatform everything that it needs which means that I was already able to remove from the plasmate repository more or less 5k LOC (and I haven’t finished yet :))

My next blog post will cover the progress that I made so far with my Google Summer of Code project

Bodega Collections

One of the basic features of the bodega ecosystem are the Collections.
The collections are a set of assets with a common characteristic.
A collection can be something like the “Most Viewed Assets” or “Most Downloaded Assets”.
The bodega-server used to have the collections feature for quite some time now but our
clients didn’t. So during my Google Summer of Code 2013 project I added support for the Collections
in our clients. Below you can see some screenshots from our clients.

Our clients are the bodega-client and bodega-webapp-clientbodega-collections
The bodega-webapp-client is still in the alpha phase, since we focus
more on the native one. We prefer to have a complete client rather than
two incomplete ones :).

Bodega Asset Ratings

One crucial feature for a content store are the ratings of an asset,
every content store needs some ratings in its assets. So we had to figure
out how to handle the ratings in in bodega, my idea was to
use the 5-star rating system. I was thinking “What could go wrong? Its the system that most of
the content systems are using.” well here is what it could go wrong 🙂
The image from the xkcb explains how meaningless is the 5-star rating system. Then Aaron proposed an alternative solution and is the one which we use. Every category of assets would have a few rating attributes
which would have a description and a value. So, here is an example, all the assets of the category games would have rating attributes such as:
  • performance
  • stability
  • playability
those attributes can have values from 1-5 which will have guiding text to help the user decide how to rate the item. for instance, stability might have as 1 star the value “crashes often” and 5 star “rock solid”
During my Google Summer of Code 2013 project I had to implement the ratings feature.
I had to implement the ratings functionality in the bodega-server and to our client. That’s why I was silent about the ratings, I guess making a blog post with some raw json isn’t exciting 🙂 So here is how the ratings look like in the bodega-client
Also all the bodega API is documented at
Contact Info
If you are interesting about bodega you can
contact us at or in #active at freenode

Bodega’s Comment System

Every content system needs a comment system, so does bodega 🙂
For bodega we decided to use discourse.
Of course setting up an instance of discourse wasn’t enough. The
users should be able to log in with their bodega credentials and
they should have a place to discuss about the assets. So the users
are able to log in with their bodega credentials (ok nothing fancy here 🙂 )
and for each asset there is a category in discourse which contains posts and topics.
Here is how a discourse instance for the bodega looks like


Contact Info
If you are interesting about bodega you can
contact us at or in #active at freenode

Bodega Content System Web Application Client

We are happy to announce the move of the Bodega Content System Web Application(bodega web-app)  Client in KDE’s playground. The bodega web-app client is a frontend for the bodega-server like the Addons Store is. We have made a video which presents some of the basic features of the bodega web-app client.

The bodega web-app client is a playground project so its not ready yet, this is just what we have done until now. We have setup the bodega web-app client here in order to make it easier for people to test it and keep an eye on the development of it. 

How To Install It
The Bodega web-app client is completely client-side, in order to install it and test it in your machine you must do

> cd bodega-webapp-client
> npm install (only the first time in order to install the dependencies)
> node app.js

irc channel:
#active @freenode
Mailing List:

Plasmate 1.0-beta1 is out!!

We are very happy to announce the 1.0-beta1 of plasmate. Plasmate is part of the Plasma SDK. The Plasma SDK is consisted of the old kde-workspace tools and plasmate, which is the plasma’s IDE.

Plasmate makes the developement/testing/deployment of your application very easy and fast. Your application can be a plasmoid, dataengine, runner, theme, a Kwin effect, a kwin script and a kwin windows switcher.


Plasmate doesn’t restrict you into a specific language, each package supports a variety of languages which you can use.


The 6 most powerful(at least for me:) features in plasmate are

  • the semantic file browser
  • the embedded plasmoid previewer
  • the konsole previewer
  • the metadata editor
  • the project manager
  • and the kconfigxteditor

The semantic file browser

In order to create a package, this has to follow a certain directory structure, of course plasmate is able to create a package with the correct directory structure but if you don’t know the directory structure in how will you add more files into the package? Plasmate offers a semantic file browser which makes it easier.


The embedded plasmoid previewer


As you can see you don’t need to open and close your plasmoid previewer every time that you change something in your plasmoid(no more switching between your terminals 🙂

of course a nice embedded previewer without some output is useless so..

The konsolepreviewer


The metadata editor


You don’t need to know any entry in the metadata.desktop file, the metadata editor does the job for you!

The project manager

Do you want to install or to publish your plasmoid but you don’t know how?
Well, you do now 🙂



This year in my GSoC project among other stuff I also implemented the KConfigXtEditor. With the KConfigXtEditor you modify/create your xml files which are being used from the KConfigXt framework.


Any feedback is really appreciated in this phase since we are approaching the 1.0 release.
You can find more information about plasmate in our community wiki page.

You can download the complete Plasma SDK from here.

Update: fix the tarball link

Randa Meetings 2012

This September the Randa meetings are from 21 to 27. This is the fourth time
that KDE sprints will take place at Randa. As usual KDE Developers will meet in
order to discuss about the development process in KDE. Last year in Randa the Platform 11 sprint happen, from which crucial decisions were taken about KDE frameworks.

This is the first time that I will attend in the Randa meetings and I am very exciting about it.
I will be together with the plasma team and I will help with the development of libplasma2 which is very important for KDE frameworks. Also we will discuss there about plasmate’s
release. We will have a lot of interesting stuff to discuss about 🙂

All the KDE Developers which will be in the Randa meetings are volunteers so there some
expenses like food and accommodation. A fundraising campaign has started in order to fill in those expenses. You can help KDE by donating some of those expenses and You can make the difference!:)


GSoC 2012: Make Plasmate ready for release, report 3

As I mentioned in my previous report my second task is to implement a remote installer. This week I have fixed the ui and a few things in the logic code, from now on the remote installer doesn’t ask the user to specify a temporary directory. So this is how remote installer looks like right now,

the remote installer as a plasmate plugin

the remote installer as a standalone application

GSoC 2012: Make Plasmate ready for release, report 2

This is my second report for my GSoC 2012 project. This week and the next two coming weeks my task is to implement a remote installer. Except from adding the feature into plasmate we also decided to make the remote installer a standalone application.

So far I have implemented the remote installer both as a standalone application and as a plasmate plugin, but the logic code doesn’t work properly yet.

the remote installer as a plasmate plugin

the remote installer as a standalone application

When the remote installer will be finished you will be able to access the remote installer

  • from plasmate via the publish dialog
  • and as a standalone application named plasmaremoteinstaller

So what’s next?
I don’t really like the ui, so I will try to come up with something nicer 🙂 and of course to fix the logic code which doesn’t work properly.

Also, this week I had to integrate the remote installer inside plasmate’s Publish dialog, so I fixed  some bugs that Publisher had.

Contributing Experiences