Plasma Mobile and Convergence

Convergence, or the ability the serve different form factors from the same code base, is an often discussed concept. Convergence is at the heart of Plasma‘s design philosophy, but what does this actually mean to how apps are developed? What’s in it for the user? Let’s have a look!

Plasma -- same code, different devices
Plasma — same code, different devices

First, let’s have a look at different angles of “Convergence”. It can actually mean different things, and there is overlap between these. Depending on who you ask, convergence could mean any of the following:

  • Being able to plug a monitor, keyboard and mouse into smartphone and use it as a full-fledged desktop replacement
  • Develop an application that works on a phone as well as on a desktop
  • Create different device user interfaces from the same code base

Convergence, in the broadest sense, has been one of the design goals of Plasma when we started creating it. When we work on Plasma, we ultimately expect components to run on a wide variety of target devices, we refer to that concept as the device spectrum.

Alex, one of Plasma’s designers has created a visual concept for a convergent user interface, that gives an impression how a fully convergent Plasma could look like to the user:

Input Methods and Screen Characteristics

Technically, there are a few aspects of convergence, the most important being: input methods, for example mouse, keyboard, touchscreens or combinations of those, and screen size (both physical dimensions, portrait vs. landscape layout and pixel density).

Touchscreen support is one aspect when it comes to run KDE software on a mobile device or within Plasma Mobile. Touchscreens are not specific to phones any more however, so making an app, or a Plasma component ready for touchscreen usage also benefits people who run Plasma on their convertible laptops, for example. Another big factor is that the app needs to work well on the screen of a smartphone, this means support for high dpi screens as well as a layout that presents the necessary controls in a way that is functional, attractive and user-friendly. With the Kirigami toolkit, which builds on top of QtQuick, we develop apps that work well on both target devices. From a more general point of view, KDE has always developed apps in a cross- platform way, so portability to other platforms is very much at the heart of our codebase.

The Kirigami toolkit, which offers a set of high-level application flow-controls for QtQuick applications achieves exactly that: it allows to built responsive apps that adapt to screen characteristics and input method.

(As an aside, there’s the case for Kirigami also supporting Android. Developing an app specifically for usage in Plasma may be easier, but it is also limiting its reach. Imagine an app running fine on your laptop, but also on your smartphone, be it Android or drive by Plasma Mobile (in the future). That would totally rock, and it would mean a target audience in the billions, not millions. Conversely, providing the technology to create such apps decreases the relative investment compared to the target audience, making technologies such as QtQuick and Kirigami an excellent choice for developers that want to maximize their target audience.)

Plasma Mobile vs. Plasma Desktop

Plasma Mobile is being developed in tandem with the popular Plasma desktop, in fact it shares more then 90% of the code with it. This means that work done on either of the two, mobile and desktop often benefits the other, and that there’s a large degree of compatibility between the two. The result is a system that feels the same across different devices, but makes use of the special capabilities of a given device, and supports different ways of using the software. On the development side, this means huge gains in terms of productivity and quality: A wider set of usage scenarios and having the code running on more machines means that it gets more real-world testing and bugs get shaken out quicker.

Who cares, anyway?

Whether or not convergence is something that users want, I think so. It takes a learning curve for users, and I think advancements in technology to bring this to the market, you need rather powerful hardware, the right connectors, and the right hardware components, so it’s not an easy end-goal. The path to convergence already bears huge benefits, as it means more efficient development, more consistency across different form factors and higher quality code.

Whether or not users care is only relevant to a certain point. Arguably, the biggest benefit of convergence lies in the efficiency of the development process, especially when multiple devices are involved. It doesn’t actually matter all that much if users are going to plug their mouse and keyboard into a phone and use it as a desktop device. Already today, users expect touchscreen to just work, even on laptops, users already expect the convertible being usable when the keyboard is flipped away or unplugged, users already expect to plug a 4K into their 1024×768 resolution laptop and the UI neither becoming unreadable or comically large.

In short: There really is no way around a large degree of convergence in Plasma (and similar products).

14 thoughts on “Plasma Mobile and Convergence

    1. Rohan made one, he’s still working on it, so it’s really an unsupported snapshot that will soon be reflashed. I guess he’ll post details about that when it’s more usable.

  1. Is Plasma the best desktop for touch based devices? I see all the laptops I’m interested in purchasing have a touch based UI (of course along w/ the standard keyboard/mouse inputs). After watching the video it seems like Plasma will be the better UI for a touch based laptop/2 in 1.
    In the 2 in 1 model then what happens when I convert it to a tablet mode? Does it just switch automatically then?

    Also will I still be able to leverage the ability to touch to scroll, etc. when I’m in a laptop mode?

    Anyways it looks pretty cool and interesting

    1. It depends a little, in some areas, we’re doing pretty well on convertibles: Touch usage, virtual keyboard, etc.. What we’re currently lacking (and what I’m working on actually) is automatic screen rotation, so if you depend on that, you’ll have to rotate “manually” right now.

  2. I like the ideas of convergence and is mostly positive to it, but two questions:
    – If its just gonna be 1 codebase does this also mean that I will have the same binary blobs on desktop that is the reason to why phones cannot be trusted and that Purism want to make a phone with baseband separated from cpu etc?
    – How will the battery life be on such a device? From what I’ve heard GNU/Linux is not the best batterywise on desktop, so how will it behave on a mobile?

    I’m sorry if the questions are weird, but as a user it’s the few questions I feel is not easy to find a answer to.

    1. I don’t think I understand your concern. Let me try to explain: Plasma has a binary called plasmashell that dynamically loads a specific user interface. This has nothing to do with the baseband at all, so it’s orthogonal to the trust model.
      The battery life again depends on what you’re actually running. Plasmashell is actually very well reviewed to not unnecessary wake up the CPU. The specific UI loaded may still do that (and if there’s no clear reason to do so, i.e. user interaction or some important event, that would be a bug). It is easier to achieve good battery performance this way, since one only has to fix one program, and multiple battery-driven devices benefit. (Laptops and phones, for example.)

  3. Is it possible that the desktop and tablet UI’s would be integrated such that it works well on convertables like Chromebooks?

    So when in normal laptop mode, it is a full Plasma desktop UI, then when you flip the laptop into tablet form-factor, Plasma switches to the tablet UI?

    Would give us another advantage compared to Windows or ChromeOS

    1. That’s actually the idea. We haven’t put a lot of effort into switching shell layouts at runtime yet, but the architecture is built to support that.

  4. I really like the approach taken towards convergence here. And the different angles also help clear up some confusion.

    I’m curious about how you intend to solve the part of the convergent-device-spectrum where you go from a touch-optimized interface to a traditional desktop interface. The devices here could have similar screen sizes but different input methods (touch vs keyboard/mouse). I think it currently shows the cursor for the mouse, but doesn’t really optimize the UI for keyboard/mouse use, resulting in UIs with big buttons and lots of empty spaces. I understand if this part is still far ahead in the future, I just haven’t really heard anything about it yet.

    I wrote a forum post about this, a little while ago. Maybe it wasn’t in the right place to reach the people I wanted it to. You can find it here:
    https://forum.kde.org/viewtopic.php?f=285&t=141574

    1. Excellent question! There’s not really one clear solution to this as you always have to make a trade-off between those input methods, and there is a number of other factors coming into play (such as readability of inputs, screen fidelity, even eye fitness, etc.). Some things that help is if one looks at order of preference: On my laptop in keyboard mode, I’d *like* things to be touch-friendly, but not at the cost of efficiency for keyboard and mouse, so it’s more of an extra. This may be the other way round for some people, so often it’s down to preferences. Plasma in itself is very configurable and adapts to font size, so the user can actually influence things to a certain degree. It also helps that we can actually differentiate between pointer devices and events, so a touchscreen even can be handled differently from a mouse event. This allows us to implement touch gestures that don’t interfere with the mouse, for example.

      We don’t have this problem fully solved, but at a technical level, we have an excellent toolbox to keep improving.

  5. I hope that it uses wayland because doing it with xorg and then porting it to wayland would be a huge work and doing it with xorg is a totaly no-sense.

    1. Not really, most of the code isn’t tied to a specific windowing system, it happens on a wholly different level. Qt abstracts those differences, as well as libraries such as KWindowSystem, and of course our KWin window manager and compositor.

      The Wayland transition has some benefits for our convergence story, but it’s not as clear-but as you say — which is good, because we can work on both topics in parallel, and also take things we learn from our convergence work into account when we design Wayland solutions.

      Convergence is certainly not something you do either on Wayland, or Xorg. I will write more about the technical background of that in one of my next articles about this topic. Stay tuned!

Comments are closed.