Commit Graph

13 Commits

Author SHA1 Message Date
Kartik K. Agaram 966f8a15bf simplify state management for menus 2023-12-04 22:09:47 -08:00
Kartik K. Agaram 42cc608d06 bugfix: only check for settings menu when open
Scenario I was seeing:
* on an Android phone
* when font size is small
* if I scrolled down a bit
* and then tapped on the editor

Then before this commit, the scrollbar would move. Even though I was
tapping nowhere near the scrollbar. Or even the settings area!

I carefully bisected this down to commit 7ca2006145 and this code in
on.mouse_release:

  if on_area(Settings_menu_area, x,y) then
    return
  end

What was actually going on in the above scenario:
* on a device with a small screen
* after I open the settings menu once
* the scrollbar overlaps the erstwhile setting menu, so that dragging
  the scrollbar doesn't trigger on.mouse_receive
* as a result the scrollbar is still active when I tap the editor.

Holy smokes!
2023-12-03 15:43:27 -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 7ca2006145 partition handlers between screen regions
This fixes one bug I know of: dragging the mouse atop the settings menu
was selecting text in the editor underneath.
2023-12-01 20:59:22 -08:00
Kartik K. Agaram 2e66d2f0fd send errors from event handlers to output editor 2023-11-21 21:22:52 -08:00
Kartik K. Agaram fc3cb96171 support event handlers
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)
2023-11-21 19:17:49 -08:00
Kartik K. Agaram 76bfcba47e sliders for font size and color settings 2023-11-21 02:19:56 -08:00
Kartik K. Agaram 740afc1036 bugfix: stop dragging output scrollbar on mouse up 2023-11-19 21:30:28 -08:00
Kartik K. Agaram e38191fc4f aggregate global state inside a 'pane' object
We're soon going to start juggling multiple of these.
2023-11-19 13:15:06 -08:00
Kartik K. Agaram 809a980213 implement second, 'output' editor
Also its scrollbar.
2023-11-18 21:18:09 -08:00
Kartik K. Agaram 065da8de04 send editor clicks to the left of the scrollbar 2023-11-18 06:03:57 -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
Kartik K. Agaram 01a8e0bb9f new fork: carousel shell 2023-11-15 06:06:56 -08:00