When reading label text (on non-Windows, at least), fscanf("%lc")
was being used. It seemed to be skipping the initial space,
causing strings to be shifted left one, and end up with garbage
bytes at the far right.
Fixes https://sourceforge.net/p/tuxpaint/bugs/247/ I hope!
"Apply Label" mode of Label tool can be activated/deactivated,
though it doesn't currently do the work yet.
Also
* Modularized routine to select a Label (via click or [Enter] key):
`select_label_node()`
* Starting routine for applying a Label to the canvas
(via click or [Enter] key): `apply_label_node()`
* Modularized routine for repositioning the on-screen keyboard based on
where we're typing: `reposition_onscreen_keyboard()`
Seems likely that I broke some things.
Starting work towards
https://sourceforge.net/p/tuxpaint/feature-requests/213/
The ability to 'apply' a label to the canvas, making it permanent
(as if added using the "Text" tool instead).
Removed unused "label rotate" option's code (and hence addressed
a bug we didn't relalize when choosing the "Label" tool while in
in "--nostampcontrols" mode; the unused "rotate" button would appear).
Show tips when choosing brushes, to remind the user when they
are animated, and or rotational/directional.
Show tips when brush spacing is changed, specifying the approximate
spacing. Output is fuzzy, to avoid being overly technical (e.g., it
will never say "2 345/1000 times as big as" or "1/103 the size of")
Occasionally running Tux Paint in Korean, Japanese, and possibly other
languages would cause Tux Paint to crash. This commit fixes it.
This bug was previously mentioned as the possible cause of these
previously reported crashes, though they were determined to be
unrelated:
https://sourceforge.net/p/tuxpaint/mailman/message/37364981/https://sourceforge.net/p/tuxpaint/mailman/message/37376574/
The cause of the crash turned out to be in the function that loads the
input method map (*.im). Some languages that use more than one
keystroke to produce one unicode character use this mapfile to track, in
a state machine, what keys have been pressed and what unicode character
should be output. This state machine's memory is increased dynamically
as needed when the input method map file is loaded. There was a line of
code that references the old memory that could have moved by the memory
increase. This line of code has been moved to prior to the memory
increase to avoid accessing memory that may have moved.
It appears the system language detection doesn't work on [some versions
of?] macOS. Fixed.
Strangely, querying the Cocoa API for the system locale on a system in
US with the preferred language set to Korean produces the invalid locale
"ko-US" instead of the expected "ko-KR". This behavior of returning the
language with a invalid region qualifier for the language appears to
happen only with languages where macOS does not have regional variants
(this issue does not seem to occur with Canadian English, en-CA, for
example.) A fuzzy matching locale function has been added to handle
this issue.
Under Xcode with clang, Mark Kim was getting an error:
src/tuxpaint.c:23125:44: error: use of undeclared identifier 'i'
SDL_MapRGB(img_color_btns[i]->format,
^
Oddly, I was not getting errors no matter what nonsense I put
in there (e.g., changing "->format" to "->formatXYZ"), under
"gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)"
When looking up paths of fonts, preferences, etc., macOS searches two
places, the system paths and the user paths under $HOME.
This change handles rare scenario where HOME is not set. If HOME is not
set, now the application just searches the system path twice instead of
searching the system path followed by going into an undefined behavior
(possibly segfault.)
Forgot to wrap the color mixer's tip text printf() format string
in gettext(), which caused the static part of the text
("Your color is...") to not be translated. h/t to Shin-ichi for
pointing it out.
Say a color is a mix of 5 red, 4 blue, and 1 black.
It will show "5/10 (1/2) red, 4/10 (2/5) blue, 1/10 black."
Also, when adding multiple contributions of only one color (so far),
it will say, e.g., "entirely (3/3) red".
Rather than having a "current color" and averaging it with
the newly-added color, averaging the entire set of colors each time.
Before, if you added R + Y + B, you'd get a different color
than R + B + Y, or Y + B + R, etc.
Now, it starts fresh every time and averages the hues (when applicable),
saturations, and values of each color that's been added to the mix.
R + Y + B (combined in any order) currently always comes out a brownish
orange, as expected.
Show the color proportions (e.g., "entirely red", or "1/2 yellow and 1/2 green",
or "1/5 red, 2/5 blue, and 2/5 black") in the Tux tips area. Show the full
instructions again when the color is reset with the clear button.
(Also, label clear (trash) button with the word "Clear".)
Adjust HSV values for Red/Yellow/Blue. When drawing color,
drop V value very slightly (so white appears off-white).
Undo & Redo now have black icons/text if available, else grey.
