Vision for Plasma Mobile vs Plasma Desktop

Today, Plasma Desktop works very nicely on the Desktop and Plasma Mobile works on small (phone) screens. However, tablets/convertibles are somewhat in between and that’s when things become tricky (especially with an external screen/convergence).

A few examples:

  • always maximized windows without decorations
  • widgets
  • full blown and additional/custom panels
  • screen locker with numbers only

This leads to the situation that I’m currently using a Frankenstein Plasma on my tablet:

  • Plasma Desktop shell
  • regular SDDM with qtvirtualkeyboard, no automatic screen lock
  • Convergent Windows KWin script to have maximized windows without decorations on the internal screen but floating windows with decorations on an external screen.
  • Halcyon homescreen
  • Maliit

So maybe Plasma Mobile should be more modular such that the user experience is defined more by configuration.
This could mean to focus Plasma / Plasma Mobile · GitLab on the shell and extract everything else to separate repositories:

  • Halcyon
  • Folio
  • taskswitcher (see !272)
  • quicksettings (@niccolove wanted to see this in Desktop anyways if I remember correctly)

Then, the bits and pieces would be pulled together in Plasma Mobile / Plasma Phone Settings · GitLab (or a similar Plasma Tablet Settings).

Moving apps from the Plasma Mobile category to “regular” categories and KDE Gear releases is another step in the same direction that has already been taken.

In the end, everything boils down to the questions:

  • What actually is Plasma Mobile?
  • What are the goals/vision (especially compared to Plasma Desktop)?

I strongly believe that those questions should be answered in a central place (e.g. Plasma Mobile · GitLab) such that everybody is on the same page.


I totally agree. Since Plasma Mobile is such a new project, I never understood why the developers decided to create a new DE rather than adapt the existent software to react correctly to different form-factors. As it is, KDE’s software appears to have mostly become more fragmented due to their effort because the mobile applications use the more basic but adaptive Kirigami, whereas the desktop applications are unable to convert to Kirigami because its design is so inconsistent and basic.

Convergent software is indeed the sole decent solution to this problem. After many years fought doing exactly the same thing (albeit 1 million times worse) Microsoft has finally realized this with Windows 10 and 11, with their WinUI GUI toolkit.

This is kind of the the direction that the shell is moving in, however convergence does take a lot of work to get right. I think it’s a worthwhile goal to have, and should be easier once kded: Add startup settings manager (!283) · Merge requests · Plasma / Plasma Mobile · GitLab gets through.

Since there isn’t many people that work on mobile and have ways to test it, there is always the risk of regressions due to desktop work that aren’t caught in time for mobile (ex. see kcms that are shared between desktop and mobile)


Yeah, @espidev, I’ve tried Plasma Desktop with PostmarketOS on my FP4, and it definitely isn’t ready for mobile use. Plasma Mobile, on the other hand, worked almost perfectly except that because it would render every application in fullscreen, I was stuck forever when I launched an app that didn’t provide window borders in Wayland.

The description of the linked MR is somewhat nondescript to a layman such as myself. Do you mind telling me whether it adds a new KCM to Plasma Desktop, and whether, as its description appears to state, it shall make the entire Plasma Mobile systemsettings5 fork unnecessary?

The MR is unrelated to KCM settings at all, it is for managing specific settings configurations needed for Plasma Mobile, otherwise you would need to edit config files yourself when switching between desktop and mobile. This can allow for using modular components (ex. task switcher, convergent window script) easily for Plasma Mobile, which is opinionated (we choose which components are used, it’s not configurable).

it shall make the entire Plasma Mobile systemsettings5 fork unnecessary?

Plasma Settings (which is Plasma Mobile’s settings app) is not a fork of systemsettings5. Systemsettings5 was designed to be compatible with both QtWidgets and QtQuick KCMs, but brings with it many issues since we have to embed different app toolkits into one applications (ex. dialogs can’t darken the entire app window). In theory, if all of the QtWidgets based KCMs were ported to Qt Quick, then Plasma Desktop could use Plasma Settings or something like it, which is a typical Qt Quick application.

1 Like

Good to hear. I’ve always thought that plasma-systemsettings is hideously inconsistent. Knowing that all that stands between the new Plasma Mobile being the replacement is rewriting the interface of some KCMs provides some hope.

By the way, is the inability to darken the window beneath the dialogue box the reason why it uses those nonstandard pseudo-windows? demonstrates one at 0:05 (if you don’t know what I’m referring to).

Those look like standard Kirigami dialogs to me?

Yeah, just checked, and they appear in most Kirigami software. So are they deliberately not using the window manager? That seems strange – to reinvent the wheel in such an inferior manner.

That’s not our design decision, this is something inherent in how QML is designed. Dragging around windows wouldn’t work too well on mobile devices either :slight_smile:


Thanks again for the info.

Do you know where the correct place to discuss such a decision would be? I’d love to ask whatever team manages such decisions for QML why they chose to do such a thing, because if they were to reverse it, it’d make my experience with Plasma Mobile (and especially desktop) a lot better.

After all, the WinUI team recently realized, after making many of their windows separate from dwm.exe in Windows 8, that the decision was a mistake, so there’s decent precedent.

Your best bet is to contact Qt themselves, but you’ll not get many opinions on reversing it.

1 Like

Just to demonstrate my point, the WM does make the dialog look a lot better, even to GTK’s otherwise definitely inferior layout.