scenario 1: tap on scrollbar area off scrollbar.
With the previous commit the app would crash.
scenario 2: drag down a bit, then let go, then drag the scrollbar again.
With the previous commit the scrollbar would start again from 0.
Root cause: units mismatch (pixels vs normalized y between 0 and 1)
scenario: just tap somewhere on a scrollbar.
There should be no scrolling. But before this commit there would be.
This made the scrollbars feel unstable.
I finally figured this out while noodling over a follow-up question to
the previous commit:
Why was dragging the scrollbar down ever leaving a trail of more than
just the top line's `starty`? In other words, why was my example:
line 1: 30
line 2: 60
line 3: 90
line 4: 30
line 5: 30
line 6: 30
...
..and not:
line 1: 30
line 2: 30
line 3: 30
line 4: 30
line 5: 30
line 6: 30
...
??
The answer: when I grab a scrollbar it always used to jump down!
Usability issues can either exacerbate bugs or make them harder to
diagnose. If I'd implemented scrollbars like this from the start, we'd
either never have noticed the problem of the previous commit or fixed it
much more quickly.
The active state has 2 uses:
* It gives some visual feedback that a button has been pressed.
Otherwise, tapping a button gave no feedback that the tap had
occurred. Particularly on a phone screen where fat-fingering is
easier, hitting the 'save' button in particular gave no hint that the
file had actually been saved. Which causes some anxiety.
* It suppresses all mouse taps during the activation time. For example,
this helps keep tapping say an overflow button from selecting text in
the editor.
Before this commit we were only saving settings when explicitly hitting
the 'settings' button to dismiss the menu. But clicking anywhere outside
the menu dismisses it.
I've agonized over conflicts between editor and script handlers for a
while, but finally the solution occurred to me: to use the script's
handlers, hide the editor. To use the editor's handlers, show the
editor. The menu and settings are always active. This seems nice and
consistent, easy to explain.
Mike Stein would prefer we just supported love.* handlers in scripts to
minimize special cases and cognitive load for people. But I'd rather
err on the side of being transparent about what's going on inside. As a
compromise I'm supporting love.* names at least in addition to my
rephrasings (which came about mostly because love.keychordpressed is
just too much of a mouthful)
You can either drag the scrollbar or click anywhere in the scrollbar
area.
It has this weird funkiness that the scrollbar shrinks as you get near
the bottom. But it feels.. weirdly satisfying?