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.
A Textual layout bug is unfortunately making the Yes button HUGE,
and the No button INVISIBLE, until you mouse over the dialog, which is
pretty funny...
"<file> already exists. Do you want to replace it? [Yes]"
These are pretty good candidates, paired together.
For the Free-Form Select icon (⢼⠮), I'm specifically imitating the
asymmetrical star shape from MS Paint.
* Implemented the Fill With Color tool using the algorithm described as
"combined-scan-and-fill span filler" on Wikipedia.
* I added handling for the affected region being None, which turned
out more complicated than I would like...
Some cases may be able to be simplified or removed.
* Also, I moved event.stop() to the top so I don't need to call it in
multiple places when there are multiple return points.
You could imagine having a brush with momentum, that swings around the
mouse without always reaching it. But it's just generally clearer to
not have an inadequate initial region that's then extended.
I mean, let's be honest, most of these symbols are garbage candidates.
But these ones I accidentally left from trying to get ChatGPT to find
emoji for me.
More helpful were https://emojidb.org/ and http://shapecatcher.com/
I wanted to avoid duplicating tool-related state between PaintApp and
Canvas, and prepare for adding different tools with more state and which
will want to live in a separate file.
This makes it slower, when running with `textual run --dev paint.py`;
when running with `python3 paint.py`, it's fine.
When running in dev mode with `textual console` devtool connected, it's
extremely much slower. But if it was faster, you'd have more messages
to scroll through, ha. So it's a tradeoff.*
*Ideally you want it to be fast and for the logs to be compacted.
In the future, I could bypass the message system for performance, but
for now I think it's better to stay idiomatic.
- Remove scrollbar from root
- Fix extra height below color palette due to vertical layout giving even heights
- Add container around canvas to make canvas scrollable
