Just a short update on the CryFS situation I mentioned a few days ago.

I was contacted by Sebastian (the maintainer of CryFS) and he said he has been actively working on the solution to the upgrading problem.

He has already implemented quite a few things that will be useful for Plasma Vault, and I will make the CryFS backend default again in Plasma 5.13 (after the LTS release) if these updates get released and packaged by the most popular distributions.

The main changes so far include automatic filesystem upgrades and error reporting through error codes. This will allow Plasma Vault to know exactly why opening a vault has failed to be able to properly communicate it through the UI.

It is awesome how the free/libre open source community sometimes works. :)

CryFS is considered beta software by its developers.

While that is completely fine, it is a bit of a problem for the LTS release of Plasma Vault.

The most recent problem that I was made aware of is that CryFS breaks its filesystem layout in new releases. While this is not a problem when using cryfs from the command line, it is a problem for UIs that use it like Plasma Vault, SiriKali and others.

Namely, the tool asks whether to upgrade the filesystem when you invoke it even when running in non-interactive mode. This means that Vault will fail to open if the filesystem needs to be updated.

Not all is lost though, if you encounter the issue of not being able to open a vault after upgrading CryFS, you just need to mount it manually once, and after that everything will work like before.

Open the .config/plasmavaultrc file, and find the Vault that you have the problem with. The configuration group header is the device - the location where the encrypted files are stored, and the mountPoint entry is the location where the decrypted files are shown when the vault is open.

Now just open Konsole and do the following:

    cryfs device mountPoint
    ... Answer all the questions you are asked
    fusermount -u mountPoint

This should be enough.

I’ve tested different options to do this automatically, but CryFS does not provide a safe way for it, and a bug report related to this issue has been ignored for half a year now.

For this reason, EncFS will be the default encryption system in Plasma 5.12. After that, I’ll start working on supporting gocryptfs which will hopefully be a fitting replacement come the next LTS release.

I’ve got a chance to share a part of my upcoming book here.

The book is in production, I’m expecting it to come out in February.

There will be a discount on December 24th and 25th: Half off everything at Manning. You can use codes dotd122417 and dotd122517 – just go to Manning webpage.

The biggest problem in software development is handling complexity. Software systems tend to grow significantly over time and they quickly outgrow the original designs. When it turns out that the features that need to be implemented collide with the design, we must either re-implement significant portions of the system or introduce horrible quick-and-dirty hacks to make things work.

See the whole excerpt in this PDF

After David’s post, I got a few mails asking whether this change has anything to do with the project I started last summer, so I decided to provide a small update.

My original plan was to ship a test version of Blade a few months after the project announcement, but that did not happen. The main reason was that there were some higher-priority things in Plasma I needed to work on, so I had to put this on hold a bit.

While the project is not yet made public, some important things have happened that moved it forward quite a bit.

First, a teaser

Before I start, a fancy screenshot is in order. The main UI is as dull as it was, but there is another UI:

If you are not sure what this is, this is not a fancy new Plasma theme. This is a screenshot from a phone (more precisely, a phone version of Sailfish OS in a virtual machine) connected and set to search applications on my main system.

The design

I have significantly simplified the design because the original one induced some communication overhead to allow any two nodes in the system to communicate with each other (regardless whether they are on the same system or not).

This was a cool feature, but I’ve realized that it is not needed here, and that it is not needed in most programs that I’d use a similar message-passing mechanism in.

The messages now have a strict flow and each node can send messages only to its designated listener(s).

The beast below

I’ve also replaced the serialization mechanism which used the Qt data stream proocol with the ProtoBuf library, and the Qt networking has been replaced by ZeroMQ (yes, I’ve changed my mind).

One great thing about these libraries (and one of the reasons I decided to replace the old stack with them) is that they have fully-functional bindings for any programming language imaginable – from Python and Java, to languages like Haskell, Erlang and Elixir.

This means that it will be possible to write any of the components in any language you want. If you want to use Python’s great numeric libraries to implement the calculator runner, or if you want to implement a Web UI in Haskell, you will be able to. No need to be limited only to languages that support Qt.

The future

I don’t have any plans to propose replacing KRunner’s current implementation with this anytime soon. As David mentioned in his post, this would be problematic because this is a reimplementation with a completely different API and everything.

The first milestone will be to create an alternative to KRunner that will have enough cool features for people to start using it instead of KRunner.

This is the same approach I took a long time ago with Lancelot. Be a conscious choice instead of being the default.

Once upon a time, for those who remember the old days of Plasma and Lancelot, there was an experimental applet called Shelf.

The idea behind the Shelf was that sometimes it is useful to have a small applet that just shows your recent files, favourite applications, devices, which you can place on your panel or desktop for quick access.

Now, this post is not about a revival of Lancelot and Shelf (sadly), but it is closely related to them.

Namely, I always disliked the “recent documents” section that is available in almost all launchers in Plasma. The reason is that only one in ten of those documents has a chance to ever be opened again.

The first code that had the aim to fix this landed in Lancelot a long time ago – Lancelot was tracking how you use it so that it could eventually start predicting your behaviour.

This idea was recognized as a good one, and we decided that Plasma as a whole could benefit from this.

This is how the activities manager (KAMD) was born. The aim was to allow the user to separate the workspace based on the project she was working on; and to have the activity manager track which applications, documents etc. the user uses in each of the activities.

The first part – having different widget sets for different activities was baked in Plasma 4 from the start. The second one (which I consider to be much more important) came much later in the form of KAMD.

KAMD, apart from being tasked to manage activities and switch from one to another, also tracks which files you access, which applications you use so that the menus like Kicker and Kickoff can show recent documents and recent applications. And have those recent documents and applications tied to the activity you are currently in.

For example, if you have two activities – one for KDE development, and another for working on your photo collection, Digikam will be shown in the recent applications section of Kicker only for the second activity, since you haven’t used Digikam for KDE development.

Now, this is still only showing the “recent documents”. It does show a list of documents and applications that are relevant to the task you are currently working on, but still, it can be improved.

Since we know how often you open a document or start an application, we do not need to focus only on the last time you did so. We can detect which applications and documents you use often and show them instead. Both Kicker and Kickoff allow you to replace the “recently used” with “often used” in the current version of Plasma.

Documents shelf

Now back to the topic of this post.

While working on the KAMD service, I often need to perform tests whether it keeps enough data for it to be able to deduce which are the important applications and documents, and whether the deduction logic performs well.

Most of these tests are small GUI applications that show me the data in a convenient way.

For one of these, I realized it is not only useful for testing and debugging, but that it might be useful for the day-to-day work.

In the screenshot above, you can see an applet, that looks quite similar to Shelf from Plasma 4 days which shows the files I use most often in the dummy “test” activity.

One thing that Shelf did not have, and neither Kicker nor Kickoff have it now is that this applet allows you to pin the documents that are really important to you so that they never disappear from the list because the service thinks some other file is more important.

You can think of it as a combination of “often used” and “favourite” documents. It shows your favourite documents – the documents you pinned, and then adds the items that it considers worthy enough to be alongside them.

This applet is not going to be released with the next Plasma, it needs to evolve a bit more before that happens. But all the backend stuff it uses is released and available now if you want to use it in your project.

The keywords are kde:kactivities, kde:kactivities-stats and kde:kactivitymanagerd.