Currently multiple postmarketos-ui-* packages can't be installed at the same time because the 60-autologin.conf file conflicts. If this file is renamed to something else for every UI package they can at least co-exist. This would lead to less problems when trying to switch UI with the package manager and it would make it possible to select the UI on boot if there's a greeter that supports a mobile screen.
For example gdm can be installed on postmarketos and enabled, and then lightdm disabled. gdm works reasonably well on the pinephone (and probably crashes on most other postmarketOS devices) and can select the desktop to boot in to.
and probably crashes on most other postmarketOS devices
Oh, I got kinda excited about it yesterday when you mentioned it, not so much now...
Ideally we have a DM which allows switching UI's, like GDM, but it should work on every device with working screen really. I've been meaning to look into using SDDM for it but haven't gotten the chance yet.
if there's a greeter that supports a mobile screen.
We could make something with the webkit greeter (but it could probably be incredibly slow and it doesn't seem to be packaged in Alpine yet) or fork an existing one and attempt to modify it.
gdm works reasonably well on the pinephone (and probably crashes on most other postmarketOS devices)
On the 2 Samsung devices I tried it with, it worked, but it was painfully slow (especially the keyboard, which seems to need to be restarted once?)
We could make something with the webkit greeter (but it could probably be incredibly slow and it doesn't seem to be packaged in Alpine yet) or fork an existing one and attempt to modify it.
Ewww, let's not use the webkit greeter. This should be a simple task that some lightweight software can do, having a whole browser in there is the opposite.
@Raatty's custom mobile greeter is more lightweight, although still depending on python: !1017 (merged)
It's probably not so hard to add multiple UI selection to it.
Rustwashing is off-topic on every forum on which it's raised. C is a suitable langauge for new projects and if the community does not wish to use Rust, I will thank you for holding your tongue.
(And now my offtopic opinion that I'm not qualified enough to say: there's no need to overcomplicate and use Rust. Considering that we are going to do, good old C (or good not so old C++ if we are going to write one in Qt) would fit our needs. And if you are suggesting us to use Rust because muh MeMoRy SaFeTy, well, feature just for feature is not always good and you really need to mess something up in your C/C++ code to get problems with memory.)