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.
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
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.
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
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.
A long time ago in a galaxy far
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.
After the KDE SC 4.9 is released, projects inside KDE Projects:
start requiring more up-to-date compilers and will start (ab)using more modern
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