Tag Archives: plasmate

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

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.

GSoC 2012: Make Plasmate Ready For Release, Report 1

This year I have been accepted us a GSoC student and my mentor is Sebastian KĂĽgler. My project is to make plasmate ready for release.  This week my task was to populate plasmate with actions and editing options. Until now plasmate didn’t offer any of the usual actions like undo, redo also the user wasn’t able to modify plasmate’s editing options like indentation.

Also I have prepared a screencast in which you can see how plasmate was before and how it now.