Of all the interfaces I tried on the pinephone, sxmo is easily the best. I'm not a big suckless user generally, I respect that kind of software but find myself gravitating more to kitchen-sink stuff like emacs and KDE. That said, sxmo is much snappier than KDE or Phosh and once you get over the the discoverability hump (I think megi had a nice cheatsheet) it's really functional and intuitive (subjectively speaking ofc).
I’ve been running Plasma Mobile on my Librem 5 and it’s pretty snappy though I’m not sure how viable it will be as an app platform as KDE has chosen to rewrite all their core apps using a more mobile friendly framework. So there isn’t a whole lot to dive into and probably won’t be for a few years still. I will give sxmo a try from your recommendation.
I run Plasma (via pmos) on a pinephone and snappy is probably the last word I'd use to describe it.
Mostly based on Qt responsive Framework Kirigami https://api.kde.org/frameworks/kirigami/html/index.html . The GTK counterpart on Gnome Phosh (Phone Shell) was libhandy (https://gnome.pages.gitlab.gnome.org/libhandy/), now for GTK4 merged to libadwaita (https://gitlab.gnome.org/GNOME/libadwaita).
Yeah I think I ran an early build on a Pinephone and it was laggy. I’ve heard if you go Pinephone you have to go with the Pro version, because the previous model has no hardware support. Thus the poor quality software experience. Purism actually contributes to the software side so while it’s a bit lacking in quality, it is getting better with snappier ui and battery life.
Plasma Mobile is already using that "new framework" though (always has).
Yes it is more of a QT thing because they didnt update widgets for mobile friendliness but I didn’t want to go into the details as it wasn’t my point. I’m not really a fan of QML so I am not sure I’m going to stick with Plasma Mobile anyways.
At least for the Kirigami apps [1] that are hosted on invent.kde.org (and not just personal projects), a lot of porting has to KF6 has happened.
[1]: https://linuxphoneapps.org/frameworks/kirigami/
The problem with Kirigami is that it became a grab-bag of missing Qt QML components that relies on Qt Fusion-styling instead of a unique design language as originally proposed. So the migration to v6 doesn’t really benefit, because Kirigami just inherits bugs from Qt QML which may or may not still be present.
I haven’t used my PinePhone for six months (travel-related reasons), and have gone through another period of not using it (for inscrutable reasons, phone calls weren’t getting audio), but cumulatively I think I’ve got around a year and a half of using it as my phone.
I tried other desktop environments, but settled on sxmo/swmo, mostly because I liked the theory of it, and having control in putting pieces together, and being able to ignore my phone and use it over SSH from my laptop, which I’m much more likely to have with me and out, and I’m already used to Sway. Also phosh and KDE both had fairly debilitating issues when I started. They’re probably much better and more suitable now.
I’ve always found sxmo seriously buggy. Huge numbers of race conditions that will ruin things until you restart. In order to get open and unlocked, you might need to press the power button once, twice or three times, or press and hold for at least half a second and press a second time, or who knows what else, I can’t remember—all depending on sleep states and what was happening earlier. And any things like status and mode changes will take most of a second before they’re updated visually, rather than happening instantly, which is a surprisingly big drag. Or some mutex state will go bad in some way and you’ll end up with an ever-increasing number of new processes trying to control how the LED should flash, and before long you’ll have to pull the battery out because even holding down the power button isn’t doing anything.
You know how people talk up Rust over C, and talk about how various categories of bugs wouldn’t have occurred if only they’d chosen Rust with its memory safety and its superior data model? Well, sxmo is largely implemented in shell scripts, which for large-scale design are considerably worse than C. You get even fewer proper primitives, and it shows. The system as a whole is a hodge-podge of pieces that have covered their eyes and ears to the existence of the other pieces, when if only they would work together, they could achieve much more stable results. Sometimes these things seem OK, but aren’t implemented completely correctly; other times the design is just overcomplicated and ill-conceived. I doubt it’s changed in the last six months, so I challenge anyone that uses sxmo: figure out (a) how to change the system tray clock’s presentation (can’t remember what it was I baulked at, 24h or 12h with zero-padding, where I wanted 12h without zero-padding), and (b) how to have it actually update at the right time rather than up to 55 seconds late (!). The endeavour will take you through a few completely different systems as a 55s timer sets a cached value and the status bar fetches the cached value, but I think it was more complicated than just that, and it comes from at least three significantly different locations on disk (you will want something like ripgrep to aid you in finding stuff in these exercises), and you’ll come away wondering why the status bar command didn’t just include a direct `date +'%H:%M'` command that you could change to `date +'%-I:%M %P'`.
Functionally also various things that on Android would Just Work just don’t at all, and even some that on Phosh would Just Work don’t really, or don’t smoothly. But if you can figure out how to make something happen, you can now script it far better. But… yeah, I’ve done a lot of scripting of things. My own personal workflows, I’ve made more convenient than on any other OS (though I dunno, I think I heard Apple had some scripting thing that maybe could come close).
Some of these issues have been fixed over time, others have been introduced; overall its actual quality remains fairly low; I continue to use it; perhaps I’m a masochist.
In the end, I don’t actually know a single person that I would recommend sxmo/swmo to. But the sort of person that I would recommend it to would certainly already be using a tiling window manager on their desktop, and probably doesn’t care much about phones in general.
Guilty as charged.
The parts I like are the parts that work, and I think I was lucky enough not to encounter so many bugs as you did. Furthermore the hackability may be not great, but I'd venture it's still superior to the alternatives where I'd presumably need to spin up a build env for KDE or Gnome and deploy a whole new release.