Not for the weak-hearted

My blog has been rather empty lately. It’s not because I haven’t had anything to report, but due to the fact that many things have happened and all sorts of cool things in Plasma Active’s “Activity world” started appearing that I didn’t have the time to write about them.

Today, I’m going to write about one of the smallest things I’ve done lately that will change the world

startkde

startkde script had served us quite well for a long time now, and it is still the best way to start your Plasma session. But it has some downsides that we needed fixed in Plasma Active, and some features that Plasma Active doesn’t need.

So, this post is about an alternative approach to start Plasma, a new application called startactive. It is *NOT* a replacement of startkde, but an alternative. Meaning that it doesn’t do all the things startkde does, while it does some work that startkde doesn’t.

The design

The main goal of startactive’s design was to create a dependency-based system that starts various workspace components.

You can see the dependencies of various systems that startactive invokes in the following graph.

The blue items are meta-modules – they don’t start anything but they make it possible to keep the organization manageable.

Waiting and starting

The system starts all the free modules (modules that don’t depend on anything) at the same time (makes a nice performance boost on both single and multi-core systems), and then waits for some of them to finish until a new module becomes free. When it does, it is automatically started.

There are two ways to see when a dependency has finished its job – 1st – the usual – wait for the process to finish; and 2nd – wait for the program to register its D-Bus service. (org.kde.nepomuk.services.nepomukqueryservice for Nepomuk, org.kde.plasma-desktop for regular Plasma etc.).

Splash screen

Now, when you’re making something that doesn’t need to provide any compatibility with existing systems, you have the freedom to do the things as you see fit. So, I felt free to abandon the old splash screen engines that KDE Workspace used, but to focus only on the QML one I blogged about some time ago. It is now run in-process avoiding dirty ways of communication via X-events and such.

The missing features

startkde does a lot of things, from the initialization of the user’s .kde directory, to fonts, mouse cursors etc.

startactive doesn’t for one simple reason – all of that should be already set up on your Plasma device. All environment variables, Qt plugin locations, directory infrastructure…

Don’t try it

The code is currently located in kde:scratch/ivan/startactive and you shouldn’t use it. Unless you are a really brave soul who doesn’t care if startactive jumps out of the system and start killing kittens in your neighbourhood.

For me, it killed only two older felines, and now it has returned and manages my system with only a few smaller issues. So, if you are brave enough, then continue reading.

To test, you’ll first need to compile it and install with the same prefix as the rest of your kde system, which in turn needs to be in your PATH. Otherwise it will not work.

Then, you’ll need to adapt the module files to fit your setup and finally start the application in an empty X session.

An ordinary startactive will do – it will, by default, start the plasma active module, but if you want to run a desktop session, and change the splash screen theme, you can do something like this:

startactive --modules desktop --splash somethemename

Missing modules

If you notice that something is not started while it should, ping me here or on IRC and tell me about it.

Ok, it is the time for me to blog from Randa and KDE Platform 11 and Nepomuk sprints.

So, what I’ve been up to? I’ve been finishing the backend stuff and the library for registering the “desktop events” aka opening a document, web page and similar. All that is contained in the activity manager, so all the recorded stats will be tied to specific activities.

Share-Like-Connect

One of the side effects of the /usage tracking/ is that we now know what document is currently being viewed/edited, so the Aaron’s S-L-C concept can finally come to life without using the fake dummy data.

Tasks Documents applet

This doesn’t exist yet, but when applications start reporting which documents they are showing, we’ll be able to make a fully document-oriented workspace for those that like that kind of stuff.

Zeitgeist integration

We (Nepomuk – Trueg and myself) and Zeitgeist people (Seif and Trever) had quite a few hours spent deciding the best way for the two systems to collaborate and I think we have done well. Apps that support Zeitgeist will automatically support us as well, and vice-versa. So, whether you are using a Gnome application in KDE, or KDE application in Gnome, it will just work(TM).

As you probably already know, I’m a sucker for fall-backs, so I still intend to make this work even if you disable one of the services. And it will work, but badly if you disable both of them.

Contour and Plasma Active

The thing worth mentioning is that I’m now a part-time member of the Contour team at basysKom, so you can expect these things to be finished faster than it was when I had to give focus to other non KDE-related projects.

This is a short post about one of the interesting events that is going to happen in Randa this summer.

Usually, multiple developer sprints are not held in the same place at the same time, but now we’re gonna have four very important ones from June, 1st to June, 7th in Randa, Switzerland – Platform 11 (kdelibs and kde platform sprint), Nepomuk, Multimedia and KDevelop.

I’ll have to develop a split personality for this one since I’m planning to get involved in P11 and Nepomuk as well. My main purpose over there will be to finish the activities backends and to push a few things into kdelibs.

Join the evolution

Aaron and Sebastian have already blogged about Platform 11 and the Nepomuk sprint so I’m not going to repeat what they said.

I’m just going to add that if you are interested in smarter handling of recent/favourite documents/web pages etc. based on user’s usage statistics and not only on the last access timestamp, if you want to have the possibility to retrieve documents that are tied to a specific project/task youre working on … and other activity-related stuff, you should join us and get the opportunity to discuss these topics in-person.

You might have noticed that this is the first time activities are a part of a sprint that is not Tokamak (Plasma sprint) – it is due to the fact that we’re expanding – the activities are now nicely separated into the libs/data/backends (Platform 11 + Nepomuk sprint) and user interface (Tokamak 5 – soon to be held in Nederlands).

I was (more than) a bit silent lately. The thing called ‘life’ happens and you get dragged away from your computer

The strange thing is that lately, I’ve been doing more artwork than coding, so the new openSUSE 11.4 is fully stripe-themed and (IMO) looks awesome.

I don’t use openSUSE, but that doesn’t mean I should avoid contributing to one of the best KDE experiences out there, right? (Ok, this ended up being a contribution even to Gnome installs which required quite a lot more work, but I don’t really mind)

The additional thing that made my day was the openSUSE review on the Linux Action Show. Chris (one of the hosts) didn’t stick with the original theming, but chose to use the standard blue Stripes with the Slim Glow plasma theme. The only thing better than being the default is being a choice over the default.

Coding again

Well, after reaching the artwork stardom :), I decided it was the time to return to my true calling. The first thing in line were a few Lancelot bugs that needed attention, and that don’t depend on the future libplasma2 development. No new features yet – but stay tuned – there should be some soon.

Activities

The main reason I got involved in developing the activities system in the first place was to have different favourite applications, different usage statistics (files opened, browser history etc.) in different activities. It always seemed daft to have Inkscape, Gimp and similar in the appmenu when I’m doing some non-GUI C++ coding.

The thing that will be responsible for that kind of stuff is the kactivitymanagerd. It currently (4.6) only controls which activities exists (along with icons, names, running/stopped states…), and which one is currently selected.

The next big thing is making it track the user’s behaviour and things that are accessed on per-activity bases. At first the data was supposed to be stored in Nepomuk, but Sebastian raised concerns that it might slow down the database too much (needs to be tested) since it would require a vast amount of data to be stored.

The second option was to use Zeitgeist as proposed by Seif (the lead Z devel). Now that we have a usable Qt API for it, the second option became viable as well.

Since I’m not famous for betting all my money on one horse, I decided to refactor the current code to be able to handle different backends, and use the one(s) that is(are) available.

Features

Currently, the following is planned for the backends:

1. Rating will be automatically calculated based on usage
2. Files, locations, web pages, contacts etc.
3. If the tests show that Nepomuk doesn’t slow down when saving each event individually, this will be a ‘yes’

No-backend support

Naturally, if you don’t want to use Nepomuk nor Zeitgeist, you’ll not get the rating goodness. But that doesn’t mean you’ll be left out – per-activity recent documents, places etc. are still a possibility.

Ok, this was a bit longer than I expected, sorry for that

So, work on activities has been so overwhelming that I’ve had no time to do anything else lately (KDE-related).

Service

First, the kded module and the nepomuk service that were present in KDE SC 4.5 are no more – they are now merged into one application called kactivitymanagerd (KDE ActivityManager Dæmon). The reason behind this rewrite was to have a more stable system (no crashing kded on dbus locks etc.) and to make it easier to maintain.

Identicons

We have new identicons, fully themable. Since one picture is worth more than no picture at all, here they are:

Configuration

As you can see in the screenshot above, there are two corner-actions for each activity – one to stop or delete it, and another one for configuring the name and the icon.

If you remember, the ‘old’ place for configuring the above was in the ‘desktop settings’ dialogue. It was really the wrong place – this is the activity manager, it should manage all related to them.

If Nepomuk is not running, changing the icon will be disabled.

Edit: The layout in the shots is not showing the whole text of the label – it has been fixed.

Smaller stuff

Few of the things above required rewriting quite big chunks of code, removing a more than few hacks and refactoring. So while all that was happening, I had the opportunity to change a few visually irritating things as well. The most important usability problem was the fact that we didn’t differentiate the current activity from the others.

Templates

Others were also busy, so Chani and Mario started making the templating system for creating and sharing activities, but I’m not going to write about that – I’ll leave it to them – I’ll just post a screenshot of what the ‘Add activity’ looks like at the moment.

That’s all for now, so long and thanks for all the squids.

At last Tokamak (Plasma developer sprint), I’ve made a small KWrite proof-of-concept patch just to see how it will behave with the new activities framework – notifying system when it opens and closes a document. A lot of time has passed since, and activity classes were completely revamped, turned upside-down, went through one API review, and moved from the playground to kdebase/libs.

That original patch doesn’t exist anymore, and even if it did, it wouldn’t work for all the changes that were made to activities.

The uber-awesome KDE conference – aKademy – was a time for something new!

New client

Ok, after this introduction you’d expect that I’ve written another patch for KWrite. Well, you’re wrong. The first application that supports activities as a client is Vim!

The main reason I went for Vim this time was to prove that non-kde apps can work with our awesome concept of activities. Another reason is that I didn’t want to use KActivity* classes, so that I can see whether the d-bus protocol is sufficiently profound for this task. It turned out that it is, but there are some improvements to be made.

At the moment, only Vim invoked from a terminal emulator program (eg Konsole) can work with activities since I can’t find a way to retrieve the window id of a GUI-enabled Vim from vimscript, so I’m essentially using WINDOWID environment variable that terminal emulators set.

The following is a debugging output of the activity manager daemon related to Vim windows

resourceWindowRegistered: 54526034 file:///home/ivan/mailacc.txt
resourceWindowUnregistered: 54526034 file:///home/ivan/.vimrc
resourceWindowRegistered: 85983274 file:///home/ivan/
resourceWindowRegistered: 85983274 file:///usr/share/vim/vim72/doc/options.txt

Truly limitless possibilities!!!

^^^^ just wanted to write an awesome marketing-speak sentence for the end of the post

This one will be short, I don’t really have the will for writing – it is half past midnight here.

The activities infrastructure is mostly finished – now only polishing is left to be done.

The new organization goes like this:

The core activity-related features are placed into a kded module which doesn’t depend on anything but Qt and the core kde libraries. The class for writing the clients of this service (any program that wants to be able to react to activity changes etc.) will be in kdelibs. The API is minimal and very easy to use – it took me only a couple of minutes to patch KWrite to be able to use activities.

The second part is the revamped Nepomuk Activities service (I already blogged about it – the changes made at T4 were mainly related to make it fit the new arhitecture). If it is running, the above class passes all the info to it. Running the service enables the access to extra meta-data regarding documents and activities.

The third, and last part is the manager class which will be in kdebase/workspace (most probably) because it is only intended to be used by kwin and plasma. Normal programs shouldn’t use it.

The next step is the UI – kwin and plasma

Cheerio.

Unfortunately, the activities service didn’t make it into 4.4 because there wasn’t enough time for it to pass on from kdereview into kdebase. This means that it was returned to playground for further processing.

The service has grown a bit and now it exposes a few more methods like linking activities to other nepomuk resources (documents, places…).

KIO

Since the service is not really useful by itself (from the user’s point of view), it will need some kind of UI. The main UI will be Plasma and the ZUI replacement which will be one of the Tokamak4′s main topics.

For the time being, I made a KIO slave shown in the picture above. It lists the defined activities and the resources linked to it. At the moment, the resources are limited to Applications, Documents, Places and Contacts (I’ve just realized that those are the same sections that are in Lancelot – completely by accident).

The data shown in the picture is a garbage data I put into nepomuk for the sake of testing (no sane person would put Thumbs.db in the work-related documents.

First of all, let me just say that Tokamak 3 experience was more fun than riding on a carrousel under the influence of LSD (or so I heard) and more strange than some of the episodes of the Monty Python’s Flying Circus (which was, by the way, quoted many times – mostly by Aaron and me).

All kudos go to Mario, the father of our big Takamak family, and all in all a swell guy. We taught the Brazilians (Ana and Artur) what snow is, and I think they will remember it for a long time

Ok, enough about the fun parts. You were/are able to read about many things that were done during T3, so I’ll not bother you with the others’ work. I’m just going to write an update to the last post.

KRunner + Kickoff

Kickoff in trunk now uses KRunner as its search engine. There are a few bugs and a few concerns about functionality that will be resolved soon.

At the moment, all runners in KRunner are active in Kickoff as well, but that will change since we’ll need to make a whitelist of approved runners to avoid Kickoff crashing the plasma-desktop process on an error in KRunner. This means that Kickoff’s search will be less powerful than the KRunner and Lancelot, but that’s the price of running in the plasma-desktop process.

Plasma + Nepomuk

The service for activities runs well and is located in the playground, and so is the testing client.
The current work is to completely integrate it into Plasma which has proven to be more complicated than I expected at first. The thing that makes it hard is the need of libplasma to stay API and ABI compatible. The Plasma::Context class has been introduced some time ago, but it did nothing and some methods defined in it weren’t sufficiently granular.

At first I tried to implement everything with no API changes, but I’ve hit a wall very soon and had to deprecate a few methods, and introduce a new class named GlobalContext. It seems to work, so I’ve now switched on to implement the handlers in the plasma-desktop. I hope to have it working till the end of the week so that I could post it all for an API review.

Favourite applications

I was hoping to have more time to talk to Ruphy about making a library for handling the usage data and favourite applications handling (to be used in Raptor and Lancelot… and possibly in other menus) but Ruphy could stay for only a few days. I’ll have to start the discussion about this on plasma-devel when I finish the activity stuff and when I look the relevant parts of Raptor’s code.

Photos…

Photos will come later… hopefully from other guys and gals aswell (torrent comes to mind)