Commit Graph

5 Commits

Author SHA1 Message Date
Kartik K. Agaram 66c9f61ddc bugfix: tapping in scrollbar area
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)
2023-12-02 18:36:11 -08:00
Kartik K. Agaram 10efcfef8a UI improvement: more stable scrollbar movement
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.
2023-12-02 17:22:44 -08:00
Kartik K. Agaram 793f0daf44 bugfix: position cursor after dragging scrollbar
scenario:
  drag the editor scrollbar down more than a page
  tap near the bottom of the editor. Tapping works
  tap near the top of the editor. Nothing happens.

The cause: as you drag the scrollbar, starty gets set for lines on
screen. However, the lines going above the screen don't get their starty
reset.

Why even would any tapping work? Answer: dragging the scrollbar is
always contiguous, never random access. So when you drag a little bit,
the top line gets its starty set. When you drag a little more the next
line has its starty set. As a result, the usual pattern with the bug
was something like:
  line 1: 30
  line 2: 60
  line 3: 90
  line 4: 30
  line 5: 30
  line 6: 30
  line 7: 30
  line 8: 30
  ...

As a result, low `y`s (<90 in this made-up example) get caught in those
first few lines, but high `y`s get to the right line below.

Root cause: any time you scroll, you have to call Text.redraw_all. That
will cause `starty`s to look like this:

  line 1: nil
  line 2: nil
  line 3: nil
  line 4: nil
  line 5: nil
  line 6: 30   <== screen_top1
  line 7: 60
  ...
2023-12-02 16:58:20 -08:00
Kartik K. Agaram 809a980213 implement second, 'output' editor
Also its scrollbar.
2023-11-18 21:18:09 -08:00
Kartik K. Agaram fe8a21bea3 mouse events for scrollbar
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?
2023-11-18 05:29:07 -08:00