Just a teaser:

KDE software tends to require mysql as the database engine (either a hard requirement like Amarok, or recommended backend like in Akonadi) so things like these genuinely worry me:

Disappearing test cases or did another part of MySQL just become closed source?

Thoughts? MariaDB? PostgreSQL? …

p.s. I don’t have influence on amarok nor akonadi, just want to see what the people think

Dolphin got the ability to send the events when the user opens a directory to the activity manager. It is quite a small patch that I decided to share in order to demonstrate how easy it is to use KActivities API

Simple example

Find the widget that displays your document (in this case, a folder). Declare one KActivities::ResourceInstance object inside it

KActivities::ResourceInstance * 
        m_activityResourceInstance;

When you create the container, just create a new ResourceInstance and pass the window id (of the top-level window that your container resides in) and the url you just opened:

DolphinViewContainer::DolphinViewContainer
    (const KUrl& url, QWidget* parent)
{
    :::

    #ifdef KActivities_FOUND
    m_activityResourceInstance
        = new KActivities::ResourceInstance(
            window()->winId(), url
        );
    m_activityResourceInstance->setParent(this);
    #endif

    :::
}

This is it if you have a SDI (single-document interface) – interface where one main window can contain only one document (okular, kwrite etc.)

MDI

If you have a possibility to have multiple documents inside one window (dolphin, konqueror, kate etc.), you’ll need to do some additional things:

If your component lost the user’s focus (switched to another document), call:

    m_activityResourceInstance->notifyFocusedOut()

When it receives the focus, call:

    m_activityResourceInstance->notifyFocusedIn()

And when the url of the document that is shown changes (user opens another file, navigates to another web page), just call:

    m_activityResourceInstance->setUri(newUrl);

This is all.

Why?

This info is used for the share-like-connect applet and to rank the locations users visit. This can be, in turn, used to sort applications, documents etc. in krunner based on the ranking; to show most recent documents for pinned applications in the task bar etc.

Privacy

Although every system tracks the user’s behaviour in some way, it might not be something the user desires. This will be configurable – see this for more info

For the whole ResourceInstance API, see: api.kde.org/KActivities::ResourceInstance

I’ve just committed a helper script to KDE Activities that gets into all different build directories for the project you’re compiling, and runs the compilation. If all compiles successfully, it calls git commit.

I have decided to compile kactivities on a regular basis with GCC 4.7 (my default compiler), GCC 4.5 and Clang 3.1 to ensure no compiler specific things are being used, and no C++11 features that GCC 4.5 doesn’t support.

If anyone is interested, here it is:

#!/bin/bash

# The script finds build directories for the current
# src directory and builds them
#
# For example, for the source dir:
#   /some/path/kde/src/project/whatever
# It finds:
#   /some/path/kde/build*/project/whatever

current_dir=`pwd`

all_root_dir=`pwd | sed 's#/src/.*##'`
src_root_dir=$all_root_dir/src

echo "src:   $src_root_dir"

for build_root_dir in $all_root_dir/build*; do
    echo "building in $build_root_dir"

    cd $current_dir
    current_dir_log=`OBJ_REPLACEMENT=s#$src_root_dir#$build_root_dir# makeobj`
    if [ "$?" = "0" ]
    then
        echo "... success"
    else
        echo "... FAILED"
        echo $current_dir_log
        exit
    fi
done

git commit

Activities have some hidden features, some that can even be configured, but not from the UI. They also have a nice plugins system that is far from the user’s eyes.

I am planning to make a system settings module for it, but haven’t gotten to do it yet. The configuration in the plasma‘s activity browser panel just doesn’t cut it anymore.

It would be quite nice if someone stepped up to implement at least some parts of it. Even starting and leading a discussion on the mailing list regarding the UI would be beneficial.

There are some similarities between kwin and kamd in this regard. Plugins could be shown like kwin effects are, in a list, but some of them provide features that should be shown in a more pleasant way.

These are the features that need to be covered OTOH:

• Creation and deletion of activities, and the other things currently available in the activity browser
• Configuring which applications should be tracked (record which documents they open) – globally and per-activity
• Private activities – setup, do-not-track option, extendable to include more features
• more…

The session (ksmserver) code in the activity manager (KAMD) has lingered since its inception. Everybody ignored it and kept far away like it is an ugly duckling, even its original authoress. It never worked properly, and had quite a dirty implementation.

The code in KAMD was refactored, polished, dusted for many times since then, it even learnt a new language (C++11). But the ugly duckling remained locked in the dark. Even spiders left since there was no free space to left for a new cobweb.

Not anymore!

I’ve just rewritten it and moved all ksmserver/kwin things in a separate class. The new version is pushed into master an hour ago.

I need testers (edit: somehow this title got lost while publishing)

Since I’ve never used the session mechanism and start/stop for activities, I have no clue whether it works as bad^Wgood as it did before. I’ve tested it a bit, but that might not be enough, and it could still have some regressions.

Not Anymore?

Now, we are back to the sad story of the aforementioned duckling.

I haven’t done this because I wanted to work on it, but contrary – because I wanted to move it far from my sight.

This part of KAMD is now officially unmaintained (edit: or “done”). Since it is working, it will not be removed from the codebase, but don’t expect any significant improvements from my side.

If anyone thinks that

• there are bugs that need fixing
• there are features missing
• anything else…

help yourself to the code and start sending patches. I will, naturally, try to help as much as I can.

Edit: More explanation

Somehow, it seems that everybody thinks I want to drop the code.

It is going to stay in KAMD.

It should already have the features it had before. If it doesn’t, report the issue. I intend to fix the regressions. That is why I asked for testers.

So, then, what is the problem?

The whole activity session system had some issues that are not a fault of the code in KAMD, but the session protocol itself which was not designed to be used for this purpose.

Essentially, what I’m saying is that the feature will work as it did before. And will not be developed upon, as it wasn’t since it was created.

In that aspect, nothing has changed.

Chani, while she worked on these things, had a few very nice ideas about session stuff that included a new protocol specification, new session management in ksmserver, etc. etc. It would need changes all over KDE, probably Qt, etc. I don’t have the time to continue her work. See this for inspiration.

So a summary: Everything is as it was before. New features and some existing issues can’t be solved with the current underlying infrastructure. And I don’t have the time to work on the infrastructure.

A long time ago in a galaxy far away there was a non-KDE application that supported activities. That is, reporting opened documents to the activity manager (KAMD).

That code was essentially left for dead. Mainly due to some missing features and changes in the activity manager’s API. It was the time to play Dr Frankenstein and to pick up the pieces to revive this beast.

The Share·Like·Connect problem

While the normal part (statistics collector) of KAMD can work well with an application only reporting which document was opened (like the previous version of the vim plugin did), SLC needs one more info – the window id.

At the time, there was no way to get a window id out of GUI Vim if you’re under X11. It was introduced in later versions, but might not be present on your system. So, in those cases, there needed to be a different approach of getting the valuable data.

Enter the python scripting and Xlib

Here it gets painful. While writing vim scripts in python is rather pleasant, and my usual choice, playing around with Xlib is very irritating. The problem at hand, essentially boils down to getting the process ID (os.getpid) and finding a window that has _NET_WM_PID set to that value. Sounds trivial, yet it needs >50 lines of readable code due to the need to traverse the window tree hierarchy:

01 import os, sys, Xlib
02 from Xlib import X, display, Xatom
03 
04 # Doing dirty things to stop Xlib from
05 # writing to stdout
06 # Xlib.display.Display()
07 #     Xlib.protocol.request.QueryExtension
08 old_stdout = sys.stdout
09 sys.stdout = open("/dev/null", "w")
10 display    = Xlib.display.Display()
11 screen     = display.screen()
12 sys.stdout.close()
13 sys.stdout = old_stdout
14 
15 def _processWindow(win, atom, processId, level = 0):
16     result = set()
17 
18     response = win.get_full_property(atom, Xatom.CARDINAL);
19 
20     found = False
21 
22     # Testing whether the response was valid
23     # and whether we found a proper process id
24     if response != None:
25         for pid in response.value:
26             if pid == processId:
27                 result.add(win.id)
28                 found = True
29 
30     # If we have found the window, we don't
31     # search its children
32     if not found:
33         for child in win.query_tree().children:
34             result |= _processWindow(child, atom, processId, level + 1)
35 
36     return result
37 
38 # Gets the window IDs that belong to the specified process
39 def getWindowIds(processId):
40
41     root = screen.root;
42     tree = root.query_tree();
43     wins = tree.children;
44     atom = display.intern_atom("_NET_WM_PID", 1);
45 
46     # recursively searches the window tree
47     # for the one that has a desired pid
48     result = set()
49 
50     for win in wins:
51         result |= _processWindow(win, atom, processId)
52 
53     return result
54 
55 # Gets the window IDs that belong to the current process
56 def getWindowIdsForCurrentProcess():
57     return getWindowIds(os.getpid())

Guessing it can be shorter, maybe Xlib has some magic methods to do this, maybe they are exported to the Python binding, but I haven’t found them.

No GVim, just Konsole and Vim?

If you don’t use GVim, but like to start normal Vim as a part of your Konsole session, the former approach doesn’t work. The window doesn’t belong to Vim’s process. Now, you’d say this will be a more difficult thing to solve than the above. But, alas, Konsole (and I guess a few other terminal emulators as well) is quite nice and provides an environment variable called WINDOWID.

Strange, right? Getting a window id for a non-gui Vim is easier than for GVim.

The only downside in this case is that Vim can’t tell when you switch to another tab in Konsole, so SLC still thinks that the document from the previous tab is shown. But, it is a rather minor nuance to really pay attention to.

The code and Emacs

The code is and will be in kde:activities-support.

It would be rather nice if somebody ported this to Emacs, so that we can cover two most popular geek editors in the world.

Others…

There is one more plugin coming. For one of the most popular applications on all platforms. But I’m not going to reveal it just yet.

I’ll start patching applications from the KDE world once we release 4.9, and get out of the feature-freeze period.

After the KDE SC 4.9 is released, projects inside KDE Projects: Activities will start requiring more up-to-date compilers and will start (ab)using more modern C++.

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.

Some time ago I wrote about the possibility to make activities private, that is, to encrypt the files that relate to it. And, I wrote it will be available in KDE SC 4.9

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.

There is one feature whose implementation got dragged out for quite a while now, and gets requested with each new release of the KDE Workspace – being able to tell an application always to be shown on all activities, or on a specific one.

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.