Sxmo: Linux tiling window manager for phones(sxmo.org)
sxmo.org
Sxmo: Linux tiling window manager for phones
https://sxmo.org/
48 comments
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.
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/
[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.
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.
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.
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.
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.
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.
It may be just me, but a 1-2min video demo on the home page in place of the 45min presentation could help to get the idea over clearly.
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
Edit: added missing key words in a sentence :/
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
Edit: added missing key words in a sentence :/
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].
[0]: https://fosdem.org/2024/schedule/track/foss-on-mobile-device...
[1]: https://fosdem.org/2024/stands/
[0]: https://fosdem.org/2024/schedule/track/foss-on-mobile-device...
[1]: https://fosdem.org/2024/stands/
>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.
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.
Could there be motion gestures for Sway on mobile?
- pinephone-sway-poc: https://github.com/Dejvino/pinephone-sway-poc#components
(Edit)
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.
"Using OSTree Native Containers as Node Base Images" (2023) https://www.opensourcerers.org/2023/06/16/using-ostree-nativ...
- pinephone-sway-poc: https://github.com/Dejvino/pinephone-sway-poc#components
(Edit)
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.
"Using OSTree Native Containers as Node Base Images" (2023) https://www.opensourcerers.org/2023/06/16/using-ostree-nativ...
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.
Would be nice if there was a screenshot.
Everything I've seen about SXMO makes me think it's for neckbeards who care more about Stallman-style freedom than aesthetics/usability.
Everything I've seen about SXMO makes me think it's for neckbeards who care more about Stallman-style freedom than aesthetics/usability.
Cool! Question:
I don't need to run google apps on this. That's nice.
But can I please? Having access to a few key banking apps or home-automation apps, as much as they suck, would be really helpful.
I don't need to run google apps on this. That's nice.
But can I please? Having access to a few key banking apps or home-automation apps, as much as they suck, would be really helpful.
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].
[1]: https://waydro.id/
[2]: https://tilvids.com/w/2b2f3a24-ae23-458e-a0fd-2f24a185a11b
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].
[1]: https://waydro.id/
[2]: https://tilvids.com/w/2b2f3a24-ae23-458e-a0fd-2f24a185a11b
For "security" reasons banking apps generally disagree running on anything rooted. Is there a way to circumvent that?
Don't use a bank that demands an app instead of having a website?
I haven't used Linux on a phone yet so I don't know about those, but regular rooted android has easy ways to circumvent what you're talking about.
Generally, in order to run bank apps on a non-stock ROM you have to root your phone and install things that hide it, kinda defeating the purpose.
Nice! I see that it's got two flavours in PmOS:
* 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 swayWhat's new with SXMO? Haven't been keeping up since 2021. Is there a stable phone to run this on now?
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...
A 2nd title from the front page:
> SSH as a first class citizen
What the window manager has to do with SSH?
> SSH as a first class citizen
What the window manager has to do with SSH?
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):
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
Is there any Android launcher that is close to this?
The closest thing I can think of is KISS Launcher.
I really like the idea. But until it has an actual lock screen, it is not that useful sadly.
AFAIK it does have a lock screen.
Yes, but there is no pin nor password for unlock. Or at least there wasn't last time I looked. So calling it a "lock screen" is bit of a stretch...
Is anyone using mutt/neomutt as their e-mail client on this?
Tiling WM is useful for those who touchtype.
Ok it’s time. Goodbye apple.
Clever name: suckless -> suckless mobile -> sxmo -> sucksmore
Has anyone tried to write a WM using Python and Qt (for the menus and such) e.g. PySide6?
I know it is possible from Python alone calling Xlib directly, but it would be nice to have a more capable environment based on Qt.
I know it is possible from Python alone calling Xlib directly, but it would be nice to have a more capable environment based on Qt.