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