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:

import os, sys, Xlib
from Xlib import X, display, Xatom

# Doing dirty things to stop Xlib from
# writing to stdout
# Xlib.display.Display()
#     Xlib.protocol.request.QueryExtension
old_stdout = sys.stdout
sys.stdout = open("/dev/null", "w")
display    = Xlib.display.Display()
screen     = display.screen()
sys.stdout.close()
sys.stdout = old_stdout

def _processWindow(win, atom, processId, level = 0):
    result = set()

    response = win.get_full_property(atom, Xatom.CARDINAL);

    found = False

    # Testing whether the response was valid
    # and whether we found a proper process id
    if response != None:
        for pid in response.value:
            if pid == processId:
                result.add(win.id)
                found = True

    # If we have found the window, we don't
    # search its children
    if not found:
        for child in win.query_tree().children:
            result |= _processWindow(child, atom, processId, level + 1)

    return result

# Gets the window IDs that belong to the specified process
def getWindowIds(processId):

    root = screen.root;
    tree = root.query_tree();
    wins = tree.children;
    atom = display.intern_atom("_NET_WM_PID", 1);

    # recursively searches the window tree
    # for the one that has a desired pid
    result = set()

    for win in wins:
        result |= _processWindow(win, atom, processId)

    return result

# Gets the window IDs that belong to the current process
def getWindowIdsForCurrentProcess():
    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.