Ui framework needs to be reintegrated

[upsiflu]

• [ ] Higher test coverage in Restrictive
• [x] Need to implement a Ui element that is path-dependent (sth like 'page' or 'at' or 'byPath') -> Accordion will render according to path because Restrictive.application.view won't
• [x] Then we can remove the Route type in Main and defer the complete Ui state management to the URL/Restrictive Model
• [x] Implement centering with custom element instead of Cmd because it'll happen in the view, not update

[upsiflu]

Revisiting the view code to check for requirements

• Segment.view seems messy but it's fine. It really is. We can, of course, add a convenience function for toggle. Then we can remove the self-check in Accordion.
• Accordion.view seems even messier but it's very fine. It's coupled to some CSS, which can be painfull. If we go for the pay-to-view approach, we have to:

1. Decide how to represent the 'perspectives' (paths). Probably we simply use a custom Ui where we grab the path and view the accordion accordiongly. This would be a potential primitive in Restrictive. Simply :(Url->Ui)->Ui and done. Note: implemented as experimental Ui.page

2. Implement other viewModes such as history or overview with toggle-able windows. Easzy.

3. Upgrade the custom elements. Specifically, we want auto-nav:

   • At the moment, the centering does not involve a path-change, which is a bit bad. In fact, it only changes the current (highlighted) element within the parent.
   • This behavior can be formalized by serialising the current cursor into an optional hash, and each hash-change would navigate through the accordion.
   • A nice side-effect is that we can then easily define the ArrowKey-TabOrder by making Arrow-keys affect the hash directly.

4. For the hash to store the current element, we need to have the aforementioned :(Url->Ui)->Ui Ui.byUrl. -> new issue!

[upsiflu]

Concerning centering, we had good experience in https://github.com/upsiflu/multimedia