Ivan Čukić

Just a teaser

Activity Window Management

The future of activity switching

I have returned to the colourful world of UI (still refusing to say UX :) ) development.

The new pretty thing that is taking away my time is the activity switcher which got a rather big revamp for the next release of Plasma.

Activity Switching in Plasma After Next

Apart from the new UI, it got a few usability improvements, namely full keyboard navigation. You are able to filter, navigate and switch activities without touching your mouse.

Meta+Tab activity switching

Unfortunately, not all is great – the Meta+Tab shortcuts for switching activities are not going to be enabled for the first release, they will have to wait for the one after.

What will that look like?

As you can see in the screen-cast, the Meta+Tab will (unlike old Plasma) have a visual feedback – it will show the switcher until you release the Meta key. Similarly to how Alt+Tab for window switching works.

Per activity global shortcuts

The second thing that will need to wait is the port of the global shortcuts plugin by Makis Marimpis. I expect it to be present in the same release as Meta+Tab.

Linking stuff to activities, plus a junior job

Foreword

Since we lost the King Nepomuk at the battle on the now red desktop fields near the Semantic River, the common people lost the ability to tie things to their activities.

Nepomuk Battle

Stories and hymns of how King Nepomuk got to the throne by learning the sacred skill of tying things to one another with differently coloured strings and with labels attached to them, will remain in our heads and hearts for years to come.

The most famous and loved will always be the balad of the Active lands of Plasma where the society became so enlightened they managed to expel the Royal Society for Putting Things on top of other things.

What the future (KF5) brings?

Ok, stopping with the story now.

KActvities are back in the world of semantic linking, this time without Nepomuk, and without any unnecessary performance overhead. The new service implements all the features Nepomuk provided for activities, but also goes a bit further than that.

Everything is exposed to the developers via the ResourceModel available via the org.kde.kactivities QML import.

With the new system, we are finally able to implement one of the most requested features – to be able to define some Kickoff/Homerun/Lancelot/whatever favourites to be tied to a specific activity while leaving some to be global as they are now.

A small task for a volunteer

If someone is willing to port the Dolphin plugin and the Activities KIO to the new system (for KDE SC 4.13), please send me an e-mail.

Namely, the new activities service (although based on Qt5/KF5) can and should serve as a drop-in replacement in the future 4.x releases (if the distributions decide to ship it, I’m not going to force the issue).

In order to restore the missing features that depended on nepomuk, the two components from above need to be implemented to work with the new service.

My current focus is on KF5 and Plasma Next, and I’m not going to be able to implement those any time soon.

So, if you think you’re up to the task, and would like to be able again to link stuff to activities in 4.x, ping me.

#1 talk at Meeting C++

I have been honoured by the voters for the upcoming Meeting C++ conference. My submission got the most votes for the popular track without me whipping votes*.

I have to say that it will be awesome to have the opportunity (and challenge) to speak at the same location where the great Scott Meyers will be the keynote speaker.

If you are close to Berlin in December and love C++, I guess there is no better place to be.

(*) I’ve been waiting to use this phrase since I first saw the “House of Cards” :)

Using Clang’s static analyzer to analyze your project

There was a post recently about running a static code analysis tool on Qt 5 with some rather cute results. The main purpose of the post is to advertise the tool used, but it does make a nice point of how careless we can be when writing the code.

Since KDE is a Free/Open project, we don’t usually have the necessary finances in order to be able to use the tools like the one linked above. Fortunately, not all is grim. The great people at Clang, apart from making one of the best C++ compilers, provide us with a few tools as well.

I’ve written about clang-format some time ago. Now, it is the time for another, a bit younger project – Clang Analyzer.

What is it?

The Clang Static Analyzer is a source code analysis tool that finds bugs in C, C++, and Objective-C programs. The analyzer is 100% open source and is part of the Clang project. Like the rest of Clang, the analyzer is implemented as a C++ library that can be used by other tools and applications.
~ from the project’s website

It tries to analyze the different execution paths of your code and try to detect whether some of them can lead to problems.

As an example, I’ve used it on KActivities. And I got a false-positive, but a very reasonable false-positive. Namely, one variable was not initialized when declared, and as far as the analyzer is concerned, it might have been left uninitialized till its insertion into sqlite.

In reality, it was initialized in a range-for loop which is guaranteed to have at least one iteration, which the analyzer could not have known. It took me more than a minute to explain to myself that the variable can not be uninitialized, so I can not blame the the static analysis for the false alarm.

clang-analyzer

How to use it?

At the moment, it does not have a very sophisticated mechanism of execution. It follows the usual pattern of wrapping the compiler commands (similar to icecream, colorgcc etc.).

You need to set your build to use the wrapper instead of the actual compiler.

Lets say that you have installed Clang to /usr/local and copied the llvm/tools/clang/tools/ directory to /usr/local/share/clang/ (the analyzer is not installed by default, so you need to copy it manually).

You can create a separate build directory (in my case /opt/kf5/build-analyzer/path/to/your/project) and invoke cmake from there like this:

cmake /path/to/your/project's/sources \
    ...options you normally pass to cmake ... \
    -DCMAKE_CXX_COMPILER=/usr/local/share/clang/tools/scan-build/c++-analyzer

After cmake finishes its magic, run the analyzer:

/usr/local/share/clang/tools/scan-build/scan-build \
    --use-analyzer=/usr/local/bin/clang++ make

It will compile your project and analyze it at the same time. It will take much more time than an ordinary compilation run, but that is to be expected because of all the additional work it does.

To see the results, you need to run the scan-view command which will start a small web-server and point your web browser to it. You’ll be able to browse the detected issues from there. It nicely displays the sequence points that lead to the detected problem.

Which one is clearer – the resolution

If you haven’t seen the previous post, I’ve posted a question of what style would you prefer (I’ve simplified it a bit here, for the original, go for the link above):

(A)                        | (B)
                           |
if (ratio < 1.5) {         | result = (ratio < 1.5) ? 1.0 :
    result = 1.0;          |          (ratio < 2.0) ? 1.5 :
} else if (ratio < 2.0) {  |          (ratio < 3.0) ? 3.0 :
    result = 1.5;          |          /* otherwise */ ratio;
} else if (ratio < 2.5) {  |
    result = 2.0;          |
} else if (ratio < 3.0) {  |
    result = 3.0;          |
} else {                   |
    result = ratio;        |
}

As expected, people are split into two similarly sized groups. It is a matter of style after all.

Neither of these is better, but they both have their pros and cons. Lets see what we have collected so far.

Firstly, lets deal with the elephants in the room:

- Is this an academic question? (as suggested by krake)

Yes and no. Yes, because it is not really that important – people will continue using what they used before. No, because it might influence the different aspects of the resulting code. (see below)

- You can use if-return format: (suggested by cyber_fusion)

if (...) return ...;
if (...) return ...;
...

This seems to be a popular variant of (A) when the purpose of the result variable is to be returned from the function we’re in (as it was the case in the original post). It does not work in other cases.

While it is a good approach (and preferred by a significant number of people), there was one statement for it, that is not correct – (Alex) “it shows structure, it will not execute if statements after a successful one”. All the proposals behave the same – neither executes statements after the first successful one.

The issue some people pointed out is the lack of braces for the if body which is frowned upon by a significant number of coding styles used across the world. If somebody questions why would missing braces would ever be a problem, just search for the ‘apple goto fail’. When you add braces, the solution stops being as visually attractive.

Now, we can start with the reasons people wrote for one or the other. In no particular order, to avoid the trap of actually counting pros and cons.

(shamaz) The big difference here is that the 2nd solution is ONE statement. This means that it’s less simple to debug : you won’t see which branch is chosen (similar comment by Morten)

It is a single statement, but it has multiple sequence points[↗] (or whatever they are called in the new standard). The same sequence points an if/else construct does. So it will show up (tested in gcc+gdb1) as separate steps while debugging2. You will be able to see where you left the statement.

Edit: 1 clang does not create the same debugging info, so it does treat it as one execution step.

2 It has a big uglier debugging output, but still is quite usable.

(Lihnell) I’d like to add that putting the else in a comment for readability is a clear indicator that the language used is not suitable to the person using it

I do agree. It essentially boils down to the fact that ?: syntax (for this) is not something people are used to. So adding ‘else’ or ‘otherwise’ is a nice way to make it more readable.

(konqoro) I guess it was how we were told to better understand the if-else statements.

There were a few similar comments to this one.

Yes, if-else approach is ubiquitous, and therefore understandable by everyone. IMO, it is the strongest reason for going for it – people are not used to (B) even if (Jeff) “the notation fades into the background, and the structure of the actual operation pops out”.

(dhardy) I find the second much easier to read. My preferences are (a) avoid re-assigning variables

Thanks to some pure functional languages like haskell, the concept of immutability started to spread out to other paradigms. The second approach is also usable in C++11 constexpr functions, while the first one will be allowed in C++14.

One of the approaches to make the result variable const for the (A) variant would be to use lambda-initialization, thus localising the mutable variable inside the lambda. Like:

const double result = [] { ... }();

(Alex Elsayed) I doubt you care overmuch, but PHP will not do what you expect on the second one

You are right that I do not. But, this is a useful information for the future – if I get to hack on some PHP code. Thanks!

(shamaz) For the 2nd solution, if someone try to format your code automatically with his IDE, it may become hard to read.

Yes, unfortunately. I’ve tested it with clang-format and it essentially killed it. I guess if it became a common idiom, formatters would learn to deal with it. :)

Epilogue:

Personally, I prefer the second option although I don’t use it that often mainly because it is not that common and people are not used to it.

I do prefer it on the technical grounds, though. It is perfect for const initialization / constexpr functions, the syntax stops you making code-evolution mistakes similar to the ‘goto fail’, and different mistakes that the original code (which inspired me to write this) had. (the original code was posted for half an hour in the previous post, but I decided to edit it to show only the styling differences, without other issues)

Which one is clearer?

This is a excerpt from a real project, just with variables renamed.

EDIT: * I’ve removed the issues from the original code so that this can be a real style vote, without sidetracking the readers.

Although, by fixing the code, I removed one of the things that I think the advantage of the second one is – it is much harder to make errors and dead code.

const qreal ratio = someFunction();

if (ratio < 1.5) {
    result = multiplier;
} else if (ratio < 2.0) {
    result = multiplier * 1.5;
} else if (ratio < 2.5) {
    result = multiplier * 2.0;
} else if (ratio < 3.0) {
    result = multiplier * 3.0;
} else {
    result = multiplier * ratio;
}

return result;

This was the usual imperative code that you’d find almost everywhere. And this is the alternative (functional) way of doing the same:

const qreal ratio = someFunction();

return multiplier * ( 
    (ratio < 1.5) ? 1.0 :
    (ratio < 2.0) ? 1.5 :
    (ratio < 2.5) ? 2.0 :
    (ratio < 3.0) ? 3.0 :
    /* else */      ratio
);

The second one is kinda what you’d do in maths:

       /  1.0     x < 1.5
       |  1.5     1.5 ≤ x < 2.0
f(x) = <  2.0     2.0 ≤ x < 2.5
       |  3.0     2.5 ≤ x < 3.0
       \  x       otherwise

What do you find more readable?

Activities API for QML

I had an unfortunate intermission in kactivities development due to a hard drive failure.

Fortunately, I managed to salvage significant parts of my work, but without git history. Now, it is ready for prime-time.

You are now able to access the activity manager without the need for the ‘clumsy’ activities data-engine. Just import org.kde.activities and create an instance of the ActivityModel.

  import org.kde.activities 0.1 as Activities

  ListView {
      id: main

      model: modelMain

      Activities.ActivityModel {
          id: modelMain
      }
  }

But, this is not all. You are not limited only to retrieve the data, it is also possible to create, delete or alter them. The service control API is asynchronous. Therefore, all methods, apart from regular arguments, receive a continuation function that is called when the method is executed.

Something along these lines:

  modelMain.setCurrentActivity(idOfTheActivity,
    function(result) {
      console.log("Activity switched")
    }
  )

  modelMain.createActivity(nameForTheActivity,
    function(result) {
      console.log("Activity id is: " + result)
    }
  )

Well, that is all for now. I’m thinking of adding overloads without callbacks, but these methods are not really meant to be called by everybody, so I’m not sure how important a more pleasant API actually is. :)

SQL results in range-for

I’ve been irritated for the way a QSqlQuery result-set is supposed to be processed for some time now – with while(query.next()) and getting the results via query.value(...). I was always thinking it would be nice if it were more accessible… namely, accessible using iterators.

To be able to do something like this:

  for (auto &record: query) {
      // do something with
      record[0]
      // or
      record["ID"]
  }

You have a simple .h file to include, and it will just work. [1]

The issue is that it is only tailored to match only this use-case – it can be improved to do more, and to allow more iterators over the same query, but I don’t really care to do that :)

[1] https://gist.github.com/ivan-cukic/7346513

Activity switching questionnaire

I have a few questions that I’d like to hear an answer to from a wider user (and developer) community. Those revolve around the activity switching UI and the things it could have in plasma 2.

Currently, the switcher shows the name and the icon of an activity, and allows you to:

  • switch activities (duh)
  • create / delete activities
  • start / stop activities
  • change the name and icon

This is rather rudimentary. We have more information for the activities that somebody could find useful. We know:

  • which windows are currently open in an activity
  • which documents are open in an activity (for applications that support that kind of thing)
  • which documents have been opened in an activity in the past, along with which were most popular (kept open the longest, accessed multiple times etc.)
  • what is the wallpaper in the current activity, for running activities maybe even the screenshots of the windows

These are some of the things we could have:

  • marking activity as private in the sense of the private mode web browsing which would stop the usage tracking, etc. (not to be confused with encrypted activities we planned for Plasma Active which proved to be infeasible)
  • instead of creating blank or templated activities, we could optionally create activities containing the work from the last hour or so. This would move the windows and documents you are currently working on to the new activity (and move all the related recent usage statistics along with them)
  • some kind of search (for what?)

All comments on above, ideas for new things and even mock-ups are welcome!