This makes the keyboard navigation feel more solid.
I'm not bothering to do the same for panning with the mouse. Mostly
because I'm lazy, but also as an escape hatch in case I find myself
wanting to move the top lower down the screen or something. But it'll
still snap back the first time I pan using the keyboard. Let's see how
much it matters.
This will make things more consistent in the long term, but I realize
one major cost: our button abstraction doesn't work well with luaML and
compute_layout. So we need something to replace it.
This required a little more restructuring of Global_state. It's not flat
now, it's hierarchical again, but in a different way.
after commit 3d89b8eb9d:
post
\- reply A
\- reply B
\- reply C
after commit f9f7dab9b7:
post
reply A
reply B
reply C
after this commit:
row
\- col
\- indent 0
\- post
\- col
\- indent 1
\- reply A
\- col
\- indent 2
\- reply B
\- col
\- indent 1
\- reply C
The indents are just invisible rectangles of different widths with 0
height.
One change I had to make was to initialize_editor. Neither luaML and
driver load lines from disk, but that's arguably the common scenario to
support.
Instead of a tree of items, we now have a flat list. Each item knows its
depth. This structure is closer to what luaML's compute_layout needs.
For any future hierarchical functionality, each item still knows its
parent and replies as ids inside the metadata field.
Next step: redo A for this app. compute_layout should stay fairly
timeless across forks of luaML.
Pace layers for apps built on the box model:
A
B
...
F (I think of on.draw as F)
A runs least frequently, F runs on every frame.
In this app, the plan is:
* initialize_thread will load items inside Global_state
* A will convert items into a relatively stable box model of rows,
columns and text editors in Surface, using compute_layout as a
helper.
* B will recompute some aspects of Surface as the viewport moves.
Anything that changes the height of any box needs to rerun A. Anything
that moves the viewport reruns B.