Commit Graph

25 Commits

Author SHA1 Message Date
Kartik K. Agaram 6ab646a976 Merge carousel.love 2024-01-15 03:24:51 -08:00
Kartik K. Agaram a6f69931f3 Merge template-live-editor-mobile 2024-01-15 02:52:26 -08:00
Kartik K. Agaram fdc84789fc switch all handlers to run either the app or editor 2023-12-31 16:21:30 -08:00
Kartik K. Agaram dc1109202b decouple menu font from output buffer 2023-12-30 21:27:06 -08:00
Kartik K. Agaram 966f8a15bf simplify state management for menus 2023-12-04 22:09:47 -08:00
Kartik K. Agaram f1ddd6b8da hoist a temporary inside a function 2023-11-26 09:49:54 -08:00
Kartik K. Agaram 83ebcaa5c4 first draft of load/save buttons
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.
2023-11-25 23:40:28 -08:00
Kartik K. Agaram 52abeafc47 bugfix: missing variable in a button 2023-11-22 22:08:32 -08:00
Kartik K. Agaram c0253d6182 handle still narrower screens on phones
Now I only assume 'run' and 'stop' are always visible.
And there's no point wasting space on the 'code' text in that case.

I've also standardized the boilerplate on all the other buttons.
2023-11-22 19:37:30 -08:00
Kartik K. Agaram d98bc8cc7d lay out buttons based on device dimensions 2023-11-22 12:38:16 -08:00
Kartik K. Agaram 0d4500e41d Mike's suggested button layout
* No more 'clone', now that I realize we can share definitions between
  panes.
* New 'stop' button.
2023-11-21 23:11:56 -08:00
Kartik K. Agaram 76bfcba47e sliders for font size and color settings 2023-11-21 02:19:56 -08:00
Kartik K. Agaram 10e99377d5 make pane index pop a little for Mike Stein 2023-11-20 23:46:22 -08:00
Kartik K. Agaram f580e2efca add lots of buttons to the toolbar 2023-11-20 22:23:09 -08:00
Kartik K. Agaram e5e6193184 show current pane number 2023-11-20 18:19:50 -08:00
Kartik K. Agaram 5133d7c11f get rid of pane transition animations
It seems hard and is also liable to put pressure on the settings menu.
2023-11-20 07:29:38 -08:00
Kartik K. Agaram 47d38eabf2 starting to experiment with animated pane transitions 2023-11-19 17:33:22 -08:00
Kartik K. Agaram 20f95bc766 running `print` now appends to output editor 2023-11-19 14:36:42 -08:00
Kartik K. Agaram 5a998feca7 implement carousel buttons for inserting/switching current pane 2023-11-19 13:37:41 -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 e53245e62d implement 'Run' button
Error flow is still klunky. We'll need to implement the output region
for that.
2023-11-18 19:42:26 -08:00
Kartik K. Agaram 31bb55d18d bugfix: output border color 2023-11-15 13:07:01 -08:00
Kartik K. Agaram 1f272c9d39 mock up rest of menu bar and nav buttons 2023-11-15 09:02:22 -08:00
Kartik K. Agaram 28f1e113a4 start of the visual skeleton 2023-11-15 07:04:34 -08:00