Expose methods to change viewport alignment

[tarkah]

As discussed in #1912, consumers need to be able to calculate new viewport offsets when swapping between alignments.

This exposes two new with_<direction>_alignment methods. If user wants to keep the scrollable's viewport anchored in the same position while swapping alignments, they can call viewport.with_alignment(new_alignment) and return the new viewport's relative_offset to scroll_to.

[hecrj]

I have simply introduced an absolute_offset_reversed method instead. Will that work?

[tarkah]

Looks good, @hecrj. Thanks!

[hecrj]

Eventually, we should probably expose a variant of the Scrollable widget that lets the user completely manage the offset.

[hecrj]

Cool! Thanks again 🙇

[tarkah]

Eventually, we should probably expose a variant of the Scrollable widget that lets the user completely manage the offset.

At what point should we prefer widget operations over managed app state?

The same can probably be said for text input widget.

As for composing widgets, a parent widget can still do widget operations within on_event right? It's not just the application that can do these.

[hecrj]

At what point should we prefer widget operations over managed app state?

When commands are regularly needed to keep a widget in sync with some application state, then that's a sign there are multiple sources of truth.

With managed app state you can derive any scrolling state from your application state without necessarily storing offsets at all.

The same can probably be said for text input widget.

Yes, a text input with a fully managed cursor has a bunch of valid use cases.

As for composing widgets, a parent widget can still do widget operations within on_event right? It's not just the application that can do these.

Yes, although I'm not sure that'd be very useful. You'd want the unmanaged widget to depend on the managed one, and the managed one won't expose operations ideally.

[tarkah]

Agreed! The need for managed state satisfies both use cases.

The text input seems like a good test case for this since it really can go either way.

Would you prefer two separate widgets, or one widget that exposes a managed builder for taking state provided by the application and internally it can switch between that or tree state?

[hecrj]

Two separate widgets; one built on top of the other. Logic will be simpler this way, and we can expose specific APIs for each.