I don't want to bother importing Rich's Color class in addition to
Textual's Color class.
This also doesn't work, which might be the fastest if it worked:
style.color.triplet.red = 255 - style.color.triplet.red
style.color.triplet.green = 255 - style.color.triplet.green
style.color.triplet.blue = 255 - style.color.triplet.blue
style.bgcolor.triplet.red = 255 - style.bgcolor.triplet.red
style.bgcolor.triplet.green = 255 - style.bgcolor.triplet.green
style.bgcolor.triplet.blue = 255 - style.bgcolor.triplet.blue
It's a bad idea, unless applied on a case-by-case basis.
It makes things wrap badly when the viewport is narrow, making things
much less readable, even though the aim is to make it more readable
by ensuring visibility. And it makes message boxes feel less OS-like.
It's better to have to drag a window back and forth to read it, than
to have it wrap at every character.
- Don't log an error about a missing language file at startup.
- Don't append to untranslated.txt for strings that don't need
translation because they're already in the target language.
I could use an early return for this too, but it's not important.
I'm new to python package management, so I don't really know when these
packages got updated, but I'm updating this file with this command:
python3 -m pipreqs.pipreqs --ignore .history --force
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.
