DanielTux @danielst@librem.one

@meldrian @Bertibaer
Naja, vielleicht besteht ja Hoffnung:

Nach Auslieferung der limitierten Serie des TWIKE 5 werden wir die Fahrzeugplattform weiterentwickeln und mit einer folgenden kostenoptimierten TWIKE 6 Serie verstetigen.

@emacsen
Thanks!

Here's a thread about it:
https://forums.puri.sm/t/the-search-for-a-floss-mobile-os-aug-2021/14520

I wonder whether you intended to have a section on the "Linux-based" OSes and then forgot it? 🙃 Or is that just because you think they're too far from being daily drivers?

In case you care about typos:
ASOP->AOSP
LibreM->Librem 5
Calx->Calyx

@vincent @vidak
I don't know, but isn't FFs reader view close to what you want?
Main problem, I think, is that it only works on pages where text and headline are reasonably obvious to extract.

@vincent @vidak
As in the HTML3 days? 🙃
Netscape had page navigation controls, but I think I never saw a page that could use it.

@pvagner @praveen @wizzwizz4 @storm @lorabe@floss.social @devinprater@dragonscave.space @csepp @purism
For example, the label of an input field is not independent, but directly related.
In my example, you could also swipe down 5 times very quickly, to skip reading 5 items if you already have a clue. And of course keyboard or speech recognition could be used to directly jump to relevant items. But the structural info "this is a menu" should help no matter what is your favorite approach.

@pvagner @praveen @wizzwizz4 @storm @lorabe@floss.social @devinprater@dragonscave.space @csepp @purism
Yes and no. Possibly, different mechanisms can complement each other. BUT I'd take advantage of structural info, which is possibly more available in libadwaita apps than in some frameworks. There might always be free-style content that needs exploring, but structured controls allow much more precise navigation, without possibly missing a weirdly placed item.

@pvagner @praveen @wizzwizz4 @storm @lorabe@floss.social @devinprater@dragonscave.space @csepp @purism
(4/4) In the mobile view, only either menu or content are visible, starting with menu. Thus, it would instead directly read out the available items, possibly assisted by gestures, e.g. tap: stop and re-read current item, swipe up: read previous, swipe down: continue reading, swipe right: select. Then continuing by reading the top level items, either settings or groups of settings, inside of WiFi.

@pvagner @praveen @wizzwizz4 @storm @lorabe@floss.social @devinprater@dragonscave.space @csepp @purism
(3/4) Question: Is one-tap-read-two-click really a good approach? It implies you have to tap around a lot to find stuff. With libadwaita it should be possible to do something like "read out top level items". For gnome-settings, in desktop mode it would read "menu" and "content: WiFi", indicating that WiFi is the selected menu item.

@pvagner @praveen @wizzwizz4 @storm @lorabe@floss.social @devinprater@dragonscave.space @csepp @purism
(2/4) libadwaita controls know about their state, e.g. settings dialog knows it's currently in the WiFi sub-dialog, even if the menu is hidden on mobile. Apps using those controls automatically benefit from all improvements there, be it default gestures or screen reader integration.

@pvagner @praveen @wizzwizz4 @storm @lorabe@floss.social @devinprater@dragonscave.space @csepp @purism
(1/4) While Purism is overwhelmed, understaffed and underfunded, I could actually imagine that GTK4 makes a11y simpler in the long run. Why? Purism created libhandy, now libadwaita in GTK4, providing consistent, complex, advanced, themeable controls, automatically adapting whole dialogs between mobile and desktop form factors.

@mailonator
was soll das?
😉