One of the problems that the Nepomuk team had in the past were crashes in the strigi library (usually because of a corrupted file or similar). For that reason, the indexer was moved into a separate process, and it was executed for each file individually.

This is generally a good practice – ensuring that components can not crash the main server. For those who don’t know this, Nepomuk server invokes a few out-of-process services so that those can’t crash each other. And, as already stated, the file indexer service delegates the work to an external process. This is a rather nice design – hierarchical separation of risky components into external processes.

While this brings stability, it is not cheap. Launching processes takes valuable CPU time (loading, linking and other things your OS does whenever you start a program). This is not a big issue for Nepomuk’s services since there are only a few of them, and they are started only once, when the system boots.

But it was the issue with the indexer since the executable was being run for each file that needed indexing. This is not something that I was comfortable with, so I decided to make it a bit more sophisticated, without decreasing stability.

Now, the external indexer process is started only once, and the server feeds it with a list of files that need indexing – one by one. If the indexer crashes, the server just restarts it and continues without a glitch.

Nepomuk is a very nice shared data repository. It is an easy way to make the data from your application available to others.

But, it is important to know that Nepomuk is not a general purpose database – everything is peachy until you start using it as such. And especially if you start treating it as a relational database.

There are a few things to keep in mind when developing Nepomuk-based programs.

Working on graphs

Nepomuk is a graph database – this means that the data is not organized into tables live you’ve used to, but as nodes and connections between them.

So, any query you make is not a restriction on a relation (a table) but rather a multi-join of a single subject-verb-object table (this is a bit simplistic view).

As you probably know, doing joins is not really a cheap operation however optimized it is (and Virtuoso is one of the fastest graph databases available).

D-Bus connections

The second thing is that while Nepomuk-internal connections are done via local sockets, your connection to Nepomuk goes through D-Bus which is not the fastest kid on the block. The more requests you make, the more time it will take.

Some hints

There are some things you can make to make these issues less relevant to your applications.

Wide-table queries

One of the common ways people write queries is the following:

    select ?r where {
        ?r a something .
        ?r something else . 
        ...
    }

And then process the results one by one by doing stuff like:

    resource.getProperty(something);
    resource.getProperty(something else);
    ...

Which means your program creates a lot of queries – one main, and a couple more for each result.

Instead of making a lot of queries, it is advisable (although initially not that intuitive) to create one big query like this:

    select ?r, ?prop1, ?prop2 where {
        ?r a ?prop1 .
        ?r something ?prop2 . 
        ...
    }

It does transfer a lot of data at once, but at least it does so in a single request-response connection, and it doesn’t repeat the same query (parsing, optimizing, evaluating) multiple times for different parameters.

Consider storing some data locally

If you have data that don’t necessarily need to be shared, consider storing it in config files, embedded database like sqlite3 or similar.

This way, apart from skipping D-Bus, you can have faster queries in the cases like these (which are not at all rare):

    select ?r where {
        ?r a someType .
        ?r property1 "value1" .
        ?r property2 "value2" .
        ...
    }

This query does a number of joins, whereas its equivalent in SQL does only filtering:

    select * from someType where
        property1 = "value1" and
        property2 = "value2" and
        ...
    

Summary

So, whatever you do (be it Nepomuk or something else), first ask, experiment, test and learn the system before using it.

Just a short note for everyone using anything from the kext ontology that is related to activities – since today, kext:Activity and friends don’t exist. Everything is moved from kext to kao (KActivities Ontology)

There are a lot of news regarding the activity manager, but nothing picture-worthy so I’ll skip writing about it.

Security in activities

There is something that a few people here and there have been requesting – having some automatic (UI) way to create encrypted folders to keep their sensitive data in.

The thing I’m going to talk about today is exactly that – starting with KDE SC 4.9 you’ll be able to decide to encrypt specific activities. When you do that, you’ll get a ~/Activities/Something folder that is password protected and encrypted using fuse/encfs.

The encryption/decription process will be done automatically on activity switching.

For example, lets say you have two activities – Leisure and MI5 – with the latter being an encrypted activity. When you switch to the MI5 activity, you’ll be asked for its password and you’ll be able to access the data. When you switch back to the Leisure activity, the system for the previous one will be automatically unmounted.

Plasma Active Three

One of the reasons behind this new feature is PA3. You’ll have a portable device that can be stolen, that could be used by your children (while being single-user) for fun etc. and you don’t want some data to be visible to them.

In the case of PA, since there is no file manager and we don’t want to expose the file-system to the user, every document that you link to the activity will be automatically moved to the encrypted folder.

Drawbacks

There are a couple features that will stop working with encrypted activities – you will not be able to search encrypted documents by contents since the contents will not be indexed by nepomuk, and documents will not be able to belong to multiple activities if one of them is encrypted.

Edit: Cool, thanks for the input! I get the gist what is the common format. There are some unpredictable ones, but I think we could come up with some not-useless heuristic to deduce whether two wifis are at the same institution.

Hi all, I need the following information from out awesome users – what are the names of the wifi networks you are using when you are at some institution or something. I don’t need the exact names, just the format.

So, for example, at my faculty. we have names that follow this pattern: faculty_name-classroom_number (eg. Abcd-122). At the math institute, it is something and something2.

Please write your strange formats

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.

This is something I realised after reading some blogs on the intertubes – I’m bad

ZZ Top – I’m bad, I’m nationwide

I can’t wait to get my doctorate to become a Proper Villain (TM) like Dr Doom, Dr Evil …

If you were to pass by Sebas’ house these last few days of Tokamak 5, you’d see a window full of post-its that contained tasks that we plan to do (can be seen on Kevin’s blog).

One of the post-its was 1/8 in size compared to the normal ones and it only said TSP, an abbreviation for ‘The Secret Project’. I didn’t want to tell anyone what I was doing until I see what comes out of it.

So, after meddling with Xlib, strange code-paths in kde-workspace I’m proud to present a new splash screen engine that can do QML.

Why this? The main reason is that creating new splash screens currently sucks – everything is prerendered and the theme authors don’t really have any control over the process. That is probably the main reason we still have basically the same splash screen as we did in KDE (SC) 3.x.

Currently under a GIT branch of kde-workspace, KSplashQML allows the theme creator to define the animations in a more pleasant manner, to adapt the animation to the screen size…

The theme is rather simple – black/white KDE logo with rotating gear that fades into the logo that can be seen in the screenshot. If you are wondering why the text says ‘Friday’, it is because we are recognizing the fantastic song made popular by our idol Rebecca.

Tokamak 5 is approaching the end – only Marco and I still linger around (and Sebas, naturally) – and that is going to end tomorrow around noon.

So, as you all should already know, Tokamak 5 (plasma developer sprint) is in progress. The main desktop-related thing I’ve been working on last two days was presenting a few chosen activity templates as if those were real.

What does this mean? That you’ll see a couple of activities in your activity bar that don’t really exist. This was done, along some other stuff, to promote the activities a bit more.

Currently, as far as I know (as usual, I’m the backend guy and have no clue what will end up in the release for the user to see ) the only one /fake/ activity you’ll see is the ‘Photos activity’. It is meant for something that we all enjoy – managing our photo collections.

Before you start arguing that you don’t want to see a bunch of templates in your list of activities, this affects only the defaults – you can easily remove them like any other activity – click the red ‘x’ and you’re done.

Running applications

Apart from defining the widgets layout, templates are now able even to start applications. In the case of the ‘Photos’ activity, it will start Digikam and Gwenview.

Since the templates can be downloaded via GHNS (from kde-look and similar sites), automatic execution of apps is rather dangerous, so you’ll be asked for the confirmation on which programs to run.

You can see what it looks like in the screenshot above. Recognized desktop applications are presented with their names and icons, and are automatically selected. While other programs (like in this case ‘rm’) will have a warning icon in front and will be automatically deselected.

EDIT: I’ve just added a rather rigid test for the ‘safety’ of apps – the application is automatically selected only if it is a registered desktop application and it doesn’t have more than one argument specified. So, the things like konsole -e ‘something’ are not going to be selected by default.

As Notmart said “I have a dream!”. (I have no clue what this sentence has to do with the blog post, but I didn’t want to finish it with the usual ‘that’s all for now’ )

I’ve been interested in Telepathy for some time now. And every time it was mentioned on PlanetKDE, I wanted to test it. Some things worked, some not. Now, that the important ones are functional – system settings module, contact list, chat window – I decided to start the preparations for Lancelot to switch from Kopete to Telepathy.

So far, I’ve managed to display the list of accounts, and it will soon show the contacts as well.

Plans for 4.7

AFAIK, Telepathy will not be replacing Kopete in 4.7, so Lancelot will still be using the old (current) contacts model.

With that said, there will be a possibility to use the Telepathy model in the Shelf applet – it will be available via the configuration dialogue.

For Lancelot, I’ll probably make a hidden (non-UI) option.

That’s all for now.