Plasma Meeting: Web, browsers and app bundles

This year’s Plasma Sprint is kindly being hosted by von Affenfels, a software company in Stuttgart, Germany, focusing on mobile apps. Let me try to give you an idea of what we’re working on this week.

Bundled apps

Welcome, KDE hackers!
Welcome, KDE hackers!
One problem we’re facing in KDE is that for Linux, our most important target platform, we depend on Linux distributors to ship our apps and updates for it. This is problematic on the distro side, since the work on packaging has to be duplicated by many different people, but it’s also a problem for application developers, since it may take weeks, months or until forever until an update becomes available for users. This is a serious problem and puts us far, far behind for example deployment cycles for webapps.

Bundled app technologies such as flatpak, appimage and snap solve this problem by allowing us to create one of these packages and deploy them across a wide range of distributions. That means that we could go as far as shipping apps ourselves and cutting out the distros as middle men. This has a bunch of advantages:

  • Releases and fixes can reach the user much quicker as we don’t have to wait for distros with their own cycles, policies and resources to pick up our updates
  • Users can easily get the lastest version of the software they need, without being bound to what the distro ships
  • Packaging and testing effort is vastly reduced as it has to only be done once, and not for every distro out there
  • Distros with less man-power, who may not be able to package and offer a lot of software can make available many more appliations,…
  • …and at the same time concentrate their efforts on the core of their OS

From a Plasma point of view, we want to concentrate on a single technology, and not three of them. My personal favorite is flatpak, as it is technologically the most advanced, it doesn’t rely on a proprietary and centralized server component. Unless Canonical changes the way they control snaps, flatpak should be the technology KDE concentrates on. This hasn’t been formally decided however, and the jury is still out. I think it’s important to realize that KDE isn’t served by adopting a technology for a process as important as software distribution that could be switched off by a single company. This would pose an unacceptable risk, and it would send the wrong signal to the rest of the Free software community.

How would this look like to the user? I can imagine KDE to ship applications directly. We already build our code on pretty much every commit, we are actually the best candidate to know how to build it properly. We’d integrate this seamlessly in Discover through the KDE store, and users should be able to install our applications very easily, perhaps similarly to openSUSE’s one click install, but based on appstream metadata.

Website work

Hackers hacking.
Hackers hacking.

We started off the meeting by going over and categorizing topics and then dove straight into the first topic: Communication and Design. There’s a new website for Plasma (and the whole of KDE) coming, thanks to the tireless work of Ken Vermette. We went over most of his recent work to review and suggest fixes, but also to get a bit excited about this new public face of Plasma. The website is part of a bigger problem: In KDE, we’re doing lots of excellent work, but we fail to communicate it properly, regularly and in ways and media that reach our target audience. In fact, we haven’t even clearly defined the target audience. This is something we want to tackle in the near future as well, so stay tuned.

But also webbrowsers….

KDE Plasma in 2017
KDE Plasma in 2017

Kai Uwe demo’ed his work on better integration of browsers: Native notifications instead of the out-of-place notifications created by the browser, controls for media player integration between Plasma and the browser (so your album artwork gets shown in the panel’s media controller), acccess to tabs, closing all incognito tabs from Plasma, including individual browser and a few more cool features. Plasma already has most of this functionality, so the bigger part of this has to be in the browser. Kai has implemented the browser side of things as an extension for Chromium (that’s what he uses, Firefox support is also planned), and we’re discussing how we can bring this extension to the attention of the users, possibly preinstalling it so you get the improvements in browser integration without having to spend a thought on it.

On and on…

We only just started our sprint, and there are many more things we’re working on and discussing. The above is my account of some things we discussed so far, but I’m planning to keep you posted.

LTS releases align neatly for Plasma 5.8

Our upcoming release, Plasma 5.8 will be the first long-term supported (LTS) release of the Plasma 5 series. One great thing of this release is that it aligns support time-frames across the whole stack from the desktop through Qt and underlying operating systems. This makes Plasma 5.8 very attractive for users need to that rely on the stability of their computers.

Qt, Frameworks & Plasma

In the middle layer of the software stack, i.e. Qt, KDE Frameworks and Plasma, the support time-frames and conditions roughly look like this:

Qt 5.6

Qt 5.6 has been released in March as the first LTS release in the Qt 5 series. It comes with a 3-year long-term support guarantee, meaning it will receive patch releases providing bug fixes and security updates.

Frameworks 5.26

In tune with Plasma, during the recent Akademy we have decided to make KDE Frameworks, the libraries that underlie Plasma and many KDE applications 18 months of security support and fixes for major bugs, for example crashes. These updates will be shipped as needed for single frameworks and also appear as tags in the git repositories.

Plasma 5.8

The core of our long-term support promise is that Plasma 5.8 will receive at least 18 months of bugfix and security support from upstream KDE. Patch releases with bugfix, security and translation updates will be shipped in fibonacci rhythm.
To make this LTS extra reliable, we’ve concentrated the (still ongoing) development cycle for Plasma 5.8 on stability, bugfixes, performance improvements and overall polish. We want this to shine.
There’s one caveat, however: Wayland support excluded from long-term-support promises, as it is too experimental. X11 as display server is fully supported, of course.

Neon and Distros

You can enjoy these LTS releases from the source through a Neon flavor that ships an updated LTS stack based on Ubuntu’s 16.04 LTS version. openSuse Leap, which focuses on stability and continuity also ships Plasma 5.8, making it a perfect match.
The Plasma team encourages other distros to do the same.

Post LTS

After the 5.8 release, and during its support cycle, KDE will continue to release feature updates for Plasma which are supported through the next development cycle as usual.
Lars Knoll’s Qt roadmap talk (skip to 29:25 if you’re impatient and want to miss an otherwise exciting talk) proposes another Qt LTS release around 2018, which may serve as a base for future planning in the same direction.

It definitely makes a lot of sense to align support time-frames for releases vertically across the stack. This makes support for distributions considerably easier, creates a clearer base for planning for users (both private and institutional) and effectively leads to less headaches in daily life.

Tokamak 6 Kicking Off: Why switch graphics stacks?

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.

Plasma Active Balsam Updates Available

I’ve compiled an update to the Balsam Professional Plasma Active packages in the last weeks, they are now are available for your upgrading pleasure. While the packages work very well in my testing, they are still only development snapshots, so if you’re happy with your current Plasma Active, and you need to be absolutely sure everything keeps working, I’d advise not to upgrade. In all other cases, you’re in for a good performance kick, a lot of bugfixes and a few new, but important features.Instead of boring you, my dear audience, with a long piece of text, I got out my webcam and recorded a screencast of these packages running on my viewtab (an Atom-based 10 inch tablet). Lay back and watch.

Watch on YouTube

In the screencast, I’m showing the general workspace UI, as well as a few new apps and features, file browsing, microblogging, news reading workflows, which we’ve been improving lately.

The packages work fine on wetab and exopc tablets, and most likely also on other Intel-based tablets. Builds for various ARM flavours are available throught the Mer project. As Balsam Professional 12.1 is compatible to openSUSE, they will also work there. If you want to install the packages in your desktop, be advised that this might mess with your desktop sessions, so that’s essentially at your own risk.

The Balsam Packages are made available by open-slx and built and served from our Open Build Service.

Plasma Active on OpenGL ES

The past weeks, I’ve been working on getting Kwin, the window manager and compositor in Plasma Active (and Plasma Desktop ;) to work on top of OpenGL ES instead of OpenGL. After some updating of packages lower in the stack, especially Mesa and parts of Xorg, we now have working OpenGL ES support on our hardware. Today, I’ve finished packaging it as an option on top of our Plasma Active packages. These packages in the :Devel subsection of the KDE:Active repository in the OBS run on top of Balsam Professional and openSUSE 11.4. We will give this some more testing and improve a few things, in order to move to GLES by default. OpenGL ES is very interesting as this is an API often used on mobile devices, so I’m glad that I can state that we’re ready for this. This of course needs proper support in the drivers, something we can not always solve by ourselves. I have been running this successfully on two Intel Atom-based tablets.

Contour showing the Froscon activity

All the props of course to to our Akademy-award winning window management and compositing hero, the one and only Martin Grässlin. He’s been working on OpenGL ES support (and a lot of other features to make kwin “ready for the future”) for quite some time already. OpenGL ES support in kwin has been introduced in the recent Plasma Desktop 4.7 release, a few weeks ago.

So, is it much different? Nope, it’s very much a thing of underlying technology. There’s no noticable performance improvement, but it runs stable and well. Given that OpenGL ES support has only very recently been introduced in kwin, it’s already surprisingly good. There is probably still a lot of room for improvement, which is something we can investigate now and easily test much better.

Froscon

In the screenshot of the Contour shell of Plasma Active, you can see that I’m all set up to go to FrOSCon tomorrow, where I’ll be presenting the ideas and demoing the prototypes, hoping to get some feedback on concepts, and give some understanding of the challenges and opportunities we face in this exciting endeavour. And of course show some serious bling. :) If you’re in the area around Bonn, drop by.

KDE:Active:Devel introduced

The past week, when working on the Mesa packages for Plasma Active, I might have caused some headache since I broke the compositor in Plasma Active with a few packages I uploaded for easier deployment on test devices. It was not more than an annoyance, because kwin gracefully falls back to non-composited mode in case of graphics problems. In order to get a bit more stability into our deployment process, I’ve now set up a subproject called KDE:Active:Devel under the KDE:Active project on the Open Build Service (OBS) which we use to build the Balsam packages. As we’re moving, development-wise into the stabilization phase for Plasma Active One, this makes testing new things a lot easier, just by switching to the same package from the :Devel branch. Conversely, this means that if you install packages from the :Devel subproject, you should really know what you’re doing. On the bright side, it’ll be easier to keep regressions out of the packages that are deployed on most users’ machines. Contour showing the Froscon activity

Along with these changes, I’ve updated all the packages to the latest state of the art, and worked a bit on our documentation, as we keep getting very good feedback about this. Among the most wanted fixes we’ve introduced is a patch by Aaron that makes konsole usable with the virtual keyboard, making another very powerful tool usable on Plasma Active. I’ve also fixed up some default configuration options, polished up the contour packages and made that used by default. (Those who have plasma-tablet-config on their machine will have to replace it with “plasma-contour-config”, though.) This is another pretty big move, as we now basically regard the contour shell stable enough to make it into Plasma Active One. It’s also very, very shiny I must say, the usual disclaimer about alpha software notwithstanding.

OBS makes it rather convenient merging changes back and forth between these branches. In general, my impression is that OBS works very nicely as a collaboration tool, and solves a very complex problem for us, the “how do we get our code onto the device”. As an aside, it also makes it very easy to build packages locally, so for even shorter development-deployment cycles, one can build locally and rsync packages onto the device. With the right kind of script setup, that takes a lot of the pain away, that development for mobile devices often brings with it. The KDE:Active:Devel repo can be used directly by developers to upload their latest sources in order to deploy them to their testing machines, and we can pull working versions in from there. Rocking.

Installing Plasma Active on the ExoPC (“WeTab”)

If you own an ExoPC, and you’re eager to know how to get Plasma Active, our new workspace and set of applications for consumer devices to run on it, this blog article will help you get going.

Note: Plasma Active is in alpha state right now, it is basically usable, but you will find many rough edges. You should not try this unless you consider yourself an early adopter, or if you mind fiddling with bits and pieces. We are working towards an end-user ready product, but we’re not yet there.

Plasma Active

What to pick?

There are a few different options to choose from, I’ll quickly explain which to choose under which circumstances.

  • MeeGo: Works well overall, but is lacking in key areas, for example we do not have a UI to connect to wireless networks yet, and as the device doesn’t have Ethernet (and cables are lame on mobile devices anyway). You can work around this with a trick Marco explains.
    Choose this option if you want to run and develop for MeeGo
  • Balsam Professional: Download the Balsam Professional live images from open-slx. This live image provides a fully functional live system without too much hassle.
    Choose this option if you want to try Plasma Active
  • openSUSE: Install Plasma Active on top of openSUSE 11.4, it uses the Active packages created by open-slx (me, my employer), but is a bit more laborious to install.
    Choose this option if you want to run the full experience on your ExoPC, or track progress and hack on Plasma Active

I will explain here how you can get to a state-of-the-art Plasma Active, using what will eventually become the Tablet Edition of Balsam Professional. Balsam Professional is, unlike openSUSE, focused on end-users and the user experience on consumer-level devices. Balsam Professional is based on openSUSE, so you might well be familiar with many of the tools already.

What you need

  • An ExoPC, or a WeTab
  • An empty USB stick of at least 700MB
  • A USB keyboard and possibly a mouse

Note that the installation is possible to do by keyboard only, but a bit more comfortable if you have a mouse available. As the ExoPC does only have two USB ports, one of which will be occupied by the installation medium for the first part of the setup, you either need a USB hub, or a combined receiver for mouse and keyboard. If you don’t have a mouse or the means to plug one in, don’t worry, it’s not really hard to do. In this case, I’d recommend to install the updated kernel package from the KDE:Active repo as soon as the base installation is done, as that makes the touchscreen work, from that point on, you won’t need a mouse anymore.
The process should take you about two hours, you might get it done quicker, but should be able to get it running within, say, one evening.

Getting started

The following points provide a detailed guide to installing Plasma Active and the Contour shell onto your ExoPC, using openSUSE. This process is also explained on the wiki, check there for the latest updates.

  1. Install openSUSE 11.4: Download this image, Use “dd” to write it to a USB stick, or use the excellent imagewriter tool to handle this for you. after this step, you should have a bootable installation medium in your hands.
  2. Insert the USB stick into your ExoPC, boot it and install openSUSE 11.4 onto the machine. It’s wise to enable auto-login, and possibly the SSH server during the installation, since this makes your life a bit easier later on. You need a keyboard for this.
  3. Set up the repositories for Plasma Active:
    zypper addrepo --refresh \ 
       http://download.opensuse.org/repositories/KDE:/Release:/47/openSUSE_11.4 kr47
    zypper addrepo --refresh \ 
        http://download.opensuse.org/repositories/KDE:/Active/openSUSE_11.4/ plasma-active
    
    zypper modifyrepo --priority 90 plasma-active
    

    The last line increases the priority (lower value means higher priority) for the Plasma Active packages.

  4. Update your KDE installation to the 4.7 release, this pulls in the dependencies needed for Plasma Active. At this point, you still have a traditional desktop, you now update the KDE stack to the 4.7, and get a few updated packages as well (among them Mesa and a new kernel which is needed to make the touchscreen work and brings much better performance):
    zypper dup
    

    Accept all vendor changes.

  5. Make sure the 3.0 kernel is installed (“zypper if kernel-desktop”), if not install it with
    zypper in plasma-active:kernel-desktop  plasma-active:kernel-desktop-base
    
  6. Install Plasma Active packages on top. This will install the contour shell, some apps and configure your system to run Plasma Active, including tweaks to the defaut configuration that make the whole system more touch-friendly and suitable for mobile use cases.
    zypper in plasma-contour-config
    

    After this step, you have Plasma Active on your system.

  7. Reboot to boot the new kernel, the Active shell will start automatically. If you get a black screen past login, use a keyboard and ALT+F2, “konsole” to get a shell and try starting “plasma-contour” by hand. If the command is not found, as root, do “ln -s /usr/bin/plasma-mobile /usr/bin/plasma-contour”.
  8. Install additional packages, such as Calligra Active (package “calligra-active”) Kontact Touch (package: “kdepim4”) or the kdegames4 suite. Bringing you a nice collection of useful software.
  9. Hop into the #active IRC channel on Freenode.net, tell us about your experiences and help others gettting started as well. =)

On Tuesday at 14:00 UTC and on Friday at 12:00 UTC, we will organize online install fests on #active (Freenode.net) where we can help you with installation issues, and where you can share your experience with others. Of course you’re free to drop by and hang around at any time.

Kollaboration in at Platform 11

(What? We’re back to tacky K-Names? Don’t worry, just using the K to reminisce us of our roots. :-)) The Platform 11 sprint in Randa is now in full swing, while relatively little code is being written by the 24-ish people here (and the occasional visitors from one of the other 3.5 sprints happening in the same building, at the same time), we’re very, very busy. It’s basically work until collapse, sleep and start again. Kevin is applying his kanban magic to manage the sprint and get everybody focused and synched. Kanban Magic means that we’re using a wall and a lot of post-it notes with tasks and topics on them, and we move those post its through different stages indicated by swimming lanes on the wall, froom waiting through design, review to done. The first note has just passed the review stage and is now in done state: our first accomplishment. :-)

Northbound view from our house in Randa -- even a crappy cellphone camera cannot ruin the stunning viewAs we’re working on issues central to how we all (KDE and Qt hackers) develop, I’m sure you’re impatiently waiting for results to pour onto the Internet. While our first focus is on personal interaction and using the facetime and “high personal bandwidth” to solve hard problems, you can get at least an overall impression of the direction of our work, as we’re tracking our results on the wiki.

What is really good and healthy to see is the number of different stakeholders (sometimes represented by the same person wearing multiple hats). This way we can make ‘reasonably sure’ that we take different point of views into account, and find solutions that work for us all. One might expect that this results in endless discussions, but in practise, most of us are on the same page, and where we’re not, we’re taking the time to sync up and see how much common ground we have, and how we can take advantage of that. There are people from up and downstream, from subcommmunities and companies, and people that all have different stakes in the KDE platforms and frameworks.

A big thanks goes to those who made this sprint possible: first of course to all the participants who are focused, motivated and working hard to produce good results. Then of course to Mario and his excellent team of volunteers who make sure we’re fed, warm, safe and taken care of. There is a number of sponsors without which this sprint would not have been possible, those are the Raiffeisen bank, Swisscom and openSUSE who generously chipped in to get us all together for a focused meeting to improve our foundations. Thanks to you all! We are certainly justifying the energy, passion and resources made available to us by working very hard to produce good results!

What’s new in Plasma Active?

We’ve been busy bees in the growing Plasma Active team, so it’s time to post some progress updates. In case you forgot, Plasma Active is a KDE project to create a desirable user experience for the device spectrum, with its first focus to create a system suitable for tablet computers. In my first post about Plasma Active, you can see the basic shell running on a 10 inch Viewsonic Viewtab. In this post, I’m using a Wetab to demo the current state of Plasma Active. The Wetab is one of our test devices. It’s a nice target device since it’s Intel Atom-based, which makes building Plasma Active a bit easier, and thus shortens our development-testing-deployment cycles considerable. The Wetab can currently be gotten from German Ebay for 219€ + shipping, so it’s also quite affordable.

Back to the software, though. Our focus in the past weeks has been two-fold, we’ve done a lot of “small fixes” which greatly improve the user experience. The other class of changes is less visible at this point, but still fun and exciting.

Virtual Keyboard Layout

new virtual keyboard layout The virtual keyboard is using a layout that is more suitable for tablet computers, containing more characters on the first, easily reachable “page” of it. This makes text input a lot less annoying (let’s face it, touchscreens are not ideal for typing as they lack haptic feedback, so it can only become so good). There’s still a bunch of things that would make the keyboard better, and of course it has its fair share of bugs, but it basically works and isn’t too annoying, either.

Top Panel and Window Switching

We’ve also done some work on the top panel, holding access to network, power management, the calendar and a bunch of other things. While the panel would slide out a bit in our early versions to make the hit area bigger, we found that this intermediate step is not necessary, we increased the default height of the panel a bit which works nicely. The panel is still meant to be slided out, but for a different purpose. We will be putting a strip of window previews in there, replacing the current appswitcher sitting in the top left corner. Most pieces for the new panel-and-window-switching mechanism are already in place, but it’s not finished yet.

Snazzy new Activity Switcher

New activity switcher in Plasma Active During Tokamak, Marco has merged a new, snazzy Activity switcher into Plasma Active. This activity switcher offers a wheel-like interface which you slide in from the right. It has previews (or rather post-views ;)) of your activities, and you use a small slider on those previews to switch to an activity. (These activities right now provide spaces for different sets of widgets, but will be given more meaning thanks to the Contour project, which develops a semantic workspace framework for Plasma Active. As all the parts necessary to make basic activity handling in Plasma Active work, we’ve decided to merge this new switcher already, since the “old” one was really very basic, and wasn’t quite so intuitive, due to lack of visual feedback (i.e. previews).

Try it!

open-slx has created a new Plasma Active image, which can be run live off of a USB stick, you can find the latest version here (spot the plasma-active.current.iso). There are also openSUSE and Meego packages available (the latter being a bit less mature, but we’ve made really good progress in the past days.)

If Plasma Active has spawned your interest, or you would like to find out how you can get your software to run on and integrate well with Plasma Active, get in touch with us, either on IRC, or via our mailinglist. You can find more information on the Plasma Active pages on communitybase.

I’m going to the KDE UX sprint, then Tokamak is coming to me!

On Thursday, I’ll be travelling to Berlin for the KDE UX sprint, which is kindly hosted by relevantive in their office in the heart of Berlin. I’ll be meeting Nuno, Celeste, Hugo and a few others there, and we’ll be making plans. Topics are the human interface guidelines, getting more designers involved with KDE, and of course Plasma Active.

A few days after coming back, hell will break loose in Nijmegen, as the Plasma crew holds their Tokamak gathering here. Here means at our new house in Nijmegen in the east of the Netherlands (which is in the west of Europe ;)). I’m really looking forward to having my fellow Plasma hackers here, especially with all the excitement, new ideas and concepts coming along with Plasma Active. I’m sure it will be an epic Tokamak, and a really long one, too. Between first arrivals and least departures, there will be a whopping 12 nights. We’ll likely be doing an Open Day, so if you’re in the region, drop me an email if you’d like to come by to see the magic happen.

Speaking of Plasma Active itself, it’s off to a good start. We’ve spent crazy amounts of hours in very little time before I announced it on my blog, and we kicked off a surge of blog posts about this subject — with more to come. I’m really happy with the positive interest it generated so far, very promising.

With the past two weeks spending most of my time on documentation, packaging and communication, I got back into hacking mode today, and polished up my small metadata engine I had started writing not long ago. It’s working now, you can query all kinds of resources, either by filename, URL, Nepomuk Identifier or simple query term, and it gives you back a list of Nepomuk resources and their metadata. It’s pretty simple, but very powerful. It already provides most of what you need to write a simple filebrowser, or search widget in Plasma Quick. I’ll write a more detailed blog post (including screenshots) once I’m more happy with it, also visually. The basic metadata engine is already in master, and will be appearing in the next update of the Plasma Active packages, probably tomorrow. Now, back to hacking. =)