There is something that a few people here and there have been requesting - having some automatic (UI) way to create encrypted folders to keep their sensitive data in.
The thing I’m going to talk about today is exactly that - starting with KDE SC 4.9 you’ll be able to decide to encrypt specific activities. When you do that, you’ll get a ~/Activities/Something folder that is password protected and encrypted using fuse/encfs.
The encryption/decription process will be done automatically on activity switching.
For example, lets say you have two activities - Leisure and MI5 - with the latter being an encrypted activity. When you switch to the MI5 activity, you’ll be asked for its password and you’ll be able to access the data. When you switch back to the Leisure activity, the system for the previous one will be automatically unmounted.
Plasma Active Three
One of the reasons behind this new feature is PA3. You’ll have a portable device that can be stolen, that could be used by your children (while being single-user) for fun etc. and you don’t want some data to be visible to them.
In the case of PA, since there is no file manager and we don’t want to expose the file-system to the user, every document that you link to the activity will be automatically moved to the encrypted folder.
Drawbacks
There are a couple features that will stop working with encrypted activities - you will not be able to search encrypted documents by contents since the contents will not be indexed by nepomuk, and documents will not be able to belong to multiple activities if one of them is encrypted.
Published
in the KDE development section,
on 26 December 2011
Edit: Cool, thanks for the input! I get the gist what is the common format. There are some unpredictable ones, but I think we could come up with some not-useless heuristic to deduce whether two wifis are at the same institution.
Hi all, I need the following information from out awesome users - what are the names of the wifi networks you are using when you are at some institution or something. I don’t need the exact names, just the format.
So, for example, at my faculty. we have names that follow this pattern: faculty_name-classroom_number (eg. Abcd-122). At the math institute, it is something and something2.
I have realized I haven’t had a Lancelot-tagged post in a really long time. This just has to change.
After the release of Plasma Active 2, I decided to take a few days off, and do something else. After Martin’s port of Kickoff to QML, I got the idea that I could finally start porting Lancelot to QML. I have entertained this idea in the past, but I was unsure about how backwards compatible QML2 will be and whether I’ll have to rewrite large parts of Lancelot for the fifth time due to changes in Qt.
With all those doubts still present, I decided to bite the bullet.
I’ll try to keep things on the /safe side/ by keeping the Lancelot-specific hacks to a minimum. This means I’ll try to use Plasma Components and standard Qt Quick as much as possible instead of writing my own like before (at the time, there were no pre-made UI components for QGraphicsView).
Data models
The first to port were the data models - instead of a custom ActionListModel class, I’m now using the standard QAbstractListModel, and all the models are exported as QML components in the namespace of org.kde.lancelot.components.data.
This means that any KDE/QML application, plasma applet or something else, will be able to use these models by doing a simple import.
Shelf
After the models were converted, it was the time to test them, and what better way than to re-implement the Shelf applet. As you can see in the screenshot, even the KRunner-based search works.
Regressions
There will be regressions in this process. Some intentional (aka permanent feature removals), some not. At first, there will be no click-free activation, no drag-and-drop, no …
I don’t plan on releasing Lancelot 2 until most of the current features are reimplemented, but this is not the case for the Shelf. It will go into KDE Plasma 4.9 regardless of state it will be in. It is almost usable now, more than a half a year before 4.9 is released to the wild.
Lancelot 1.x
There will be no major changes in the current branch of Lancelot, unless someone steps up to do the work. I’ll try to find the time to fix openSuse-specific (I don’t use oS, so can’t reproduce) crashes that have been flooding bugs.kde.org recently, but that might be after 4.8 is released.
Published
in the KDE development section,
on 2 November 2011
Not for the weak-hearted
My blog has been rather empty lately. It’s not because I haven’t had anything to report, but due to the fact that many things have happened and all sorts of cool things in Plasma Active’s “Activity world” started appearing that I didn’t have the time to write about them.
Today, I’m going to write about one of the smallest things I’ve done lately that will change the world :)
startkde
startkde script had served us quite well for a long time now, and it is still the best way to start your Plasma session. But it has some downsides that we needed fixed in Plasma Active, and some features that Plasma Active doesn’t need.
So, this post is about an alternative approach to start Plasma, a new application called startactive. It is NOT a replacement of startkde, but an alternative. Meaning that it doesn’t do all the things startkde does, while it does some work that startkde doesn’t.
The design
The main goal of startactive’s design was to create a dependency-based system that starts various workspace components.
You can see the dependencies of various systems that startactive invokes in the following graph.
The blue items are meta-modules - they don’t start anything but they make it possible to keep the organization manageable.
Waiting and starting
The system starts all the free modules (modules that don’t depend on anything) at the same time (makes a nice performance boost on both single and multi-core systems), and then waits for some of them to finish until a new module becomes free. When it does, it is automatically started.
There are two ways to see when a dependency has finished its job - 1st - the usual - wait for the process to finish; and 2nd - wait for the program to register its D-Bus service. (org.kde.nepomuk.services.nepomukqueryservice for Nepomuk, org.kde.plasma-desktop for regular Plasma etc.).
Splash screen
Now, when you’re making something that doesn’t need to provide any compatibility with existing systems, you have the freedom to do the things as you see fit. So, I felt free to abandon the old splash screen engines that KDE Workspace used, but to focus only on the QML one I blogged about some time ago. It is now run in-process avoiding dirty ways of communication via X-events and such.
The missing features
startkde does a lot of things, from the initialization of the user’s .kde directory, to fonts, mouse cursors etc.
startactive doesn’t for one simple reason - all of that should be already set up on your Plasma device. All environment variables, Qt plugin locations, directory infrastructure…
Don’t try it
The code is currently located in kde:scratch/ivan/startactive and you shouldn’t use it. Unless you are a really brave soul who doesn’t care if startactive jumps out of the system and start killing kittens in your neighbourhood.
For me, it killed only two older felines, and now it has returned and manages my system with only a few smaller issues. So, if you are brave enough, then continue reading.
To test, you’ll first need to compile it and install with the same prefix as the rest of your kde system, which in turn needs to be in your PATH. Otherwise it will not work.
Then, you’ll need to adapt the module files to fit your setup and finally start the application in an empty X session.
An ordinary startactive will do - it will, by default, start the plasma active module, but if you want to run a desktop session, and change the splash screen theme, you can do something like this: