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:
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.
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.
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.
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
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.
