We (the KDE Plasma Team) are sitting at the SUSE office in Nürnberg, Germany right now, kicking off the already 6th edition of Tokamak, which is the name for (most of) our Plasma meetings. A Tokamak is a container for Plasma, which uses magnetic force to keep the Plasma in one (very hot) place. For the Plasma team, it provides a high-bandwidth setting where we can discuss, design, review and hack on the technology behind the Plasma workspaces. This meeting’s topic is Plasma2, the evolution of Plasma into the Qt5 and Wayland world.
First, we agreed on a bottom line: “Plasma 2 will be at least as good as the current Plasma, and probably better in many aspects.” This means that we’ll have to invest considerable effort and time into stabilization. At this point, where we are probably still a year or so away from a Plasma2-based release, making it part of our planning now will allow us to focus on the things that we think, matter. Among that is making sure the transition to KDE Frameworks 5, Plasma 2 and Wayland will be as seamless as possible, and perceived as an upgrade to our users.
But why are we doing this? Why are we putting so much work into it, what’s the benefit for the user?
Why switch graphics stacks?
In the past years, the landscape of graphics under Linux has changed quite a bit. Many things, like memory management of the graphics stack, rendering of primitives, font rendering, and a few other things involved in the process of “getting pixels onto your screen” have changed, and they’ve changed for the better. With a stack based on Wayland (and in extension Qt5), we are able to utilise modern graphics hardware better, to reduce maintainance effort and hopefully grow the community around the graphics stack, and not at least, to make sure that every frame that ends up on the screen is perfect. In the X11 world, we can’t really control it, since we have no idea when something is painted, in which way it is, where it’s painted, and when the pixels end up on the screen. With Wayland, this process of event processing, rendering and blitting is structured and guaranteed to happen in a certain order. In the end, this transition will enable us to put 60 perfect frames every second on the screen. The new architecture also allows us to split the rendering into its own thread, so data processing or event handling in the application doesn’t end up delaying rendering. 60 frames per second will make the UI feel smooth as buttery silk, leading to less strain on the eyes and a nicer user experience.
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.
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.
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.
KDE’s Next Generation user interfaces will run on top of Qt5, on Linux, they will run atop Wayland or Xorg as display server. The user interfaces move away from widget-based X11 rendering to OpenGL. Monolithic libraries are being split up, interdependencies removed and portability and dependencies cut by stronger modularization.
For users, this means higher quality graphics, more organic user interfaces and availability of applications on a wider range of devices.
Developers will find an extensive archive of high-quality, libraries and solutions on top of Qt. Complex problems and a high-level of integration between apps and the workspace allow easy creation of portable, high-quality applications.
The projects to achieve this goal are KDE Frameworks 5 and Plasma 2. In this article, you’ll learn about the reasons for this migration and the status of the individual steps to be taken.
As this article is going to be a bit long, due to its level of detail, you can just skip to the end of every subsection to get the executive summary. Also, I would like to thank Blue Systems for their sponsoring of a lot of the work that is going into the future of KDE’s products, among which, mine.
Status Frameworks 5
Development of KDE’s Frameworks5, which focuses on modularization of APIs currently contained in kdelibs and kde-runtime, loosening its internal structure and making it possible to only use specific parts by splitting it into individual libraries and solutions.
The entire work to be done for Frameworks 5.0 is split into 7 topics. Three of these “Epics” are done:
Initial communication and documentation (Kevin Ottens),
Merging of code into Qt 5.0 (David Faure)
Reduction of duplication with Qt by removing classes and using their Qt alternatives (Stephen Kelly)
Four Epics are currently work in progress, three of them are monstrous:
Build system (Alex Neundorf, Stephen Kelly)
CMake (upstreaming some stuff, modularization, porting)
Modularization of CMake KDE settings (work in progress)
Modularization of macros
Review and inventarize Find* CMake modules
kdelibs cleanups (David Faure)
This is a large Epic, containing many bite-sized tasks. Roughly 50% of them are done, 37 tasks remain open and 7 are being worked on, an extensive list is on the wiki.
Qt 5.1 merging (David Faure)
This is the list of things that we haven’t been able to merge upstream into Qt 5.0, so we hope we can upstream as much as possible into Qt 5.1. This can potentially cause timing problems, if we can’t get all the necessary things we need into Qt 5.1. 9 tasks are work in progress by David Faure, Thiago Maciera, Richard Moore and others. 52 tasks are on the todo list, most of them currently unclaimed.
Splitting kdelibs (blocked) (Kevin Ottens)
Another large Epic, in bigger chunks, meaning going through all libraries one by one, porting their build system to the changes in Frameworks5, cut out certain library dependencies and changing the translation system. 13 tasks are done, 12 work in progress and 8 on the todo list, not all of them assigned.
An extensive list of libraries and their status can be found on the wiki.
Frameworks 5 currently compiles on top of Qt 5.0 and basic system services run (kdeinit5), although not all of its dependencies have been ported to Qt 5. Work on Frameworks5 is ongoing, so it is currently quite a moving target, and will remain so for a while.
Plasma and KWin Direction
An architecture based on Qt5 and Wayland makes it possible to use a more modern graphics stack, which means moving from X11-based rendering to OpenGL graphics rendering. QtQuick2 (which is the QtQuick shipped with Qt5) makes it possible to offer a very nice and extensible development API, while using the full power of the graphics hardware to produce excellent visual possibilites. Plasma offers development APIs that make it easy to create well-integrated applications as well as workspaces that are flexible, extensible and fully featured on top of QtQuick, and in the future QtQuick2.
As KDE moves forward towards Frameworks5, Plasma is taking the opportunity of the source and binary compatibility break of Qt5 to do necessary updates to its architecture. The goal is to have a leaner Plasma Development API and depdendency chain and achieve a better user- and developer experience by moving the UI fully to Plasma Quick, which is QtQuick plus a number of integration components for theming, compositor interaction, internationalization, data access and sharing, configuration, hardware, etc..
This constitutes a major refactoring of the Plasma libraries and components. First, their UI needs to be done in QML. This effort of porting workspace components to QML is already well underway. Second, the Plasma library and runtime components need to be ported from the QGraphicsView-based canvas to QML. This means cutting out dependencies on classes such as QGraphicsItem and QGraphicsWidget to their equivalent in QML. In the case of painting and layouting code, it means porting this code to QML.
Plasma Components (containing a basic QtQuick widget set)
QtExtras (containing components missing in Qt, such as MouseEventListener)
PlasmaExtras (containing additional UI widgets for better integration, such as animations, text layout helpers, Share-like-connect integration, etc.)
Making scriptengines (such as the Python scriptengine) only export QObject-deriven classes to the QML runtime (needs investigation right now)
Port of widgets away from QGraphics*, also necessary for some QML code
Plans for KWin Plasma Compositor
Plasma Compositor refers, in a Wayland world, to the compositor used for Plasma workspaces, which is essentially KWin in disguise as Wayland compositor.
In KWin, we benefit from an ongoing effort to modularize and clean it up architecturally. For most of its UI, KWin already supports QML (Window decorations, tabswitcher, etc.). Some mechanisms which currenty work through XAtoms will need to be ported, the API impact of that will likely be quite limited for application developers.
The strategy for KWin is to port KWin to Qt 5, then make it possible to run KWin outside of an X server on top of KMS, using the graphics hardware more directly. The next step is to use KWin as compositor for Wayland display servers. The dependency of X11 can be removed once it is not needed anymore to provide compatibility with X11 applications, or can possibly be made optional.
Milestones for KWin (Martin Graesslin) (updated with further clarifications, thanks Martin):
KWin on Qt5 (work in progress, planned for 4.11): KWin will not depend on Qt 5 as of 4.11. The idea is to have KWin in a state that we could compile KWin with Qt 5/KF 5. But as it is unlikely that KF 5 will be allowed dependency for 4.11, we will not see a KWin on top of Qt 5 even if we achieve that goal. It’s a weak goal as we cannot release on it anyway.
on top of KMS (planned for 4.11): KWin in 4.11 will still run on top of the X-Server. This is mostly about adding a proof-of-concept. Whether that will be merged into 4.11 and compilation enabled will be seen once the code has been written. So in this case it will at most be an additional very hidden (env variable) mode for testing.
KWin as Wayland compositor (planned for 4.12): Again only as addition. As of 4.12 we will still be targetting X-Server as default. If we succeed we might add an option. But this pretty much depends on the state of Qt 5/KF 5 and QtCompositor. If any of those dependencies is not ready to depend on, the code might exist, but will not be released.
no X11 dependency (planned for the distant future): There are no plans to drop X11 support. But we want to have the possibility to build a KWin without X for new targets like Plasma Active. For the desktop there are no such plans.
Plasma Workspaces
The porting strategy of the workspaces is to port plasmoids and containments to QML, in order to make them ready to run on top of the new infrastructure. In the case of C++ and Python, Ruby, JavaScript and “Web API” applets, it means rewriting them in QML. For portability and maintainability reasons, pure QML widgets are preferred. For some complex use cases, that can not be easily done in QML, we ship a combined C++ QML applet. For Plasma2, the only way to do the UI is using QML. QGraphicsWidget based Uis will not be supported anymore.
Once we have a working libplasma2 and a useful set of QML Plasmoids, we can think of running an entire workspace in QML and on top of QtQuick2, either on top of X11, or with KWin’s plans in mind, on Wayland.
Porting status of important widgets to QML / Plasma Quick needed for the workspace:
Taskbar (close to first review, target: 4.11) (Eike Hein)
Folderview (work in progress) (Ignat Semenov)
Desktop containment (second revision close to review, target: 4.11) (Sebastian Kügler)
Calendar (work in progress, target: 4.11) (Davide Bettio, Sebastian Kügler)
Kickoff (about to be merged into master, target: 4.11)
KRunner (work in progress, target: 4.11) Aaron Seigo, Aleix Pol
Done: System tray, pager, notifications, device notifier, battery, lock/logout, weather, Wallpaper, Containment support
Open:
Digital Clock
Icon
Picture Frame
others from kdeplasma-addons
and more (see wiki)
Conclusion
KDE’s Framework 5 project is well underway. It will allow us to move to a more modern graphics rendering engine, make our development platform more portable, and make it easier to reuse solutions KDE has built. The work does not happen by itself, however, yet it is time-critical. With Qt5.0 being released, 3rd parties are porting their code already. These people will only consider using KDE’s technologies if they are actually available — and that means we need a Frameworks 5 release.
So is this going to be KDE 5? The answer to this question is still “No!”, for a number of reasons:
Frameworks 5, apps and the Plasma workspaces are not one singular entity. These parts are only released together (which might change in the future), and cobbling them up under one name really is really not helpful. (3rd party developers will think we’re only targeting Plasma workspaces, Plasma users will think you’ll only be able to run “KDE apps”, potential users of applications will assume that you can only use them inside Plasma workspaces — all of them untrue, all of them taken right out of my daily experience)
Within the Plasma team, we tend to use the abbreviation PW2 to refer to the next generation of Plasma workspaces. It stands for Plasma Workspaces 2, and it will probably be named differently in the future.
So, now you’re fully up to date on the status, isn’t it time to get cracking?
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.
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.
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!
The discussion around including online search results in the workspace, and especially in the app starter, reminded me of a discussion we had some time ago about including online search in KRunner queries. First of all, I think the idea of including online search results directly in the shell is great. It’s not new by any means, but it serves value to the user, and in fact, I use it daily and would not want to miss it.
In KDE Plasma, we do that for a few years already. I recall sitting down during the Gran Canaria Desktop Summit in 2009 with Richard Moore and hacking on a KRunner plugin that includes results from Wikipedia and Wikitravel in the KRunner search results. We got that working pretty quickly, and the plugin is shipped on most installations of Plasma Desktop out in the wild nowadays, and nobody complained. How come?
Privacy by Default
First of all, we do it quite differently from the way Canonical does it in Ubuntu. Sending every search query to an online service forms a privacy problem. Especially when not using SSL encrypted HTTP requests, people around you can basically wiretap your traffic almost trivially, or intercept it using man-in-the-middle-attacks. Also, the service receives all your queries as well, not something I’d want in general. Even if I trust someone in principle doesn’t mean I have to tell them everything I do.
While we ship plugins that promote Free culture (in this case Wikipedia and Wikitravel), one could easily add support for Amazon as well, and of course for all kinds of search engines. (We do include a couple of proprietary web services in KDE, but we’d never silently send them data when it’s not clear to the user or explicitely asked for) What we, as Plasma maintainers will not accept however, is triggering these online requests on every query typed. Basically, we won’t send anything across the net without the user explicitely requesting us to do so.
Maybe we could raise some funds this way, but we think that our users are best served with a system that gets advertisement out of the way. I’m personally easily annoyed by commercial offerings which jump into my face without me asking for it, and I understand I’m not the only one.
Earning Money through affiliate programmes
A few months ago, David Faure, the maintainer of Konqueror, KIO and a lot of other important pieces in KDE got contactetd by the DuckDuckGo search engine. DuckDuckGo asked if KDE would be willing to take part in their affiliate programme. David passed this on to KDE e.V. and offered to do the necessary changes on the code side if we decide to go ahead with this. DDG offered us to receive 25% of their earnings per clicked ad when the user searched through Konqueror (or in fact through the webshortcut). As we have already been shipping a search provider for DuckDuckGo for quite some time, it was enough to add KDE to the search query and sign a form with KDE e.V.’s banking details. That’s some free money, maybe not much, but who knows and every bit helps. The impact technically and to the user is minimal, and it didn’t require any changes to our privacy principles and setting, so ahead we went. That means, if you feel like supporting KDE through your online search, that’s easy: Use the ddg: search provider (see below). This works starting with 4.9.0.
Online, but respecting privacy
So, offline and private by default, but how can we still include all the goodness from the Internet in your local search results, so we save you a trip to your webbrowser when we can? There are a few ways you can easily query online services from your desktop:
Wikipedia, Wikitravel (and other MediaWiki-based services): ALT+F2, enter “wiki $YOURQUERY”
Videos on Youtube: ALT+F2, enter “videos $YOURQUERY”
Google search: ALT+F2, enter “gg:$YOURQUERY” (use ggi: for google images, dd: for DuckDuckGo, amz: for Amazon, qt: for Qt API documentation, php: for PHP docs, many, many more are available as well, have a look at Konqueror’s webshortcuts for a full list, all of those are transparantly supported in KRunner as well)
Starting this weekend, KDE e.V. the organisation supporting the KDE community organizes a number of meetings in Randa, Switzerland. Randa is a village in the Swiss Alps. It’s a bit of a remote location between mountains which reach up to 4500m, provides the perfect location to sit down together and do nothing but concentrate on a single topic. You can help us to make this happen, but first, read on to understand what we will be doing in Randa, and why.
From Platform to Frameworks
One of the meetings planned there is the meeting of the KDE Plasma team. The goal of this meeting is to plan and make progress on the port of libplasma, the framework that is underlying the Plasma workspaces to Qt 5 and KDE Frameworks 5.
Within the KDE Frameworks 5 effort, the KDE team splits up and reorganizes the whole KDE platform. This effort has been started during last year’s meeting in Randa, and while being a huge effort, we have already made good progress across many of the libraries and technologies that make up KDE Frameworks. KDE Frameworks 5 will be mostly source-compatible, meaning that no large rewrites will be needed in order to port an app to Frameworks 5, much rather, we’re splitting dependencies differently across the board to make it easier to reuse only certain frameworks, without having to drag in larger dependency chains. The Frameworks 5 effort goes along with porting of the codebase to Qt5 (which is also much more painless than the port from Qt3 to Qt4). The result will be a faster, more modular, and hopefully due to these new virtues more widespread use of KDE technology.
The road to Plasma-Next
One of the technologies in Frameworks 5 is libplasma2. For libplasma2, there is still a lot of work to happen. While we have a rough plan what we want to achieve, and already taken the first steps to make this happen, there’s still a huge mountain of work ahead of us to create a new libplasma2 that is worthy its place in Frameworks 5. One of the high-level goals is to be able to run Plasma workspaces (and apps) in an entirely hardware-accelerated environment. In Qt5 terms, this means we want to use QtQuick 2 to display our user interfaces using an OpenGL scenegraph. As that is quite a deviation from the current, QPainter-based approach, you can imagine that it won’t be easy to get this “just right”, and in any case, it involves touching and testing a lot of code that works well right now. Also for Plasma Addons, we want to achieve almost source compatibility, so all the work that has gone into Plasma in KDE SC 4 will be immediately available in the new world order of Qt5. Not an easy task, and there are a few areas where we don’t have satisfactory solutions yet. A lot of sweat and braincycles will be needed.
The good news is that we have a capable and motivated team to tackle this effort, and to really kick off our libplasma2 hacking spree, we will sit down in Randa and plan all this through in detail, then sit down and get hacking so we have hopefully reached a critical mass to continue on, and a clear and shared vision across the team how we want to go about the remaining work.
How you can help…
Free Software is a joint effort, and everybody can pitch in. In order to get travel costs funded for this event in the Swiss Alps, we have started a fundraiser campaign. The goal is to raise 10.000€, and we’ve already made good progress towards this goal. You can help reaching it, making the sprint in Randa possible and contribute to the future of the software you might (or might not yet!) be running!
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!
Plasma Active brings a flexible, elegant, activity-driven user experience to a spectrum of devices. This article is part of a series of articles about different perspectives on Plasma Active. This installment looks at the user story, and aims at answering the questions “How do we get developers interested in Plasma Active?”.As I’m quite a bit behind on my series of perspectives on Plasma Active, so let’s try to catch up a bit. I’m trying bit of an experiment Marco and I talked about last night: Using personas not only for user stories, but also for our developer story.
Chad – The Casual Developer
Chad is a 23 year old developer. Chad has basic (but much to his regret not highly advanced) programming skills. In order to manage complexity, he mostly works in JavaScript. Concepts like cross-compiling code, packaging and deployment are alien to him, ideally he can avoid them entirely. Chad’s main interest is to transfer cool ideas for apps he has into reality. Chad does this work next to his studies, as Freelancer.
Chad’s IDE of choice is Plasmate, a simple IDE entirely geared towards creating Plasma addons. Plasmate guides the user to the whole workflow: creating a new app template, coding the app, testing it and deploying it to one or more target devices, and publishing it using online services. By providing these features all in a single tool that is small and easy to install, we maximize Chad’s gain for the brain he put into the code. While Plasmate is (purposefully limited to “pure scripted” Plasma components (such as Plasmoids, apps) it takes away most of the system learning and allows to fully concentrate on the creative process. Resulting applications are platform indepdenent and can easily be installed on test devices, directly from Plasmate. Complexity of the process is reduced as much as possible. The powerful KDE Frameworks allow to include advanced functionality in Chad’s creation, resulting in rich and visually appealing apps.
Lwing – The seasoned app developer
Lwing is a seasoned C++ developer. She has been working on various mobile and embedded platforms, as well as desktop applications. Lwing would like to bring SqueezeIt! one of her own desktop apps to a wider range of devices. For that, she chose Plasma as being the only truely Free and open system in the world. (Yep, shameless, shameless plug :).
Lwing’s way to success involves a bit more complexity. The recommended way is using the Mer SDK and Open Build Service (OBS) to cross-compile her code and get it deployed to devices. The Mer SDK is quite easy to set up and provides a build environment that produces reproducable results and takes away a lot of the complexity (and therefore pain) from the process of deploying an existing app to a new system. Combined with tools such as KDevelop or Qt Creator and supported by lots of excellent documentation, for Lwing, sky is the limit. Lwing thusly refactors SqueezeIt! to strongly separate data, busines logic and presentation. She designs her UI so it scales to different screen sizes, and implements it using Plasma Quick (Qt Quick plus Plasma QML Components). Libraries and development packages Lwing needs are already pre-installed in the SDK, so she doesn’t have to worry about that, other than updating the SDK once in a while from withing using the zypper package management tool. For usability and design questions, Lwing consults the human interface guidelines, which make it easier for developers to create applications that feel like they belong and are consistent with existing components. When she’s happy, she offers the app through her OBS project, and uploads a premium version with a few more advanced feature for a little money in the Make*Play*Live Addon Store.
Brian – The passionate and talented Hacker
Brian is a talented C++ developer with special passion for gadgets and Free software. He has heard of Plasma Active through a friend, and after hacking a bit on addons, he wants to join the team creating this system. Briann pops up in the #plasma IRC channel on Freenode, explaining his intention and skill level. A friendly developer quickly explains Brian how to get started, pointing him to documentation how to get the development environment set up, API documentation and the team’s current plans, vision and of cource the long list of open tasks. Brian, much like Lwing sets up the environment, plays around with it a bit, changes a few things in the shell in order to get a feeling for the whole thing and starts on some easier bugs. After a few days, Brian is up to speed and starts to send patches to the Plasma team through reviewboard. Fast forward a few months, Brian has shown that he understands the code base, the processes to keep it sane and the team’s vision. He applies for an Git account to be able to take on more responsibilty, helps reviewing patches of other contributors, contributes new ideas and becomes more and more part of the team.
You’ll notice that Brian’s and Lwing’s use cases do not actually differ much technically, but mostly socially and in the sense of community dynamics. This is actually quite convenient, since it reduces maintainance and work overhead: Less development tools to create, maintain, document. Chad’s use case concentrates on lowering the threshold for people to get involved. With the Plasma Quick platform becoming more and more powerful, Chad is able to create a wide range of apps.
In this post, I’ll try to provide an overview of the results of the work we’ve done during the Workspace sprint in Pineda de Mar, Catalunya, Spain. The sprint is still going on, unfortunately I had to leave early to attend a friend’s wedding. Before going into any details, a few thank yous and credits are in place: Aleix Pol and Alex Fiestas for being excellent hosts organising this sprint (including picking this terrific location which allowed us to concentrate 100% on our processes and 0% on the beach), KDE Spain for sponsoring our food, the KDE e.V. (and its donators!) for sponsoring travel expenses and providing organisational backing, Kevin Ottens who took a sizable slice of time out of his vacation account in order to facilitate meetings, enabling group dynamical processes and generally being a good moderator, Björn Balasz for chipping in time and providing his background in psychology and usability and of course open-slx, my awesome employer.
Activities central: One focus that we have been working on in Plasma quite extensively is organising your documents, contacts, applications, files and other digital assets into Activities. Activities provide a contextual way of organising your devices. Activities usually enclose these resources into personal context which might include locations, contacts, documents and any other resource we’re able to express in terms of semantics. (So pretty much all. :)) We’ve identified areas where we can improve the activities workflow. Switching between Activities and getting an overview can surely be improved. There have already been some ideas floating around, and some smaller and larger improvements are in the pipeline to see the light of day in one of our future releases. In some parts, we’re transplanting features we have matured in the Plasma Active user experience into the desktop. The Plasma Way: Share code across devices, investigate workflows across apps and device borders. (So a workflow which we want to enable may actually involve using more than one device — we want to make especially these patterns a lot easier, intuitive and fun to use. There’s a few real challenges in there, although many parts involve someone “just sitting down and doing it”.
Personas: I’ve dedicated a separate blog entry to Carla and Raj, our brand new personas, so I’ll kindly refer you to that.
Social networks and messaging: Carla’s and Raj’s lives involve talking to people across different channels. We want to enable these patterns by providing deep integration of messaging and social networks into the desktop. While we likely will not ever support every single feature of all social networks, we definitely want things like native notifications for messages, and being able to keep tabs on the going ons around you. Technologies we’ve been working on in the part years and which are coming to mature now will be a great help in creating a nice user experience here: Akonadi, Telepathy being at the forefront of double-plus-useful frameworks here.
Along with the integration of more social services into the workspace, we also want to enable cross-device workflows using online services. Examples for getting your data across devices are ownCloud, but also commercial services like FlickR. I think we are in the position to put Free software solutions first, but not excluding proprietary services, but enabling Carla and Raj to mix and mesh whatever they uses. In this, we need to pick up the user where he or she is now. We’re not going to switch users to Free software users if we require social disruption in their lives. :)
Something I found particularly exciting was the call by a few participants to reinvigorate Project Silk. The idea is to make the web, web apps, -applications and -services first class citizens in the desktop. This can range from the introduction of a site-specific browser to deeper integration of online content and services: think of FlickR integration in Gwenview, caching data from online sources, providing native UIs for services that are otherwise a bit cumbersome to use, and much, much more. I’m surely hoping we’ll see a surge of improvements in this area. I’m also happy that Richard and I documented our ideas quite well when we came up with them in 2009 at the Desktop Summit in Gran Canaria (coincidentally also Spain, at least technically ;-)).
There’s almost too much exciting new ideas that it’s hard to report about all of it without choking your feedreaders or webbrowsers, so I’ll just mention a few more telegramme-style. Feel free to ask in the comments if you have specific questions, or just head over to the plasma-devel@kde.org mailinglist where you can discuss with the whole team involved.
As base for identifying needed improvements, we will concentrate our thinking on which workflows we can enable for users. This first line of identification will be thought about without a specific device in mind. Much more so, workflow can and often do include different devices. We want this to be at the heart of our designs.
Virtual desktop will remain what they are, orthogonal to the principle of Activities, We do not plan any sweeping changes here, in order not to break engrained workflows. Nepomuk synchronisation across devices is still a very challenging problem. It needs more design and research work to define an achievable scope.
We’ve proposed a few changes to KDE’s release rythms, basically decoupling the releases of workspaces, applications and (in the future) KDE Frameworks. This is basically a continuation of KDE’s effort to implement branding closer aligned to how we work and what we produce; currently under discussion.
Notifications will likely receive a rework in order to make them more activity aware, and to display insensitive information on a lock screen, just to name two examples.
Everybody agreed that stability and quality are key for users. We will avoid disruptive changes, but concentrate on making existing tools better, and new features not get in the way of existing workflows. A few changes in our processes have also been planned,
Clemens of Blue Systems attends the sprint as well, it’s good to see new faces participating and supporting KDE. We’ve had very interesting conversations about all kinds of topics.
Maybe the most important thing was the sharing of the Plasma vision with a wider team of contributors. It strikes that Plasma lately has been moving so incredibly fast that we built up a backlog of communication, some of which we managed to knock down in the past days, but it surely will take some time until all ideas, concepts and processes are ingrained into everybody’s brains. The first steps for this have been taken, however.
As you can see, that’s a lot of stuff we have carved in sand in the past days. It will need refinement, and consolidation, more design, ungodly amounts of hacking and surely won’t all be implemented in a whim. It does however give everyone a good idea where we’re going, and what the steps into that direction are. Exciting times ahead. If you’re looking for more sprint results, I’d also read Marco’s blog about it.
Saying good bye was relatively easy this time around, as most people attending the sprint will also be at Akademy, which starts in two weeks in Talinn, Estland. The next Plasma sprint is planned in September in Switzerland. The plan is to mostly work on libplasma2, QtQuick2 and Frameworks 5 in order to technically pave the way into the future of the Linux workspaces.
The 
While we ship plugins that promote Free culture (in this case Wikipedia and Wikitravel), one could easily add support for Amazon as well, and of course for all kinds of search engines. (We do include a couple of proprietary web services in KDE, but we’d never silently send them data when it’s not clear to the user or explicitely asked for) What we, as Plasma maintainers will not accept however, is triggering these online requests on every query typed. Basically, we won’t send anything across the net without the user explicitely requesting us to do so. 
Within the KDE Frameworks 5 effort, the KDE team splits up and reorganizes the whole KDE platform. This effort has been started during last year’s meeting in Randa, and while being a huge effort, we have already made good progress across many of the libraries and technologies that make up KDE Frameworks. KDE Frameworks 5 will be mostly source-compatible, meaning that no large rewrites will be needed in order to port an app to Frameworks 5, much rather, we’re splitting dependencies differently across the board to make it easier to reuse only certain frameworks, without having to drag in larger dependency chains. The Frameworks 5 effort goes along with porting of the codebase to Qt5 (which is also much more painless than the port from Qt3 to Qt4). The result will be a faster, more modular, and hopefully due to these new virtues more widespread use of KDE technology.
The good news is that we have a capable and motivated team to tackle this effort, and to really kick off our libplasma2 hacking spree, we will sit down in Randa and plan all this through in detail, then sit down and get hacking so we have hopefully reached a critical mass to continue on, and a clear and shared vision across the team how we want to go about the remaining work.
