Skip to content

visibility state machine

dcz requested to merge dcz/squeekboard:animation into master

This MR turns visibility logic into a state machine, and connects it to all the places that need this logic.

A nice thing about it is that it can be tested rather easily, right up into the parts which connect to external mechanisms (UI, DBus, IM handling; those are not testable).

Another nice thing is that animations are rather easy to add, at least to the logic.

Yet another advantage is that this successfuly uproots some of the C code in server_main.c.

The final nice thing is that I finally don't hate this, and I think the same pattern could be used for sizing, selecting the relevant layout, or handling completion requests.

Open question: should all state be lumped into a single struct, or rather should multiple loops handling different pieces of state work alongside?

Shortcoming: this is the third(?) different layer trying to tackle the same problem, so it is a local increase of mess. The next step would be to eliminate the "VisibilityManager" from ui_manager.rs, which would also help answer the open question above.

The meat of the design is in the src/animations.rs file, together with a prose explanation. Long story short, it's some kind of an actor model thing, where state is pure and internal to the actor, and it gets processed inside an event loop.

Credits: loop and messages inspired by Elixir/BEAM, and pure state inspired by Bevy.

Regression (fix in progress): when bringing up the panel manually, it will use the previous layout.

Draft: the commit history is messy, unused code present, comments need some expanding.

Draft: needs bugfix: !507 (merged)

Edited by dcz

Merge request reports