Archive for the ‘Active’ Category

Next means Focus on the Core

Friday, February 21st, 2014

The metaphor of a home make-over crossed my mind today, and I think it implies a few ideas that connect to Plasma Next quite well.
Plasma Next
Plasma Next is a new iteration of the Plasma workspaces. This is the first time, that KDE’s workspace is released independently from its underlying libraries and the applications accompanying it. It is built upon KDE Frameworks 5 and Qt5. “Plasma Next” is our name for the development version of Plasma, the final product will not be called “Next”. The planned release does not include the applications that are shipped today as part of the KDE Software Compilation. Applications, just like the Frameworks follow a different release schedule. Of course it’s entirely possible to run KDE SC 4 Applications on a Plasma Next desktop, and vice versa.

We have now settled on a release schedule for Plasma Next, which plans for the first stable release in June. It’s a good time to talk about what’s to expect in this first release. I think we’ve got some pretty exciting improved technology in the works. As our new baby shapes up, let’s take a look at what’s old and what’s new in more detail.

Frameworks 5

Plasma Next bases on KDE Frameworks 5, which is a modularized version of the venerable KDE development platform, kdelibs and friends, so to say. This results in a reduced footprint in terms of dependencies. The Plasma libraries and runtime components are one of those Frameworks itself, providing the tools to build applications and workspaces. Plasma has been one of the early adopters of Frameworks 5, mainly for the reason that we had to do some development in parallel. While building on an unstable base wasn’t always easy, it certainly has its benefits: We could check the viability of the Frameworks goals, and catch regressions early on. A good test harness only goes so far, actually building a real world application with the libraries makes sure they’re stable and functioning. These days, the issues are gone, KDE Frameworks has stabilised enough that applications can be ported quite easily.
With the move to Frameworks 5 come some architectural changes that allow us to cut out some “runtime fat”, we can get rid of some separate processes with the new architecture, which results in a leaner system for the user.

QtQuick for the UI

Plasma Next wallpaper selection

Plasma Next wallpaper selection


The transition to QtQuick reaches a very significant milestone in Plasma Next: the whole UI is written in QML. This concludes a transition process which we’ve started in Plasma 4.x, as a side-effect it solves a whole class of long-standing quality and maintenance problem in the code, it means a higher quality for many users. The transition to QtQuick-based UI has been fairly smooth so far, so we are not jumping onto something entirely new here, which means that we have been able to port much of the existing and matured functionality from Plasma 4.x over to Plasma Next. Our QML APIs have not changed radically, so porting existing code written in QML to Plasma Next is not a huge amount of work. For add-ons written in other languages (UIs written in C++, Python and other languages are currently not supported, this is a conscious design decision, and unless there are QML bindings for these languages (which seems like a weird idea), this is unlikely to be supported in the future. Instead we’ve improved and matured the QML API to a level where it’s very easy to create almost anything you can dream of in QML.

New Graphics Stack

Plasma’s graphical stack reaches a new state-of-the-art this year. We are now able to fully offload the rendering of the UI into threads, and other processes, making the UI responsive by default. We also offload visual effects almost entirely onto the graphics card. This means that it’s faster, so you get better framerates out of it, it frees up CPU time for the user and it’s also more energy-efficient, so saves some battery life.
In case the system falls back to software rendering, we can now centrally disable animations, so even on systems that paint slowly, or we can reduce repaints drastically to give a snappy feel. This means that the visual effects in the UI degrade gracefully with available graphics features on the system. For the vast majority of users, this isn’t an issue anyway, their systems run a fully hardware-accelerated desktop with complete ease. On these systems we can improve the user experience by using the graphics card’s capability — and not only that: The transition to QtQuick 2, which is part of Qt5 means that all the work at UI level can be offloaded onto the GPU as well.

Another hot topic these days is Wayland readiness. This is currently work in progress, Martin Gräßlin’s blog shows some impressive progress on running KDE applications on Wayland. This is one of many important milestones. The most complex case is running a full Wayland session with Plasma and KDE applications, and we are not there yet. Wayland support is continuously improved.

Polished Interaction

Let's try a dark theme

Let’s try a dark theme


Next to these architectural changes, we’ve also put some work into the actual UI visuals and interaction. We are in the process of establishing a Visual Design Group in KDE. Which already participates in the development of Plasma Next. The first results of this will be visible this summer, and the group is currently hashing out plans for the future. There is some serious design love appearing. You can follow the progress of it on the wheeldesign blog.

One of my favourite new features that has recently landed is Marco’s work on contrast behind translucent dialogs, which hugely improves readability in many cases, and make “the old Plasma” almost look bland in comparison. We’ve cleaned up quite a lot of workflows, not by making them any different, but by removing visual noise in between. The idea is to polish common elements to feel fresh and like an upgrade to users, but not entirely different. In the UI, known behavioral patterns are kept in place, with more pronounced core functions, and less fuzz around them. We’re aiming at keeping all the functionality and adaptability in place. To the user, the migration to Plasma Next should feel like an upgrade, not something completely new, but trusted after a bigger step in its evolution, yet recognizably true to its values.

We want to achieve this by concentrating on the core values, on what makes us good, and what users love us for. But we also do not want to pass the opportunity to fix what nags us and our users. Improvements in details mean that we listen to our users, a large portion of which do not want to be the subject of UI experiments, but who require a reliable system that supports and improves the personal workflows they have almost brought to perfection.

Of course, all of these workflows rely on many details behaving as they do, and these things are different for everyone. A small difference in behavior, or a missing seemingly minor feature might make or break any given workflow, there is no guarantee to be made, just a promise of best effort.
Many, but not all parts are co-installable, and it will be possible to use KDE SC 4 applications in a Plasma Next environment, and vice versa.

Beyond Devices

Plasma Next runs on top of a device-independent shell. The whole UI is structured into logical blocks that can be exchanged at runtime, this allows for dynamic switching the user interface to suit a different form factor. A target device will typically have the plasma-shell (and runtime bits) installed, and one or more device-specific shells. We are now readying the first of these “workspace user experiences”, Plasma Desktop. Others, such as the tablet-oriented Plasma Active UX will join in subsequent releases.

When will it be good enough for me?

While no .0 will ever be perfect, I expect that Plasma Next.0 will feel very much like an evolutionary step to the user, and certainly miles away compared to the impact of Plasma in KDE 4.0. For those that still remember the transition from KDE 2.2 to KDE 3.0, this seems rather comparable. While KDE 2 was almost a complete rewrite of KDE 1, the 2 to 3 transition was much less radical and far-reaching. We saw the same pattern between KDE 3 and 4, which again was quite radical, especially in and kdelibs and even more so for the workspace — Plasma which was completely new in 4.0.

In the first stable release of Plasma Next we want to provide a stable and fully functional core desktop. We concentrate on making the most important default functionality available, and are polishing this first and foremost. I expect that most users can be just happy with this first release, but as I said, there’s no guarantee, and maybe you’re missing something. For those that want to make the switch later, we have of course our long-term maintained current Plasma stable, so there’s no rush.
This concentration on the core also means that not every single feature will be available immediately. We are, however aiming at feature parity, so in most cases, a missing feature in .0 will be brought back in a later release. The kdeplasma-addons module, which contains additional functionality will likely not be ported by summer.

Ultimately, the way to make a good Plasma Next happen is to lend us a hand and take part. Even better, you don’t have to wait with this until summer. Take the plunge, build KDE Frameworks 5 and Plasma Next, try it and help us completing the core functionality and to fix bugs. That is exactly what we will be doing in the next months leading up to the release this summer, and we hope the experience will be delightful one for our users.

Reasonable DPI in Plasma Next

Friday, February 7th, 2014

We are currently looking into how we can improve Plasma (but in extension also other applications, including QWidget-based ones) on hardware that sports unusually high DPI (also called “reasonable DPI”). In this article, I’ll outline the problem space and explain our tools to improve support for high DPI devices in Plasma.

First, let’s take a step back, however, to explain the problem space to those who haven’t yet spent that much thinking on this. Most of today’s desktops and laptops have have roughly the same amount of pixels per square inch of screen space. The amount of pixels per inch is measured in DPI (dots per inch) or PPI (pixels per inch). This value is around 100 DPI for laptops. Tablets and smartphones are already available with much higher DPI screens, making for sharper fonts and overall higher fidelity graphics. A while ago, Apple has started producing laptops with high DPI displays as well, these are the so-called Retina screens. There are Macbooks on the market with 220 DPI.

Test Plasmoid showing a scaled UI

Test Plasmoid showing a scaled UI

Some people have complained for years about the low DPI value of screens available on the market (and I am one of them), higher DPI simply allows for nicer looks, and reduces the need for “dirty tricks” such as subpixel rendering algorithms (which come with their own set of problems). Graphics chips also have become fast enough (and with enough memory) to not have a problem with high resolutions (think 4K on your laptop, for example).

I’ve done some research (Well, lazy-webbing, mostly), and it seems that higher DPI screens for desktop systems, but also for laptops are still quite rare, and when you find one, they’re often really, really expensive. I believe this is caused by two reasons: production-line quality is not always good enough to produce high DPI screens, one could say that the more pixels there are on a given device, the higher the chance that one or more of them are dead, making the display unsellable, and thus increasing the price of the ones that are pixel-perfect. Also, tablets and smartphones, which often already sport high DPI screens are currently taking up almost all of the production capacity. The obvious result is scarcity and a high price. I believe it’s only a matter of time until high DPI displays become more common, however. A few friends of mine already have high DPI displays, so there is a real need to support this kind of screen well.

Battery Widget without icon scaling

Battery Widget without icon scaling

So what’s the problem? Many applications assume a fixed DPI size, or at least that the DPI value of the screen is within a certain range, so that when you render an icon at 22 pixels, it will look like a small icon, compared to text, and that its details are visible. Also, icons and sizing of fonts are loosely related, so an icon that is way smaller than the size of the text as rendered will look weird and cause layouting problems. (Imagine huge letters and cut off text, for example.)
For graphical elements, this is a real problem, but less so for text. Today’s text rendering engines (Freetype, for example) take the DPI value of the screen into account. This means that this at least partly solves our problem. Luckily, it solves the problem for very complex cases, so at least this is not of great concern. It’s only a partial solution, however, so this at best eases finding a complete solution. We need to fix these problems in different areas, and all need to have well-thought out solutions.

Limitations in X11

The bad news is that this problem is only partly solvable in an X11 world. X11 has no real concept of different DPI values per screen. This is not so much a problem for single screen systems — we just use the DPI of the only screen. As soon as you attach a second screen that has a different DPI, this is going to be a problem, and it’s not possible to solve this completely in an X11 world. We’re planning to first make it work in a single DPI environment, and then work towards supporting different DPI values per screen. (Of course we’ll keep multi-DPI-screens in mind, so that we don’t have to take too many steps back once we are actually in a position to be able to support this. This means Wayland, basically.)

Battery Widget using icon scaling

Battery Widget using icon scaling

Cheating with fonts

A pretty easy, yet neat solution is to use font metrics to compute sensible dimensions for graphical elements on the screen. The very short version is to stop thinking in numbers of pixels, and to start thinking in lines of text and with of characters as they end up on the screen. This is not a pure solution to the DPI problem, which in many cases is actually an advantage. The size (for example height) of a given letter rendered on the screen depends on a number of properties:

  • The DPI value of the screen which is used to render the text
  • The font size setting
  • The size of the font itself, as it is designed (this is usually more relevant for the aspect ratio between width and height)

This means that taking the font height as rendered, we actually can compute values for sizing elements that not only take the low-level technical properties of the hardware into account, but also user preferences (or system presets). In Plasma 2, we started using this mechanism in a number of places, and so far we’re pretty happy with the results. Some examples which where we use this is the sizing of popups coming out of the panel (for the notification area and the calendar for example), but also the sizing of the icons in the notification area (or system tray). This means instead of hardcoding pixel sizes, these UI elements grow and shrink depending on your settings. This solves a part of the problem, but is obviously not a complete solution. If you would like to implement this mechanism, here’s two snippets of code, which, with some necessary adaption, you can use to make your app work well on High DPI devices.

in Qt C++ code:

const int fontHeight = QFontMetrics(QApplication::font()).boundingRect("M").size().height();

This gives you the height of the letter “M” as it would be rendered on the screen. It’s a useful mechanism to get you a pixelsize that is dependent on the DPI value of the screen. Note that you want to use an int here, in order to not end up aligning UI elements at half pixels, as this leads to blurriness in your UI.)

We’ve bridged this API in the Plasma Theme class, which is available from QML applications by importing org.kde.plasma.core (the global property theme will be automatically set, which allows you easy access to Plasma::Theme from everywhere, in case you’re wondering where the “theme” variable is coming from).

import org.kde.plasma.core 2.0 as PlasmaCore

/* Paint an orange rectangle on the screen that scales with DPI 
   This example makes the rect big enough to paint about 8 rows
   of text (minus spacing), and allows for a column with of about 
   60 characters. Mileage varies on fonts used, and the text 
   itself, so this is an approximation.
 */
Rectangle {
    width: theme.mSize(theme.defaultFont).height * 8
    height: theme.mSize(theme.defaultFont).width * 60
    anchors.margins: units.largeSpacing

    Item {
        anchors.fill: parent
        /* ... more stuff ... */
    }
}

In the second example, you see that we’re using another property, “units.largeSpacing” for the margins. This is another piece of DPI-dependent UI which you can use to apply margins and spacing that take DPI (actually font-as-rendered-settings) into account.
To get the size of a piece of text on the screen, in QtQuick code, you can use the paintedWidth property of a Text elements, but not that this can be tricky due to text elision, line breaks, etc., so this is to be dealt with with care.

Icons and other graphical elements

Another interesting case which affects the usability of our graphcal interfaces on high-DPI screens is the sizing of icons. We are using standard sizes there, which you access via properties “units.iconSizes.small”, “units.iconSizes.large”, etc.. In Plasma, these sizes now get interpolated with the DPI value of the screen, while making sure the icons are still getting rendered correctly. The sizing is done in steps, and not linearly to avoid getting washed-out icons. This mechanism works well and automatically solves another piece of the puzzle. The result of doing this is a more balanced look and better alignment and spacing across some widgets (notably the battery gains quite a bit of beauty with this treatment).
In other UI elements, especially the toolkitty widgets we provide in PlasmaComponents, we often already scale with the text, which works just fine for reasonably-but-not-excessively high DPI values. We have done some experiments with scaling up the graphical elements that are used to, for example, render a button. As we are using SVG graphics throughout the user interface, we don’t have to resolve to dirty tricks such as doubling pixels, and we can get quite neat results. This needs some more work, and it hasn’t been merged into master yet.

The Higher-Level Picture

Now, having discussed lots of technical details, how does the user-facing side of this look and work? The changes we’ve done right now only affect the user in one way: More UI elements scale with the DPI of the screen, this means no change for displays around 100 DPI. On my laptop (which has a 180 DPI screen), this gives a more balanced picture.
As Plasma is making its way onto a wider range of target devices (think tablets, media centers, as well as high-dpi laptops or monitors), this topic becomes increasinly important. I have good hopes that we will be able to solve this problem in a way that really leverages the power of this kind of hardware. In Plasma Next, we’re now providing some of the basic tools to make UIs work well on high-DPI displays, and we’ll continue this route further on. The user will notice that in Plasma Next, most of the problems that could be seen on high DPI screen are gone, and that the whole behaves much better without many tricks.

Responsible Evolution

Thursday, November 14th, 2013
Plasma Desktop running on top of Qt 5 and KDE Frameworks 5

Plasma Desktop running on top of Qt 5 and KDE Frameworks 5

Exciting times. I am working on the lower-right corner of the desktop right now, and thought I could give a quick visual update of progress there, as well as some sense of direction where we’re heading, how the user interface evolves, Plasma’s new architecture, and underlying software stack and the device spectrum. A whole mouthful, so grab a cup of tea.

Two areas in particular are catching my attention these days, the notification area (“system tray”, that row of icons which show you the status of all kinds of things), and the clock with its calendar popup. The calendar shows quite nicely some things we want to pay attention to in Plasma 2: consistency and elegance. We are making more use of pronounced typography, are fixing alignment problems, and are looking for a generally more elegant way of presenting the common functionality. In that, the plan is not to make a lot of changes to the functionality itself, not cutting down the UI, but polishing what is already there. By reducing the workspace’s mental friction for the user makes the tools take a step back and give more room to the content and interaction that is presented. Doing that, the workspace should be functional, yet elegant. The migration should feel like an upgrade of something familiar. We want to make it functionality-wise equivalent, but more polished. On top of that, we’re readying the technology for future use cases, and evolution of the underlying technology stack.

Calender popping up from the Plasma panel

Calender popping up from the Plasma panel

QtQuick 2 actually makes these things a lot easier, as it is much more correct in terms of calculating font metrics reliably, which we need to (sub-)pixel-perfectly align text and other UI elements. Trying to make this exact in Qt4 and on top of QGraphicsView was a shortcut into madness. Ever so slightly off font metrics, and wonky layouts get you to tear your hair out pretty quicky. This is much better now, (though certainly not perfect in all areas), so it allows us to finally fix these jarring little mis-alignments that nag the eye. The calendar already does it pretty well, and serves as a nice example. This implementation takes the physical size of the pixel on the screen into account by correcting for DPI in the whole layout, so it works nicely on all resolutions and pixel densities. With higher pixel-density displays, the rendering gets more details, fonts look neater, but the size of interaction areas, and the effective size on the screen don’t change much. The screenshots have been taken on a 170 DPI display, so if the fonts seem huge on your display (or small, as I hope for you), this would be the reason for that.

Battery Monitor

Battery Monitor

In the notification area, you might notice that the widgets that have been living in there are now contained in the same popup. This results in less window management and layering of small popups in the notification area, clearer navigation and a cleaner look. The currently active icon has slightly pronounced visuals compared to the others.
The calendar will of course show information about tasks and agenda (this part doesn’t work yet). One neat thing which the new architecture allowed use to do very easily is lazy-loading the calendar. As just loading the calendar can result in quite a bit of loading underneath, delaying to loading it on-demand speeds up start-up time and lowers memory consumption in a lot of cases.

Below the surface, the changes are more radical. Qt5 and with it the move to QtQuick 2, the scenegraph-based successor to QtQuick 1, a new QML and javascript engine which is smaller and more optimized for Qt data types and conventions than V8, new sandboxing features, being able to render and composite pretty much entirely on the graphics card, share textures between compositor and workspace shell, addition of Wayland as a fully supported target platform, and along with all that new input and security features.

Network ManagementNetwork Management in the notification area

Network Management in the notification area

Plasma 2 is a converging user interface. It allows to control the Look and Feel at different levels. On the lower level / higher detail side of the scale, we look at adjusting input areas, sizing of ui elements, and interaction schemes by swapping out and “overriding” parts of the UI toolkit with, for example, touch friendly versions of widgets. On a higher level, we support laying out the furniture of the workspace (think of alt+tab window switcher, log in, lock, etc. features) by more code sharing and a different logic to how they’re loaded (and swapped out). Plasma shell allows dynamic switching of shell layouts at run-time. The shell is equipped to morph between workspace presentations, so should your tablet suddenly get a keyboard and mouse plugged in, it changes its disguise to a traditional (actually your own customized) desktop layout. While this is cool, in reverse, it allows us to isolate changes that are done to suit other devices from the “Desktop Experience”. Just because the workspace support multiple devices, the user doesn’t get the lowest common denominator, but specialization. Different devices are different for a reason, and so should the UI be. “Mobile-friendly” shouldn’t mean “misses features”, but “responsibly designed” (excuse the pun).

Our tricks allow to use the same system on a range of devices, with the user interface adopting to specialties of hardware it runs on, such as input, display, but also usage scenarios specific that device. Much like the Linux kernel, which “mostly figures out how to run properly in a device it’s booted on”, and which can be configured as small and as big as one wants, the user-interface uses “UI plugins” at different layers, and detects changes and adopts to the form factor. You use a media center “driver” if you want to use it on the TV in your living room, you use a tablet “driver” on your tablet on the go, you use desktop driver on the laptop, and you can switch the device’s UI when needed. Laptop or tablet + HDMI cable ~= media center, isn’t it?

Klipper manager showing the clipboard's content

Clipboard interaction

You see, many different construction sites. We’re working a lot on all these things and you should definitely consider joining. Nothing is set in stone yet, and you should consider the imagery functional mock-ups, rather than the final thing. It’s not perfect and lacking in all kinds of places, it even crashes in some and what is presented is just a snapshot of work in progress. Many details remain to be hashed out. Still, I’m running Plasma 2 about half of the time on my laptop now. It’s just about to be becoming usable and almost dogfoodable for more than just a very small handful of people with an elevated pain threshold and a debugger at hand.

“When?”, I hear you ask. We’re aiming at a stable, end-user ready release of the new Desktop shell in summer 2014, at the end of Q2. On of the next milestones will be a tech-preview, which is planned for mid-December, so just about a month away from today. From December, where we’ll reach the point of having the basic functionality in place, we’ll spend time on filling in the missing bits, making sure everything runs on Wayland, and on polishing and quality improvements. Integrating additional workspaces, such as Plasma Active and Plasma MediaCenter are also next year’s roadmap. These will become the tablet, resp. media center drivers.

Plasma Next: What’s changing?

Friday, November 1st, 2013

In the past week, we hit something that really feels like a milestone in Plasma development. Plasma 2 has become somewhat usable, at least if your pain level is high enough. It occurred to me after I realized after a few hours of using it that the workspace shell running on my laptop was not actually the current stable release of Plasma, but the development version. Great thing, I thought, went ahead and fixed a sizing bug in the systemtray widget, then changed the default layout to include Kickoff, Taskmanager and Systemtray in the panel, as these elements are the most important ones to have in the panel — exposure even to just our development team surely won’t hurt. This experience also marks a point where we have to take a step back and look at our general direction. Sure, we could do a “minimal port” and just make everything build and work on top of Qt5.

I can hack on Plasma2 using Plasma2!

I can hack on Plasma2 using Plasma2!


One of the technologies we’ve been using more and more in the Plasma workspaces is QtQuick, a declarative language that allows you to very easily write stunning UIs, without the need to use C++ for these parts. Our experience is that it makes developing, improving and maintaining applications a lot easier, and generally leads to much nicer user interfaces. QtQuick, being a very young technology in Qt4, has matured since then, and received a major technology update in Qt5. It moved from a traditional painter-based mechanism to a scenegraph model, and much closer onto the graphics hardware. That means that we usually get much better performance out of it, and that it allows a whole bunch of neat tricks on top of that. In Qt 5.2 (which is the Qt release we’re basing our work on), it received another big upgrade. The scenegraph renderer has been replaced, with huge performance gain as the result. (Read Gunnar’s article about it, it’s really impressive!) QtQuick also received a new QML engine, which brings major improvements to its internal data handling, but also to important topics such as maintainability. The new v4 engine uses Qt types internally, so a lot less marshalling is needed between runtime objects, and some architectural barriers have also been removed. Lars has written an excellent article about the new QML engine.

So on a technological level, we have decided to not do this. We want a more modular software stack underneath, so we decided to rework the KDE Development Platform into something that is more useful in its pieces. The result of that (the process isn’t finished yet, but rapture lines are becoming very visible) is KDE Frameworks 5, a modular set of Qt-based libraries with well-defined dependencies which separately are all very useful to 3rd party developers, and combined give you all the functionality to build highly integrated complex applications on top. Plasma next builds on Frameworks 5. In the past 1.5 years, we have spent a lot of time on reworking the build system and removing interdependencies between various “sublibraries” that made up kdelibs. This has progressed really well, we are in fact able to build and use many of our libraries standalone already. We’re currently restructuring the last libraries to accommodate a split, and will then “physically” split the libs into separate repositories. In order to not make the effort to build a KDE application or workspace explode, we have developed tooling that can build sets of modules for you. You get to choose the granularity we work with. In order to make it easier for third parties to find and use our libraries, we have set up Inqlude.org, which has information about these (and other) libraries. This is very much work in progress, but it does already give a good picture of what’s to come.

For the user, we want to keep this whole process as smooth as possible. Porting applications to Frameworks 5 is rather easy, as regarding kdelibs, it mostly involves changes to the build system, some mild Qt5 porting, and only a few API changes. It is nowhere nearly as disruptive as the move from KDE3 to KDE4 (yes, our software was still called KDE${N} back then!).
In Plasma, it’s a little more complicated, as much more changed under the hood (a completely new way to get graphics onto the screen, deprecation of larger parts of our API, more device-independence reflected in our architecture). Our goal for the first release is to not introduce functional regressions however. We want to keep the basic usecases of a Desktop fully working, preferably noticeably improved. In the past years, we have already moved a lot of the individual components (such as the task manager, widgets for battery, network management, etc.) that make up our workspace to QML, this pays off now as those things are rather easy to port, and give a very mature impression right off the bat. We do realize that we have some cleaning up to do, and now is a good time to do this. We want to introduce a greater degree of consistency across the workspace experience. Technically, this can be achieved by more and smarter sharing of code, so common UI patterns become more, well, common. Plasma’s design language will be more pronounced, and at the same time, easier to change to your liking. More on that in another article, however.

As it currently looks like, we will release a first technology preview of both, Frameworks 5 libraries and Plasma Next in December. This won’t be a complete thing by any means, but a way to check on and gauge progress. At the same time, you’ll get to have a good look at Plasma Next, which, while building on the new technology stack, will resemble our current offering quite a bit still. It is much more a technology preview, than a user experience preview. So don’t judge too early, rather, get your hacking shoes on and join the fun. :)

What’s going on in Plasma Workspaces 2?

Monday, March 18th, 2013


While moving its codebase to Qt5, the KDE Development Platform is undergoing a number of changes that lead to a more modular codebase (called KDE Framework 5) on top of a hardware-accelerated graphics stack. In this post, you’ll learn a bit about the status of Frameworks 5 and porting especially Plasma — that will be known as Plasma Workspaces 2, paying credit to its more convergent architecture.

Let’s start with something visual, before we get to the nitty-gritty:


Video showing a basic port of a Plasma Desktop Containment to Plasma 2

Frameworks 5

A whole bunch of libraries can now be built, installed and packaged separately. Those include (in tier1) Solid, Threadweaver, kdecore, karchive, kwindowsystem, and more, and in tier2 kauth and kconfig. Plasma has already moved into its own repository, and can of course also be built separately.

Kevin has been plugging away at removing problematic interdependencies between those libs, and recently could ditch (i.e. move to kde4support) a few classes that make it easier to just use Qt machinery (QApplication & friends) to bring up “KDE applications”. KAction has gone, KAboutData, so KDE Applications are now less “special” in the Qt world — a good thing for portability.
Splitting and untangling kdeui from kdelibs proves to be a bit more work- intensive than initially hoped. Fracture lines are becoming visible. The problem here is that this task is holding up the parallelization of development, so this has a high priority right now.

We’re also using a continuous integration system now to keep us on our toes with respect to “buildability” (which can be a bit daunting with so heavily shifting ground in kdelibs, this will calm down at some point though).


Video showing a Plasma 2 OpenGL shader demo widget

Plasma & KWin

Good progress, especially in the last month, in three areas:

API reviews: we’ve been doing weekly sessions for libplasma2 API reviews, where we’re going through the entire API and think about improvements for the Plasma 2, post-graphicsview world. As a result, libplasma2 has shrunk to about 1/3 in (compiled) size in its current state. We don’t expect it to grow much, since, in the scenegraph world, it plays another role than previously (although developers used to QML won’t really notice). (Join in the Hangout, if you like, we usually start on Monday morning around 10.00 UTC, just pop up in the #plasma channel and ask Marco to invite you). Our mutual status updates and Cool New Development is recorded and made available on Youtube for interested people, Last Monday’s session can be found here, but today we skipped it — you get this more detailed blog post in return. :)

Imports: Basically our QML runtime, it consists of Plasma Components, extras, bindings for things like dialog, framesvg and dataengines, drag and drop, krunner models, and a bunch of other stuff. I’m working on this right now, and have about 95% of the imports originating from kde-runtime working in Plasma2. We’ll be able to offer almost the same API to Plasma2 QML users, as in Plasma1, so porting of your QML code will be very easy.

Shell: In Plasma2, instead of having specific plasma-desktop, plasma-netbook, plasma-device shells, we will use one “generic” shell that loads containments (which then load applets), wallpaper, toolbox, etc. The shell can dynamically replace these components (change wallpaper, for example).

A few things are new here: in Plasma2, plasmoids provide their config ui via QML files, that are part of the package. That solves the problem that we could not really influence the behaviour of the configuration UIs from QML in Plasma1. It will also allow to transparantly switch between instant apply and “OK/Apply/Cancel” buttons, depending on what fits the usecase. Marco is on this.

Martin has been pushing the removal of the direct X dependency further through porting to XCB. He’s also recently started on a Qt5 port. One problem with KWin is that Martin needs a bunch of changes to have QtQuick and KWin run in the same process, that means making sure that KWin and Plasma (or QtQuick2 really) properly share and interact in the same OpenGL context. There’s a chicken-and-egg situation for kwin, since it needs to load for example window decorations and task switchers (both from QML) to be useful, but it can’t right now. The X11-based windecos won’t make it into Plasma2, so we’d rather avoid porting them just for the time being. Martin is on that though, and he earns our gratitude for going through this painful period in the porting procedure.

Desktop Containment moving to Plasma Quick

Tuesday, January 29th, 2013


As many other components of the Plasma Workspaces, Plasma Desktop’s default Containment is being ported to QML. A technology preview of the containment is being demoed and can be tested by a wider audience now. While the port is mainly replicating the current desktop containment in QML, its interaction scheme to position and manipulate widgets on the desktop has been improved.

First of all, a note: The code presented in this article is not part of the upcoming Plasma Desktop 4.10. It can easily be installed on top of it, it might see inclusion in the summer 2013 release, however

In our Roadmap, you learn that KDE is currently porting many aspects of its workspaces to QML, with the goal to create a more modern user experience on top of state-of-the-art technologies such as Qt5, OpenGL scenegraph and Wayland. The move to QML is a gradual process, made possible by the componentized architecture of Plasma. Widgets and other components that make up the workspace are replaced with QML ports one by one. The premise is to not introduce regressions by shipping each component “when it’s ready”. Ultimately, we need a complete set of QML components to run the whole desktop (and at some point also apps) directly on top of the graphics hardware, leading to higher graphics performance and more available resources on the CPU.
One of the important pieces is the Desktop containment. This is the component in Plasma that is responsible for managing and laying out widgets on the desktop and creating the toolbox (which makes some “workspace actions” available to the user. In general, a “Containment” is an area on the screen (a panel, the desktop background, the dashboard, …), and it takes care of managing widgets, their position and sizing within. It also offers access to action specific to widgets, or the containment or workspace.
The currently shipped (also in 4.10) default Desktop containment is written in C++, using QGraphicsWidgets and offers free placing of widgets on the desktop, with a bit of edge and overlap detection and repositioning poured in.


Demo movie of the new QML Desktop containment

User interaction improvements

Most of the new containment is exactly the same as in the current default — this is done by design, we do not want to introduce radical changes to the workspace (and the users’ workflows), but rather improve gradually and in an iterative process. There are two areas (which in fact are closely related) where we did change a few things: positioning/sizing and visual cleanliness. These are expressed in two changes: integration of applet handle and positioning aids.
In order to reduce visual clutter, we integrated the applet handle into the applet’s background frame. Previously, it would be its own frame, and shift out as separate element from under the widget. Merging handle and background frame reduces the number of distinct elements on the screen and allows less intrusive transitions when the widget handle becomes visible.
The second important change is that we now provide helpers when the user moves and resizes a widget. When moving, we show a halo at the position the applet will snap to when dragged. This makes widget placement more predictable and allows the user to get it right in one go. We also align the widgets to an invisible grid, so applets automatically end up being aligned pixel-perfectly with each other, which leads to a more ergonomic workflow, cleaner appearance of the workspace, and again to less visual clutter.

Platform improvements: Bindings and Toolbox

An important aspect of the work on the QML containment, was to improve the bindings which load declarative code (QML) into Plasma shells, these improvements are included in Plasma 4.10, due to be released in early february. This includes the necessary platform features to allow running fully-featured QML containments, something which we have done in Plasma Active for a while, but within a more confined context.

As a result of this work, Plasma can now also load toolboxes written in QML. The Plasma Toolbox is the little widget with the Plasma icon you can see on top of many containments, and which gives access to actions such as add widgets, settings, shortcuts, etc.. The toolbox used with the containment shown is a 1:1 port of its counterpart in the current default (C++) toolbox. The name of the toolbox package is currently hard-coded in the bindings (it loads it from the org.kde.toolbox package and silently falls back to the C++ implementation if that isn’t found — a 4.10 feature), but it also opens up this part of the workspace to QtQuick goodness. The toolbox is basically a translucent layer on top of the desktop, so much freedom is given to other implementations).

A template and a bridge

The code is not only there to replace the current containment, it also serves as a template for new developments. With the new containment bindings in place, it is now very easy to create your own containment, modify someone else’s and publish them to share them. The containment shown is just one example for what we can do with the QML integration features in Plasma. As Plasmoid packages are architecture independent, this of course works across devices and different workspaces.

The work that is upcoming in Plasma Desktop is further bridging the gap between Plasma’s interfaces for different devices and formfactors. Some of its code has been introduced in Plasma Active, and is now available in a more generic fashion also for Plasma Desktop (and Netbook). This brings us closer to one of our goals, having only one shell that dynamically loads a suitable interface (Containment, Widgets) for a given formfactor, use case, output device, etc.

Give it a spin

If you’re interested and would like to try it (we appreciate feedback, it’s especially valuable in this phase!), there are two ways to get this containment. The minimal requirement for it is Plasma 4.10-beta1.
If you’re using git, you will find the code in the branch called “plasma/sebas/desktop-qml”, just check it out and build it, install it, run kbuildsycoca4, and you’re done.
If you are using the packages, you can easily install the following two Plasmoid packages to your system:

If your system is using a version prior to KDE SC 4.10-beta1, the packages will install, but not work.

The following commands install the necessary Plasma packages into your home KDE install directory.

# create the package directory and go there
mkdir -p `kde4-config --prefix`/share/apps/plasma/packages/org.kde.toolbox
cd `kde4-config --prefix`/share/apps/plasma/packages/org.kde.toolbox
# unpack the plasmoid package
unzip ~/path/to/toolbox-git28012013.plasmoid
# check if it's installed correctly, 
# this should list metadata.desktop and contents/
ls -la `kde4-config --prefix`/share/apps/plasma/packages/org.kde.toolbox

[Edit: changes --localprefix to --prefix, as we've found a bug in --localprefix code.]
Then install the desktop containment package (If you’re updating the containment at a later stage, use plasmapkg -u.):

plasmapkg -i desktop-git28012013.plasmoid

You can now choose the new containment from Layout dropdown in the Desktop Settings, pick “Default Desktop (QML)” there.

I would like to thank Blue Systems for supporting my work on the above topics.

An ownCloud Client for KDE Plasma

Thursday, December 13th, 2012

Preface — The Synchronization Problem

ownCloud offers a Free software solution to synchronize your files across different devices. I’ve been working on a KDE Plasma client for this server technology. In this article, after giving a bit of background of the problem, I explain the design concepts behind the new ownCloud Plasma client and demonstrate how it works and integrates with different Plasma workspaces.

I’ve been looking for a good solution to synchronize my data across different devices I use forever. The need arose when I got my first laptop (next to my desktop machine): I wanted to be able to work on my projects on both devices without having to manually copy files between the machines. It turned out to be actually quite a hard problem: Sure, you can work on your stuff on a remote machine, and thereby always work on one version of a certain file. But what happens when you’re offline? I needed files to be synched, and was looking for a more or less automated that worked both offline and online. I took a look at the Coda Filesystem, which seemed to solve this problem well, for others at least. It was a bit of a pain to set up (and understand how it exactly worked), but after a bit of fiddling, I had copies of my stuff on different machines. It seemed to work initially, but later turned out to be a little bit too brittle for my use cases (I don’t quite recall the details, but eventually, I gave up on it because it meant more or less constant maintenance, and still it wasn’t quite as bullet proof as I had hoped it would be.
At university (where I both studied and worked for quite a while), we often used SVN for collaboration. There’s value to using the same tools in more places, so I put all my files into an SVN repository and used that for synchronization. Eventually, I moved these private data repositories to Git, as I grew more comfortable with this tool and it allowed useful things like offline commits and synching between “client devices”, not just between client and server. Not an automatic process, also not the most beautiful solution to the problem as it wasn’t quite as automated as I’d have liked it to be. Also, as computing became more portable, I needed something that would also blend in well with with all the devices that produce, collect and are supposed to carry my data.

Enter ownCloud

ownCloud widget sitting in the panelMy problem is of course not unique to me: File synchronization plays an ever more important role, Internet connections become faster and more ubiquitous, the device spectrum expands. Where people have been using one computer for all their electronic communication and computing needs, it now spreads across different devices, desktops, laptops, tablets, smartphones, media centers, and likely many more form factors we can only dream of today (or maybe not even that!). Devices jumping between network infrastructures doesn’t make it easier, and the most flexible solution seems to a central server – multiple clients model. ownCloud offers exactly that, it’s Free software (licensed under the AGPL), is easy to setup and runs on bog standard LAMP setups. Its server side performs well enough to be able to run it on even woefully underpowered hardware such as NAS systems or other embedded devices. More importantly, it gives you full control over your data, which is nice and important for private use, and often a hard requirement for institutional use cases, such as document management and sharing in a company.

I’ve been keeping a keen eye on ownCloud for a while, and, somewhere in its 3.x cycle, I decided to set up owncloud on my private server and started experimenting with it. Installation was quite easy, and the desktop client Mirall seemed to work well initially.

My own Plasma Cloud

After using it for a bit, I ran into a few problems, some of them simple bugs (most of which seem to have been fixed), some UI issues, and also a lack of integration. Mirall’s UI is a “standard systray application”, it always sits there in the system tray, shows its status and allows you to set up directories (“Folders”) for synchronization with the ownCloud server. Mirall’s UI, however bears all the traits of a “traditional” desktop application: It’s unsuitable for touch interfaces, abuses the system tray as task switcher and overall not quite up to modern UI standards we use in Plasma. As Mirall is geared towards portability (it’s the official desktop client for Linux, Mac and Windows), it lacked good integration into Plasma — the usual lowest common denominator problem). What crossed my mind was redoing the UI using Plasma technologies, thereby updating its Look & Feel and at the same time making it suitable for touch interfaces, such as Plasma Active, KDE’s device-independent user experience.

Collaboration for a new design

ownCloud settings moduleAt Akademy this summer, Klaas (who works for ownCloud Inc. on Mirall), me and a few others sat down to talk about better integration of ownCloud into the Plasma Desktop. ownCloud being a project very close to KDE (it sprang from the KDE community, had developer meetings and travel expenses funded by the KDE e.V., partly runs on KDE infrastructure, and some KDE developers are also working on ownCloud), that seemed like the right thing to do. In a BoF session, we sat down, talked about what we’d like to see improved and started designing a KDE Plasma client for ownCloud, based on the Mirall code base. What we came up with can be explained as follows:

  • The UI bits and synchronization code from Mirall will be split, and the sync mechanism will be split out into a shared library
  • The shared library is used by a daemon, which on the one hand takes care of keeping files in sync, and one other side exports a DBus control interface
  • A Plasma widget shows synchronization status and allows basic control like disabling syncing
  • A System Settings module allows to setup synchronization of the ownCloud client
  • A Plasma Active Settings module allows to set up the ownCloud client from your mobile device

With this solution, we can cover a range of devices, providing a consistent operation and Look & Feel and share code to keep development costs down. Doing the UI components in Plasma Quick (Plasma and KDE technologies + Qt Quick’s QML), we can the maximum amount of code across different devices, and create a modern UI that adapts itself to form factors and input methods (meaning it will work well on both, mouse/keyboard driven target devices, as well as touch screens). As a bonus, doing the UI in Plasma Quick means it’s easy to hack, easy to contribute for others.

Inception

Having a clear idea how we want to go forward, and an agreed-upon plan de campagne, we sat down to implement all the designed goodness. Klaas was quick to split out the synchronization mechanism from ownCloud into its own shared library, and I started working on the bits needed for the Plasma client: The sync daemon, the UI components used by the configuration modules and the Plasmoid, and of course those UIs themselves. Progress has been quite good, I quickly got the synchronization daemon up and running, and could move to implementing the various pieces of user interface needed.In the process, I’ve created a bunch of patches to Mirall, some of them merged, others still in the review queue. They’re mostly fairly trivial, splitting out a bit of QWidget-based remainders from the daemon (and thereby cutting down its size considerably), and extending the API (in a backwards compatible way) to allow better status display and control from the user interface “satellites”.

Current Status

File synchronization is of course the main feature here. This already works reasonably well, including setting up of server and folders. The UI has a few problems here and there, but the important pieces are in place. The plan is to ship a first stable version with the release of Plasma Active 4 in March, which will also mark the availability of the desktop client.

How to make it all happen faster?

I’d be most grateful if distro packagers would pick the new ownCloud Plasma client up at this point, package it and allow users to test it (with the necessary warning signs of eating pet and firstborns attached, of course). There’s still quite a lot of work to do, but the basics work, and getting feedback helps me prioritize what to work on first to get this into the hands of our dear users.
Of course if you’re interested in contributing to the client directly (in the form of code, UI design, bug fixing, polishing, performance, etc, you’re also most welcome to do so. The code is currently hosted on Github (like other ownCloud subprojects, if you prefer a Free software solution, we can clone it on KDE infrastructure as well, and sync our upstream changes as needed to Github). In order to build it, check out and build the “plasmaclient” branch. This will install the various components to your system. After running “kbuildsycoca4″ (or relogging in), you can enable the Plasma widget through your notification area configuration.

Inspirations from FOSS.in 2012

Tuesday, December 11th, 2012

a young visitor to HampiI’ve attended FOSS.in in Bangalore two weeks ago. FOSS.in is the largest Indian Free software conference, and has been on my list of conferences to ever attend for a long time. I’m back home for a good week now, so it’s time to recap a bit my experiences there. I travelled together with Lydia, a.k.a. Nightrose, who was attending on behalf of Wikimedia to tell about Wikidata. For the conference, I was scheduled for a talk about Plasma Active, and we also did a workshop on creating device-adaptive interfaces. More on that later.

Lydia and I went a few days earlier, to have some time to see Bangalore and surroundings. It was my first time in India, so also a good opportunity to see a few new things here and there, and to acclimatize. On the first day, we went around the city a bit, and later were invited to PES-IT, a renowned Indian IT college, where a 24hour open source hackathon would take place. Lydia and I held ad-hoc presentations about getting involved with KDE and Plasma Active respectively, followed by hands-on demos and discussions about both technical and non-technical issues. The students and professors were very friendly, and it was awesome to see enthusiastic students spending their weekend together hacking. We only arrived late at night back at our hotel, after some long and enlightening discussions about Free software and Indian culture. What struck me in particular (and in a very positive way) was the number of girls attending, about one third. In most “Western” countries, information technology is very much a male trade, Dutch universities for example struggle to attract more than one or maybe two girls each year for their computer science courses. India is way ahead there, which on the one hand is great to see, but on the other hand raises the question what is going wrong in my home country. Free software communities suffer from the same skewed demographic, so the same question applies here.

Hampi

Jean-Baptiste (j-b) of VLC arrived two days after us, and we all hopped on a nightbus to Hampi, a UNESCO heritage site, an old capital of a long-gone empire and religious centre a few hours North-West of Bangalore. There, we spent an unforgettable day, from watching (and participating) in the morning ritual of washing your body in the river, sipping a glass of chai, having a wonderful breakfast under the Mango Tree, watching temples in a beautiful surrounding, more wonderful curries, chais, temples and friendly people to enjoying the sunset from the top of a mountain.

Aakash

On Thursday, FOSS.in started. One of the booths that struck me first was the stand of Aakash, which is a low-cost tablet meant for students. The tablet is procured by the Indian government under the supervision of the Indian Institute of Technology in Bombay (IIT-Bombay). It is running a dualboot Linux/Android system right now. The Aakash people have already looked into Plasma Active (they prefer it much to Android, but there were some problems getting it to run on their hardware. The hardware is a 7″ tablet with a a capacitive screen, 512MB RAM and otherwise an Allwinner A13 chip with Mali400 GPU. That should just be powerful to enough to run Plasma Active. I got demoed a few applications, both under Android and Linux which quickly revealed why Android was not the best choice: Android basically made a lot of apps run 3 times slower. In the course of the next days, I sat down with IIT’s developers to look into problems they had with getting PA to run. We made some progress, and fleshed out strategies how to get it to run. One bigger hurdle is the lack of a good graphics driver, other tasks involve “relatively simple” system integration tasks. Doable, it seems, and a wonderful opportunity to bring KDE’s software to a very large new group of users.One thing that struck me as genius in this project is that it is not limited to procuring hardware and getting it to boot, but a large part (60+% of the budget) is allocated to content creation. Software is created under the GPL, content under Creative Commons, non-commercial licenses. Translation of content is an integral part of the project, so this initial Freeing of educational content has the potential of being very useful far outside of India as well. Visionary.
As with any big project, there are also critical voices. Hardware is one issue, building a relationship of trust with Chinese manufacturers is not easy, as is getting the manufacturer to understand the constraints and requirements of Free software. I wish the Aakash project all the success it needs however, and we will continue to support the goals of the project. This could be the beginning of a wonderful thing. :)

Plasma Active Presentation and Workshop

Holy cows feeding on trashOn the first day, I held a presentation about Plasma Active, its approach, technology, goals and so on. The talk took place in the main hall and was well attended. I collected some valuable feedback, and am happy that people understand the ideas and believe them to be right. The next day, we held a KDE miniconf, where Shantanu and me did a workshop on developing device-adaptive apps. In the workshop, we outlined the process from idea to running code on a device, and dug into details. We had about 50 interested visitors, the workshop itself was quite interactive, and we did some live-coding, it was a lot of fun to do.

conf.kde.in 2013?

During the conference it became evident, that the Indian KDE and Free software community would very much like to organize an Indian KDE conference again. After conf.kde.in 2011, which was a great success, this seemed like a good idea, so we did some planning on that, asked if people were willing to volunteer in the organization and outlined a few possible options. The discussion has moved on to the kde-india mailinglist, so if you are among the people who would love to see conf.kde.in 2013 happen, join the list and add your ideas and man/girlpower!

The Internet of Things

One of the presentations I attended during FOSS.in was by Priya Kuber, who works for Arduino. Arduino produces a open source hardware microcontroller aimed at educational purposes. The talk was very inspiring, so I wondered if I could use this for some home automation tasks, as simple example a remote power switch to turn on my workstation in the office, or somesuch. Priya sat down with me and quickly got me going with my own basic programme for the Arduino microcontroller, and it was all very easy and fun. Back home I ordered an Arduino starter kit, which has already arrived and contains basically what I’d call a kid’s microcontroller wet dream, it has the Arduino Uno board, LEDs, sensors for light, temperature, an LCD display and a bunch of other small electronic components along with a nice book. Surely something to spend the calmer Christmas days with, old style. :)
Still in India, I sat down for an afternoon and hacked up some code to use with this little project, and got already quite far. The idea is to connect the Arduino to my RaspberryPi (which is energy-efficient enough to run 24/7), run a small http server on the RPi and use that to remote control physical devices at home from a remote location (I’d like to think of a tropical island here ;)). I’ve implemented the server in twisted Python, it presents a JSON interface, which can be directly consumed from a QML Plasmoid, on either my laptop or any Plasma Active device. I didn’t get around to doing the actually interesting hardware part, yet. Maybe this is the feable start of using KDE technologies for home automation and domotica?

I would like to thank the KDE e.V., the foundation for the KDE community, for supporting my trip. You can also pitch in here, to make participation of KDE contributors in this kind of events possible by Joining the Game.

Randa Meetings 2012: The Future of QGraphicsView in Plasma

Saturday, September 29th, 2012

I’m on my way back from the Randa Meetings, where a few teams in KDE came together to collaborate on the next steps in their respective subprojects. I’ll post this to my blog after arrival, but as I’ve got some time to kill here in Basel, Switzerland, close to the German border, I decided to recap what we’ve been up to in the past days. I’ll concentrate on what the Plasma team has been working on. Present were Marco, Aaron, Afiestas, Giorgos, Antonis and myself. Giorgos and Antonis are still relatively new to the Plasma team, they concentrate on on making Plasmate rock, but have also done some excellent work this week on libplasma2. I’m happy to see the influx of enthusiast and skilled new developers in the team, as that reduces the busnumber and makes it easier to achieve our audacious goals.

Peak up to the glacier from Randa
Speaking of goals, we came to Randa with the plan to achieve a critical mass towards libplasma2. But what is libplasma2 exactly? Well, while we had some plans where to go with it, there were still a few items unclear — but not anymore! One of the big ticket items was the future of QGraphicsView in Plasma. QGraphicsView had been introduced in Qt 4.1. It’s basically a canvas on steroids, that gained features to create a fluid, widget-based UI using it. In Qt4, QtQuick uses QGraphicsView as its rendering backend. QGraphicsView is heavily based on QPainter, and employs a procedural way to rendering the UI. In Qt5 and QtQuick2, graphical display is supposed to move to an OpenGL scenegraph, making it possible to move much of the work involved to display a UI into hardware, so your GPU can do its magic with your UI. The benefit for the user is mainly that we’re able to have a much better performing rendering engine underneath (so smoother graphics), and more CPU time left to do the real work of your application. (One side effect will likely also be that we save a bit of power on mobile devices, as the GPU is much more efficient in doing these tasks – it has been optimized for it. (Experts say that the saving is in the range of an order of magnitude. Wether or not it will be noticeable to the user in the end, we’ll have to see later.)

As the OpenGL-scenegraph-based rendering is an entirely different paradigm compared to the procedural QGraphicsView, we have to rethink our use of QGraphicsView. Unfortunately, QGraphicsView is deeply ingrained into Plasma’s architecture. Even more unfortunate is that it’s not as bugfree as we’d like it to be, in fact much of the occasional rendering glitches you sometimes see in Plasma-based UIs are caused by QGraphicsView problems. Moving away from QGV and towards scenegraph is likely to solve this whole class of problems.

So one thing is clear, we want to move towards scenegraph. But what about all the old, QGraphicsView-based code? Well, we already started moving components of Plasma Desktop one by one to QML. This has begun with Plasma Workspaces 4.8, a lot more has moved in the 4.9 cycle, and yet another batch will move with 4.10, which will be released in January 2013. Our credo has been that we want to ship feature-equivalent ports, in order to keep the impact for the user as minimal as possible. There will be a point, however, when we will have to remove support for QGraphicsView in libplasma, and that will likely be libplasma2. We expect this work to take still more than a year, so also third party developers get ample time to move their code to the (much nicer) QML way of doing UI. But why not keep support for QGraphicsView? Well, it’s not that easy, as scenegraph and QGV are due to their respective paradigms more or less mutually exclusive. We’ve spent quite some time trying to come up with solutions that guarantee maximum amount of backwards compatibility, but we also had to ask ourselves if we have the manpower to implement and maintain workarounds for the incompatibilities between scenegraph and QGV. Moreover, what would the impact on our APIs and our code be? the tradeoffs were quite horrific, so in the end we decided to bite the bullet, and remove QGV from the frameworks5 branch. But what will Plasma2 with out QGraphicsView become? What we came up with is actually a very neat and clean approach: Our classes that currently manage the workspace (Corona, Containment, Applet) will become abstract managers that concert how components work together. Containments and Applets will have their UI written in QML (so we can do the rendering in the scenegraph, thus in the graphics hardware). They are extensible through C++ and various scripting languages that have bindings for Qt. This way, you can choose to implement the business logic in your favourite procedural language (C++, Python, Ruby, QtScript, etc.) and do the UI in a declarative way. Things like theming, localization, distribution, and all that will still be offered by the platform.

Clouds descending into Randa

In Marco’s preliminary branch, where he removed support for QGraphicsView from libplasma2, the result is quite spectacular. The library is already about 30% smaller, and will likely lose another big chunk of code. That means more maintainability, a smaller memory and disk footprint and faster startup. As the functionality of QGraphicsView is more or less a subset of what we can do with QML, it’s not any less powerful or flexible. Just smaller, leaner and meaner (and also a bit easier to grok for developers using our APIs).

As you can see, we have been quite productive during this year’s sprint in Randa, and the above is only one part of what we’ve worked on. We’ve also made quite a dent into our TODO list for the KDE Frameworks 5 port, reviewed lots of patches, fixed bugs left and right, made existing code faster, and caught up with each other on various side projects. This all would not have been possible without the sponsors of the event, and the 287 people who donated through our fundraiser campaign to make this great event in a scenic location possible. Thank you all!

FISL13: Civil Rights and Plasma Quick

Thursday, July 26th, 2012

After a nice stroll through downtown Porto Alegre with a few fellow Free software activists from Spain, Mexica, Peru and Argentina, today was the first day of FISL13, and it was amazing. My usually screwed up biorythm in this part of the world means that I get up at a reasonable (for a conference visit) time in the morning, enough to have a relaxed shower, a bit of emailing, breakfast and still be on time for a fully packed conference day. FISL’s first day was amazing, it started off by meeting a few well known faces (Sandro, Filipe, Isabel, Knuth, I’m talking to you!), and getting to know a lot of new ones. Especially the Brazilian KDE community is really awesome (I knew that, but doesn’t hurt to mention it nevertheless). I also went by SOLAR, the Argentinian Free software organisation who offered me a nice cup of Mate tea, and an opportunity to share some ideas by means of an interview.

After a bit of booth-crawling, I went to attend two talks, which were both really excellent: The first was by Seth Schoen, who is with the Electronic Frontiers Foundation (EFF). Seth talked about privacy and data security at the United States Border. I’m sure anybody who has travelled to the U.S. in the past 10 years can relate to that. Seth explained how the border control is organised, what your right are (at the border, your normal civil rights are actually limited, so searching your luggage or detaining you for questioning can be done without good reason, unlike “in the streets”, so it’s very good to know what they can and can’t do), and how you can protect yourself in case you *DO* have something to hide (or rather, how you carry private information on digital devices across the border). There are a few methods, one is: wipe your device, do a clean install and download the interesting data only after you crossed the border, more sophisticated tricks involve temporarily encrypting your device with a key you don’t know and only get after you’ve passed through border control. Lots of interesting information there, and it makes me more comfortable when travelling to the U.S. the next time. Also, chapeau to the EFF for their protection of privacy and civil rights in general. The talk was excellently held, really interesting and absolutely worth my time.

Next up was Rick Falkvinge, one of the founders of the first Pirate Party (in Sweden). Rick talked about the history of copyright, how people who gain power all of a sudden “kick away the ladder” to secure their position, and how, in more general the Internet changes society. Another excellent talk that felt like it was really worth the time spent. Interestingly, these days, the Brazilian branch of the Pirate Party is being founded, so it’s very much a historical thing happening here. Excited to witness that.

Later in the afternoon, Daker Fernandes Pinheiro of Plasma Qt Quick Components fame and me did a workshop teaching everything you need to know to get started writing device-adaptive applications using Plasma. The workshop was well-attended, I think well prepared as well and people seemed to like it (even if we flooded everybody with a lot of information). It was quite practical, luckily Daker and me hit the right audience, so I think even if it was quite heavy on information, it’s still manageable. After a good two and a half hours where we taught the basics of Qt Quick, Plasma Quick, and how to write Plasma Components and Apps, it was evident on the faces of our audience (and judging by their questions) that people enjoyed our sharing of knowledge, and who knows, maybe a few of the attendants will join our team and become new KDE hackers. As promised, I’ve put the slides online. They provide a good overview of the technologies involved, so are probably quite useful as reading material. Of course, as sharing is good, let me know if you would like to reuse them in part or as a whole, and I’ll send you the sources (including a bit of example code). I myself enjoyed “teaching” as well. Especially Plasmate, our one-stop-shop workflow-driven Plasma IDE resonated really well with the audience, just in time for the end of this summer’s 1.0 release.

Overall, I’m really exhilerated by FISL so far. People are more than welcoming, so it immediately feels “at home” (at 12.000km away from it!), I’ve had really interesting and inspiring conversations, and everything is really well organised. I’m now at my hotel (one that focuses on sustainability, it’s really nice, well done FISL peeps!), we’ll go for churrasco in a bit and then off to the first night’s party.

My talk on “Freeing the Device Spectrum” will be on Friday, at 11.00 o’clock in the GNU hall (that’s the big auditorium). It’s targeted at a general audience, so a lot less technical than the workshop we did today. Be there, or be square!