I’ve always had more than a few activities lying around
mainly one for each project I’m working on.
Be it KDE, Work, Studies, etc.
But I was basing my workflow not only on them, but also on virtual desktops.
I had four of them,
the first one to keep the web browser and the mail client in,
two for actual work (that is related to the current activity),
and the last one to keep the music player in.
I have noticed that this setup does not really force me to switch
activities that often,
which, in turn,
did not expose all the ‘papercuts’ in the UI.
I’ve decided to change my workflow a bit.
The first step was to create quite a few Firefox (Iceweasel) profiles.
One for each activity,
and a couple of different ones for the ‘Web’ activity
(I like to separate social sites like gmail, facebook, etc.
from other sites that I visit).
Now I needed to make each profile stick to its related activity.
Unfortunately, all Firefox profiles have the same window properties,
so KWin rules were not going to work for them.
there is a nice extension called ‘Nightly Tester Tools’ which
allows setting a custom window title for Firefox.
So, instead of it showing the application name,
I set it up to show the name of the current profile.
This allowed creating KWin rules based also on the window title
(match on regular expression 'ProfileName: .*'),
and not only the type.
With this setup, if I want to access my mail,
I have to be in the ‘Web’ activity,
and if I wanted to reach bugs.kde.org,
I need to switch to ‘KDE Development’ activity.
I’ve also written a small script that
starts a different Firefox profile, depending on activity
(I know somebody already created something like this
quite a while ago, but I was not able to find it).
While the activity switcher was always mouse-friendly,
in the days of Plasma 4.x it was not as pleasant to use for heavy keyboard users.
Maybe that is the reason why I thought
that activities are not meant to be switched often,
and why I had special virtual desktops for the things that often
interrupt my work (messaging and music).
The current activity switcher is a rather different beast.
I have only one activity tied to a keyboard shortcut (the ‘Web’ activity),
and I’m switching to all of the others by opening
the activity switcher (Meta+Q) typing a few letters from the name
of the activity I want to switch to,
and pressing enter.
I have to say it is a really fast workflow.
The only thing that I think might improve it
is a keyboard shortcut for switching back to the
since I’m often switching to the Web activity,
and back to the project I was working on,
it could be a nice time-saver.
I don’t intend to make this shortcut
enabled by default,
but it could be a nice option for people
who have a similar workflow as I currently do.
I have also seen that for my workflow,
the Meta+Tab switching of activities
is useless and much slower than the above
The main issue I have now is that I sometimes forget
whether I have something open in an activity or not.
This is something that I was always planning on
creating, but never found the time.
What are your papercuts when working with activities?
I’ve just upgraded this blog to Jekyll 3.
There were quite a few hurdles along the way, but all should be ok now.
I’ve found three different types of transition issues
(it is cool to look at these in a project I do not upgrade on a daily basis
like Plasma and the rest of the KDE software).
Type 1: Issues that break the build
API for plugins has changed. This means that plugins I wrote
for this blog stopped working (some of them).
This was the most painful one to fix,
since I had to investigate the changes in the plugin system
in a programming language that I really do not like
(Jekyll is written in ruby).
Type 2: Sneaky behaviour changes
The second type of issues
were small changes in behaviour like,
changing how the permalinks are generated,
changing a few things that were lowercase-only to uppercase
These issues were more annoying than the type 1.
With type 1, you know where you are at -
your build is broken, and you need to fix it.
The type 2 you can discover only
by actually checking whether the pages are generated properly or not
(in the end, I diffed the whole generated site to see what were the changes).
Type 3: Ruby GSL
The third issue was not really because of Jekyll upgrade,
but it did appear at the same time.
Ruby GSL library relies on an ancient version of
GNU Scientific Library which even Debian does not use anymore (Debian testing).
And while building the site with jekyll,
you get absolutely no information that your setup is broken.
The build does not crash because of a missing library,
because of incompatible library symbols,
it just keeps building.
And keeps building.
At some point you realize that even ruby is not that slow
and that something is wrong…
While it is nice to get speed improvements and all,
we should pay attention not to break things.
In Plasma, we do create breakages in major releases
because sometimes transitioning
the configuration to the new architecture is hard, or impossible.
I just hope we will not have a good reason to do it again anytime soon. :)
Today, I did the most evil hack I’ve done so far in a real project.
It is not something I plan to keep in the code,
but it is cool enough to be shared.
Do not use something like this. Ever.
I’ve found out that QFuture can contain an exception
in the case something in the asynchronous process failed.
This is nice, because it (even if Qt generally does not like exceptions)
provides a nice error reporting mechanism for asynchronous tasks
The problem is that in order to access the exception,
you need to invoke some of the blocking methods
like result() or waitForFinished().
And I hate methods that block.
Before I propose a patch for QFuture to allow
testing for an exception,
I had to find a way to access this data
without it really being supported.
The exception store is located in a private (pimpled) class in the QFuture.
So, how to access something that is private from the outside?
One possibility is #define private public but that is just overly
crude for my taste.
The second, and much more interesting one comes after realizing that
QFuture is a templated class,
and a templated class is not really closed.
The access restrictions do not apply to different instantiations of
a templated class, so if we can create an instantiation of a method
in QFuture for some class that does not really exist,
and is not used anywhere else in the world,
and we will be able to access its privates.
And, from now on, this instantiation of the method can be used to check
whether a specific future contains an exception.
Everyone talks about the power of templates,
and the possibility to calculate stuff at compile-time.
But they are much more powerful than that. :)
p.s. Yes, it would have been much easier to just roll my own qfuture.h
The idea of having a container for a value that is not yet
present, but will be available sometime in the future
is a powerful one.
it decouples the asynchronous process invocation
from the result handler.
This allows creating nicer asynchronous APIs than the usual approaches.
The Qt library provides a container like this – the QFuture<T>.
And, at the same time, it provides incompatible special-cases containers like
QDBusReply<T> and other Q*Reply classes.
QFuture was meant to be used only in the QtConcurrent library,
and was designed to suit that need –
to wrap operations executed concurrently on multiple threads.
It was moved to QtCore in 5.x,
but apart from the rellocation,
it did not receive much love,
and its design stayed the same.
Issues with waiting
In order to do something with the result,
you need to wait for the future to arrive.
It you do not want to block your main thread,
you need to wait for the future like this:
This makes using QFuture a pain.
I’ve been creating wrappers for this
on multiple occasions,
and realised that I do it often enough
to warrant creating a new library.
Issues with creation
Another issue with QFuture is that Qt does not really use it.
The previously mentioned classes like QDBusReply are a perfect example.
Imagine you are writing an interface library for some
You can make it blocking
which is very bad since the service might take a long time to respond.
You can make it asynchronous by returning QDBusReply
which exposes the implementation detail via the API.
Also a very bad approach.
Or, you can split it into a request slot and a response signal
which is plain ugly to write and use.
If the QFuture<QString> is used instead,
you get exactly what you need
it is asynchronous,
it hides all the implementation details
(the user does not know whether it uses DBus,
executes an external process and returns its output, etc.)
and it is not ugly.
The problem is that Qt does not provide
a way to allow you to convert these different future-like constructs
This is the second reason behind the creation of the AsynQt framework.
What is AsynQt?
The aims of the framework are:
To provide wrappers for common Qt future-like classes
To add methods for easier manipulation of QFutures
I’ve implemented wrappers for the DBus and QProcess.
You can convert the QDBusReply<T> to a QFuture<T> simply by
using the makeFuture template function,
or you can invoke a DBus method and get the QFuture
as the result immediately:
QProcess wrapper is a bit trickier because it has one special feature.
Apart from the process, it receives a function that
allows you to extract the information you want to return from the process,
instead of returning the QFuture<QProcess*>.
Examples are worth more than words:
There are also a few convenience methods for creating simpler futures
makeReadyFuture that creates a future which already contains a value,
makeCanceledFuture that creates a canceled future and
makeDelayedFuture which creates a future that will contain
the specified value after the specified duration of time.
And more will come.
Now, all of the above would not be that useful
if we still had to use the usual QFuture API.
For this reason,
a few new methods are provided –
transform, flatten, cast, continueWith.
I’ll leave the explanation of these for later
(when I add a couple more different ones
that I consider necessary).
At this time, just a few examples:
Pipe or range syntax
The library also supports the pipe syntax.
Instead of calling a transformation on a future directly,
you can also send the future through a pipe to the transformation.
There were some complaints from our Windows people
that it is difficult to build KActivities (on Windows)
due to its usage of boost.
This is just a public service announcement that the library part
is no longer using boost (it was using only boost::optional)
so that this is not a problem anymore if you
build with -DKACTIVITIES_LIBRARY_ONLY flag.
Non-library parts that are meant for not to be used
on Windows will still depend on boost,
and on proper C++ compilers.
P.S. I’ve created a optional_view class. Might be a thing
worth developing further, since we are getting array_view,