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.
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.
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.
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.
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.
> 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.
how many people do you know who use 100% stock sway? certainly some people _do_. if you just want the DE to be a minimal part of how you interact with the device. then there are those who install aftermarket app launchers, swap in a different bar with media widgets, configure a dynamic background like conky, use a customized screen locker, etc.
sxmo is meant to be hacked like that. unfortunately though, as your experience shows, sxmo _has_ to be hacked like that to be usable. there isn't really so much of the "i'll just use 100% stock sxmo" the way there is sway.
ditch sxmobar. use waybar, or whatever you're comfortable using on desktop sway. hopefully the clock formatting is easier to tweak there. change the input shortcuts (drop a custom sxmo_hook_inputhandler.sh in ~/.config/sxmo/hooks or wherever). for power, i like "click power once to put phone in the unlock state; click power twice to put it in the screenoff state." doesn't matter which state you're coming from: single tap power, single tap it 3s later, you'll always end up in the screenoff state. making the shortcuts idempotent like that solves like 2/3rds of the race conditions i think you're seeing.
after twisting and pulling at it for a week to get it to actually be a DE i'm legitimately happy with, i feel sxmo has but three components which are game changing, and worth preserving: 1: bonsai, the daemon which maps button presses to actions. 2: lisgd, the gesture system (if you use it). 3: sxmo_appmenu.sh, i.e. its menuing system. the first one is actually its own, separate package: take a stock sway installation, install `bonsai`, configure the mappings, and you've got what you're familiar with from sxmo but without any of the other baggage. same with the second one. the third one, unfortunately, is not so separable from "sxmo" proper. mayhaps someone will do that someday and instead of installing sxmo, you'll instead install sway + bonsai + lisgd + "sxmenu" and it'll be a bit less coupled, a bit less buggy. i don't think sxmo is likely to evolve into that on its own though. it'll probably be that a new thing fills that "sxmenu" space instead.
Love it. Everything is tied together with shell scripts which isn't everyone's taste but I appreciate being able to hack up something quickly for a phone UI.
I wrote an alarm clock script (on the pine phone itself during my commute) which I need to publish it (wakes up right before _the alarm_ from deep sleep to sound an alarm).
There's lots of missing functionality (like an alarm clock that sets an RTC wakeup) but overall it is a cool system that I intend on using and hacking on again in the near future
For everyone interested in the whole "Linux on Phones" thing attending FOSDEM, make sure to check out the dev room schedule [0] and relevant stands [1].
>The kernel running on Android devices is heavily modified such that it cannot be maintained by the community
Android works on the mainline Linux kernel. If the community can already handle maintaining the mainline kernel I don't think the 210 long series of patches that the Android common kernel includes would break the camel's back. Throwing out all of the value of Android over this is throwing baby out with the bath water.
Since Android has multiwindow support it would be reasonable for someone to implement a tiling window manager for it.
Wait.... Can this run on a normal intel/amd server and then be used in an xrdp/nx session?
I need social compatibility and a good camera.
I already tried i3 but it is difficult to use without a physical keyboard.
rpm-ostree now supports using OCI container images as host images; so upgrading the OS is easy and more error-proof because you can rollback to the previous (kernel + /etc overlay + root partition + packages) by selecting a different boot menu entry.
If you want to style SXMO on Sway (for example: make menu items larger and easier to press with fingers, change font to a narrow one to fit more text per line, aesthetics, etc), this is a useful guide: https://porkyofthepine.org/blog/rice_sxmo_sway.html
Awesome! Thanks. I already thought about using my server for Linux phone sessions. At the moment only tmux+mosh. Having a DM that actually works for phones would be much better. This might help getting me there.
There's a piece of software called Waydroid[1] that allows you to run Android applications on GNU/Linux platforms - including the PinePhone. Sxmo, despite its name, can run Wayland instead of X and therefore supports Waydroid.
Personally, I haven't managed to get Waydroid to work, a task hindered due to some massive initial downloads which are required to set it up. However, I haven't tried particularly hard, and there are videos online by those more successful than me[2].
* sxmo-de-dwm: Simple Mobile: Mobile environment based
on SXMO and running on dwm
* sxmo-de-sway: Simple Mobile: Mobile environment based
on SXMO and running on sway
The PinePhone is probably the most stable one. I have seen a few people use it on this one and in a recent thread about the PinePhone it was also mentioned multiple times as a good alternative to the default Plasma.
Anything that can help us avoid Google/Apple stranglehold will be most welcome. Looking forward to this or something similar becoming good enough for non expert use.
I really like sxmo, unfortunately I have the classic pinephone and even with an environment as minimalist as sxmo, the battery is draining really fast. This is the only thing that is preventing me from using the pinephone as a daily driver...
Based on what I've read, Sxmo is not a WM, it's more like a flavored distribution/setup based on postmarketOS. It uses dwm/Wayland as WM, and many other tools to enable other features.
The SSH part claimed (based on my understanding):
1. You can read/send text messages via SSH remotely (say on your computer)
2. Read notifications too
3. Access the Bluetooth devices connected to the phone
