This will make it possible to load localization data for a language
defined by a command-line argument, throughout the program.
Unfortunately this separates the usage of the arguments from their
definitions by a wide margin, making it harder to edit, especially
with AI autocomplete. For now. I could refactor things, either move
the bulk of this file to separate files, or define a configure_app
function up top to use down below.
Giving up on the python translation of the RC file parsing and pre-processing for now, in favor of simply parsing the JS files already generated, which is a much simpler task.
- Confirm discarding changes for Open, New, or Exit, including for
exit via Ctrl+C which was previously handled by a built-in binding.
- Await Save As dialog closing, including when Save triggers Save As.
This is my first time using asynchronous features in Python,
(as far as I remember,) so it's a bit messy.
- Make DialogWindow callback also for Cancel, which means all
DialogWindow usage sites care what button is selected.
- Send RequestClose event for Esc key.
It took a while to figure out this magic.
`textual run --help` says:
> If you are running a file and want to pass command line arguments, wrap the
> filename and arguments in quotes:
>
> textual run "foo.py arg --option"
But it doesn't describe how to handle those arguments.
It's a bit verbose, but for Open, I wanted the _dialog part since "open"
can be both a verb and an adjective, and I didn't like it reading as an
adjective. It doesn't technically disambiguate it, but it reads better.
Verb "[to] open", noun "[dialog to] open", adjective "[part of the dialog to] open"
Adjective "[is] open", noun "[dialog that is] open", adjective "[part of the dialog that is] open"
Anyways this commit just makes it consistent.
Perhaps I could use classes more in place of IDs.
