scenario:
delete config from save dir
run the app
quit
run the app again
After the stupid typo in the previous commit the app was stuck emitting
errors during the second run.
Renamed from the 'error' state.
Now we no longer overload Error_message; it's only used for actual
errors that trigger opening the source editor.
I was tempted to hide Skip_rest_of_key_events inside the 'warning' state
as well, but that isn't right. It applies to all Current_app
transitions, not just those in and out of 'warning'.
I'm starting to feel better after replacing 1 line with 20 and 2 new
bits of global state. I'm now handling two scenarios more explicitly:
* If I change Current_app within key_press, the corresponding text_input
and key_release events go to the new app. If it's an editor it might
insert the key, which is undesirable. Putting such handlers in
key_release now feels overly clever, particularly since it took me
forever to realize why I was getting stuck in an infinite loop.
* Both 'run' and 'source' can hit the version check, so we need to be
able to transition from the 'error' app to either. Which
necessitates yet another global bit of state: Next_app.
Changes inside on.initialize are minefields. Until now, if you made a
mistake when modifying on.initialize, you could end up in a situation
where the app would fail irrecoverably on the next startup. You'd have
to go dig up a text editor to fix it.
After this commit, errors in on.initialize wait for commands from
driver.love just like any other error.
Recovering from errors during initialization is a little different than
normal. I don't know how much of initialization completed successfully,
so I redo all of it.
I think this should be safe; the sorts of things we want to do on
startup tend to be idempotent just like the sorts of things we do within
an event loop with our existing error handling.
Things are still not ideal. Initialization by definition happens only
when the app starts up. When you make changes to it, you won't find out
about errors until you restart the app[1], which can be much later and a
big context switch. But at least you'll be able to fix it in the usual
way. Slightly more seamless[2].
One glitch to note: at least on Linux, an app with an initialization
error feels "sticky". I can't seem to switch focus away from it using
Alt-tab. Hitting F4 on the driver also jarringly brings the client app
back in focus when there was an initialization error. But the mouse does
work consistently. This feels similar to the issues I find when an app
goes unresponsive sometimes. The window manager really wants me to
respond to the dialog that it's unresponsive.
Still, feels like an improvement.
[1] I really need to provide that driver command to restart the app! But
there's no room in the menus! I really need a first-class command
palette like pensieve.love has!
[2] https://lobste.rs/s/idi1wt/open_source_vs_ux
In particular, I want to be able to switch to 'error' mode rather than
throw a real error() on test failures, because that's a little more
responsive and might be recoverable. (On some Android devices the font
is slightly different, and tests fail as a result.)
To do this I need some support for multiple versions. And I need an
'error' mode to go with existing 'run' and 'source' modes
(`Current_app`). Most errors will automatically transition to 'source'
editor mode, but some errors aren't really actionable in the editor. For
those we'll use 'error' mode.
The app doesn't yet work with LÖVE v12. There are some unit tests failing
because of differences in font rendering.
Error_message is a special global. It's set when the app (Current_app = 'run')
encounters an error and switches to the source editor, and cleared when
switching from source editor back to the app.
Kartik K. Agaram