I was hoping to announce this at Meeting C++, but the guys at Manning were a bit faster than I expected. :)

For those of you who know me, you have probably noticed that I talk a lot about functional programming at C++ conferences like Meeting C++, Qt Con, Qt Dev Days and such. The good people at Manning noticed that as well and offered me to write a book on Functional Programming in C++.

I’ve been keeping this under the wraps for some time now, but the book is now officially announced and the first two chapters are made available through the Manning Early Access Program (MEAP). There will be a new chapter coming out each month.

For the following two days (starting November 7th, 00:00 US ET), it will be the Deal of the Day. You can use the code dotd110716au on the Deal of the Day page.

You can see more information about the topics planned to be covered in the book at the book homepage: Functional Programming in C++

There will also be a discount on “Grokking Functional Programming” (a quite interesting FP book from what I’ve seen) and “Functional Programming in C#”.

As you might have seen, we are coming close to the most awesome Free/Libre Software conference – Akademy – the one and only place where you can meet a few hundred KDE contributors. It will be held in Berlin as a part and continuation of QtCon.

I’m going to give a talk there about all things that are wrong with the QFuture, and the things that might be fixed in the future (pun intended).

In general, futures are a great concept that allow developers to easily implement asynchronous and concurrent systems. But, why isn’t it the case with QFuture? I’ll try to cover a few things like what is wrong with the idea behind QFuture, what is wrong with its API, should we go for std::future (or boost::future instead and similar.

See you there!

p.s. If you are going to Akademy, you are free to use the above banner in your blogs and such. It is not the official VDG banner (we don’t have the official one yet as far as I know), but Jens likes it so it is almost as if it was the official one. :)

It comes in two different sizes, the regular and the slim one.

Berlin is still the city to be in if you are interested in C++ and/or Qt. At least, if you are in Europe and don’t like the idea of flying across the ocean to go to CppCon.

The first conference will be in September, and it will join the KDE, Qt, VideoLAN and FSFE communities. It is a continuation of the Qt Dev Days and Qt World Summit for Europe, and it is called QtCon.

The second conference is becoming a true tradition, even for me, and it stays true to its original name – Meeting C++. It will be in November this time, which is a pitty since Berlin in December is filled with beautiful christmas markets which provided all the Meeting C++ participants great time last few years.

Just a screen-shot this time.

The setup goes as follows:

• GUI (in the screenshot) runs on my main computer
• The runner that searches for applications with few less important ones is in a separate process on the same system
• Baloo runner is on another computer (since I have Baloo running only on that system)
• And the Recoll runner runs on yet another separate system

The result is in the screenshot:

I have a lot of issues to tackle, and to make it all usable by normal people, but I had to share this milestone since it is quite cool. :)

p.s. Mind that the Recoll runner is even able to return the section of the file where the search item appears

p.p.s. Don’t mind the ugly UI, it is just for the testing purposes.

It is strange to talk about improvements when the product does not yet exist, but there are a few important ideas that deviate from original KRunner that I’ve been working on.

I’ve already ported a few of the more important runners in order to be able to test the infrastucture. While doing this, I’ve been able to detect a few deficiencies of the current design. So I decided to go over the design of KRunner and the way it used to generate the results in order to which parts could be improved.

Reusing the results

In the old KRunner, the user would type a query, and the runners would generate the results for that query. Now, if you added another character to the query, the runners would generate all the results for that new query from scratch.

This is suboptimal. When the user types ‘kons’ and gets Konsole as the result, typing ‘o’ should not remove konsole from the list only to add it again because it still matches the input string ‘konso’.

Now each runner can add the whole string it used for matching to the result. So, in the case of Konsole, it could pass something like ‘Konsole - Terminal’. This way, the GUI part of KRunner will be able to tell that this result is still relevant and that it should keep it in the list. Runner that searches for files might even pass a section of the text where the query appears (this might even be useful to show in the UI - like Recoll does).

Merging the results

The second thing that I always found strange is that if two different runners returned the same result, KRunner will show the result twice. Just enter ‘konsole’, and you will get ‘Konsole’ and ‘Run konsole’.

Now, if two runners return the same thing, the results will be combined, and the result will get a higher score. Since the score (or relevance) is a number between 0 and 1, these are combined in a fun math way used in fuzzy logic.

Result owner

The other problem in KRunner is that each runner is tasked to handle the results it has created. This means that you might get different available actions for the same file if it was returned by two different runners.

So, the second change was to rethink what is a result in KRunner.

Instead of each runner owning its result, it will now, by default, only need to explain what the result is. That way, if it is a file, the GUI will know what actions to provide, if it is an application, the GUI will know what actions to provide, etc. If it is something unorthodox, then, and only then, the runner should be asked how to execute it.

When?

It is difficult to predict, but I hope I’ll be able to make a preview version (called ‘Blade’) by the end of July. The current plan is to release it as a separate application – for testing purposes only, and after that I’ll have to go one KRunner feature at a time to make sure it has no obvious regressions.

The worst part is that, thanks to Kai Uwe, KRunner is now a moving target and I’ll have to play catch-up with all the features he adds to main KRunner. :)