Just checking mouse.isDown works if the editor is the entirety of the
app, as is true in this fork. However, we often want to introduce other
widgets. We'd like tapping on them to not cause the selection to flash:
https://news.ycombinator.com/context?id=38404923&submission=38397715
The right architecture to enforce this is: have each layer of the UI
maintain its own state machine between mouse_press and mouse_release
events. And only check the state machine in the next level down rather
than lower layers or the bottommost layer of raw LÖVE.
This change needs to get backported to all the other forks. We want to
retain the ability to draw other UI elements in our apps, and that means
we can't always assume that a mouse press and mouse release will happen
together. Instead, each layer should manage its own state machine, and
only check for events from the immediately lower layer.
This idea generalizes commit c3cdbb52a.
Problem: on mobile devices, tapping on the editor causes the selection
to flash for a second. It looks like there's a longer time between mouse
press and release events.
Scenarios tested with this change:
* click on the editor to move the cursor
* drag-select using the mouse
* shift-select using keyboard
* shift-click to select
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.
Some considerations in the design so far:
* Desired flows:
* start typing into a new pane, then save to a filename
* load from a filename, then continue typing/running
* save as a second file
* Should we autosave? I think not yet, because my editor's undo/redo
functionality is not accessible yet on mobile. Android devices can't
press 'ctrl', and the hotkeys aren't very discoverable.
(I considered menu options for 'undo' and 'redo', but they won't be
very ergonomic because my undo/redo functionality is primitive and
doesn't support grouping similar operations. Now you're stuck tapping
'>>', then 'undo' and losing one character. Then the menu closes and
you have to do it all over again.)
Another knock against autosave on mobile: autosave on quit is
unreliable. At least on my Android devices, LÖVE doesn't trigger
love.quit when you swipe away an app. iOS of course has no such notion
in the first place.
* Menu buttons take up space, and I'm loath to expend 2 more buttons.
However, I don't see a good alternative:
* We can't use a single button to bind a filename to a pane until we
get autosave.
* Save on run? It doesn't save a button, but maybe we can keep 'save'
up top because we'll want to keep hitting it in the absence of
autosave. However, I don't want to lose data just because I started
typing out a long program that never got to a runnable point.
* I'd like to keep 'save' always up. But newcomers might have more
trouble finding things if load and save are separated from each other.
Seems like the sort of thing Mike complained about before the current
button organization.
==> conclusion: no autosave, 2 buttons, load and save
* I want to follow MiniIDE and only save to a single directory (no
subdirectories, even). Simplifies the file dialog.
* Where should this directory live? Source base risks growing really
large and unwieldy over time as we share files between lots of LÖVE
apps. At least, Mike has that problem. Save dir is utterly
inaccessible to other apps -- including later versions of this one.
Once you delete one version of an app (say before installing a new
version) the only way to find your files is to wade through lots of
cryptic directories inside source dir. And you'd need a new LÖVE app
to do that.
==> conclusion: save to a fixed subdir of source base dir. That way only
Lua Carousel will save there, but different versions share a common
space.
* Should examples be savable? If yes, we could have conflicts. If no,
it feels like a gotcha when someone starts editing an example.
==> conclusion: allow examples to be saved, but that creates a new copy
of them on restart. It'll be weird that the order changes, but seems
like the best option.
* Where to show the current filename? I don't want to further reduce
space for buttons. A smaller font seems necessary here to squeeze the
filename into an interstitial of the UI.
Still to do: providing a non-existing file to load/save. I plan a
command palette UI for filtering or selecting a new file.