I should perhaps namespace things somehow to keep from colliding with
other people's scripts, but I don't have a plan for that yet so I'm not
going to carve out a singl exception just for one case I ran into
myself. For now, it's a sharp edge that scripts might conflict with
internal Carousel variables. A single space of definitions has many
advantages, but also some disadvantages.
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!
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.
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)
Not quite ideal: the scrollbar computation only considers
screen_bottom1.line and not screen_bottom1.pos, and so it always assumes
the final line is at the bottom of the screen.
I'm making a deeper change here that I might come to regret. I want to
avoid creating new book-keeping for editor mutations, so I'm putting the
work of computing scrollbar data into clear_screen_line_cache. But that
implies the editor should never clear before updating data, and I caught
one place that wasn't true before. A better name helps avoid this in
future. Let's see how much toil this causes in resolving conflicts.