For the library, the requirement will be GCC 4.6, clang 3.0 or whatever version of MSVC++ has the equivalent features. GCC 4.6 is chosen since it will be a dependency of Qt 5, so eventually the rest of KDElibs/KDE Frameworks will foolow suit.

Since GCC is the main targeted compiler, the library will be regularly tested against 4.6. For Clang, I’ll test with the latest version provided by Debian (currently 3.0).

With that said, I don’t expect that the library will really be uncompilable with older compilers, it is just that I have no intention keeping the compatibility and testing for it.

Service

For the service, the requirement will be more obvious – compilation will likely fail on older compilers. I’m currently pondering whether to require GCC 4.6 or 4.7. The later has some rather nice additions from C++11 standard (that are present in Clang 3.0) like Non-static data member initializers (N2756), Template aliases (N2258), Delegating constructors (N1986), Explicit virtual overrides (N2928, N3206, N3272).

I guess I’ll start of with 4.6 and see whether it is enough and whether I can live without a few adorable N****s

Edit: Regarding kde-core-devel – I will start this discussion on k-c-d once 4.9 is out of the door. The point of this post is to test the public responses. Don’t want to bother everybody on k-c-d for something that is not intended for this release.

In short, it will not. You’ll need to wait, or risk your data.

Status

Essentially, the encryption works. There are also some neat features like if your screensaver is started, the current activity (if marked as private) gets automatically locked. Only one activity is unlocked at a time – it is automatically locked when you switch to another activity. The files/documents you link to a private activity are automatically moved into the encrypted filesystem and removed from the original location. And so on…

So, what doesn’t work?

There’s no UI to set the activity as private (at least, not in the Plasma Desktop). And this is intentional. Security is not something that I take for granted. Anything related to privacy needs to be tested by us before we push it into the hands of ordinary users.

This means that the implementation is there, and is present in 4.9, but it is not available to you if you don’t plan to experiment and get your hands dirty.

What are the known issues?

The files on the encrypted partition are (without custom patches to kdelibs and co.) not treated any special by Nepomuk. This means that either (1) the files will be indexed as if they were public, (2) the will not be visible to nepomuk at all (which would render the /link to activity/ useless) or (3) the files will be in nepomuk without any sensitive data and without the possibility to be reindexed. This is not something that I’m satisfied with, and I’m considering it a big release blocker.

I want to try it anyway!

If you are sure that you want to use this feature now, and want to avoid the issues mentioned above, you can do the following:

# get the uuid of the current activity:
qdbus org.kde.ActivityManager /ActivityManager \
      CurrentActivity
# use that result in the following line:
qdbus org.kde.ActivityManager /ActivityManager \
      SetActivityEncrypted UUID-of-the-activity 1

You’ll be asked for the password to use for the encryption.

When this is done, the FUSE encfs system will be set up and you’ll be able to use it. But do use it directly – save files in the encrypted folder manually, delete them manually and so on. Do not /link files to a private activity/ don’t mark as private an activity that already has some files linked to it.

If you follow the above, you will not experience any nepomuk indexing related issues, while being able to keep sensitive data encrypted.

Edit:

KIO

Previously mentioned KIO slave is able to browse the private activities, so you have no need to know where the activity manager mounts the encrypted filesystem.

The reason for this taking so long is that KWin <-> Activities relationship started in the era when I did the activity manager related things (aka /the under the hood stuff/) while Chani connected them to Plassma and KWin. She is not working on KDE anymore, so these areas got a bit forgotten.

Now, the feature will be finally available in KDE SC 4.9.

So, how to make this available to the normal users, you ask? Easy – make it available to the normal file managers via KIO – just type activities:/ in Dolphin, Konqueror or the Folder View applet, and you’ll get a list of all activities, and files that belong to them.

You can see what it looks like in the screenshots. At the moment, it is a bit buggy, but it will work as expected for SC 4.9.

The new fun and fancy feature of Activities is being able to link files and folders to activities by right-clicking them in Dolphin, Konqueror, Folder View. You can see what it looks like in the screenshots.

The first screenshot shows the menu for a single file, while the second shows it for a multi-item selection.

What’s the point?

Currently, this doesn’t do much – you can show the linked files on your desktop if you set your desktop layout to be contour (not the whole Plasma Active, but only the widget layout).

And soon, I’m planning to also have a KIO implemented so that you can browse all the linked files by browsing activities://something/…

Now is the time to bring some of the features that proved to be useful to common Plasma users, and, for this, I’ll need help from everyone, be it brainstorming or even coding. This post is meant to introduce to you what technologies are going to be available to build upon.

You should post all your ideas to the KDE Workspace Vision part of our forums.

Linking the documents to activities

Background: One of the purposes of activities is to link documents (including web pages, images, etc.), applications, contacts etc. that are related to the activity so that you can access them faster. Apart from manually telling the system which resources belong to an activity, the goal is to have the system score the documents based on the number of times you’ve used them in a specific activity*.

So here are some of the ideas I plan to make reality.

• Manual linking of files by right-clicking them in dolphin.
• Linking via Share-Like-Connect applet – eventually, when most of our applications get patched to report the documents they open to the activity manager, we’ll know which document is in focus at any given time. This way, we’ll have global (in the panel) buttons to share the document, bookmark it, link it to the activity.
• Linking contacts from Kontact, Telepathy and similar
• Linking the highest scored documents automatically or semi-automatically
• Have the favourite applications section in menus dependent on the activity
• Rank krunner results according to the scores
• Browsing the resources that belong to the activity with Dolphin (and file open/save dialogue)
• Showing all that in the Shelf applet

* actually, it is a little bit more complex than that, but it is irrelevant for this purpose.

Other simpler things

• System settings module for advanced activity configuration – the name and icon setup plasma provides is a bit underwhelming
  • Setting the basic activity info, creating and deleting
  • Setting whether the activity is private (requires a password to be unlocked, data is encrypted) – see Encryption in KDE SC
  • Setting whether the usage statistics should not be collected in a specific activity at all, or only for certain applications

Dreams

• Automatic grouping of documents that relate to each other based on the usage statistics (for example, the literature you used while writing a scientific paper)
• …

Help

So, the thing that I need from all of our awesome users is to polish these ideas, create new and more awesome ones, etc.

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.

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.

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

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.