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:

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.