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.
Tweaks to icon. Further modularized how color button rendering works,
so it can handle selector (pipette) and mixer overlay icons.
Mixer function is basically identical to color picker (rainbow palette)
as a placeholder. WORK IN PROGRESS.
Also, modularize color picker's & color selector's method of
generating a fresh version of their active/inactive buttons,
after a color has been chosen by their tool.
A keyboard shortcut is now available for picking colors from
the canvas more quickly. Hold either (left or right) [Ctrl] key
while clicking, and the color selector option will appear.
Release the mouse button over a color on the canvas to choose it
(or outside the canvas to abort).
Closes https://sourceforge.net/p/tuxpaint/feature-requests/209/
Also,
* Don't play 'bubble' paint sound when color picker or selector
are aborted (e.g., via their "Back" buttons).
* Replace many instances of "NUM_COLOR - 1" and "NUM_COLOR - 2"
(which correspond to color chose via picker (palette) and
selector (canvas), respectively) with #define's that
represent them. (Avoid magic numbers.)
The pick-a-color-from-the-canvas color selection feature
(the option in the color palette showing a pipette icon)
has been extended to support an immediate mode (return on
"mouse-up" event, don't show a "Back" button, and don't animate
the appearance of the color dialog at the bottom),
which will be used by a forthcoming feature that will offer
a keyboard shortcut to bring up this color selection option.
+ Stamps are scaled before they are colorized or tinted,
to increase performance.
+ The current stamp (in its current form: size, orientation,
and color) is cached, so it may be applied to the canvas
many times without having to re-render.
(No longer scaling and tinting every time you click.)
Closes https://sourceforge.net/p/tuxpaint/bugs/147/
(h/t Andre Anckaert)
No longer restricted to "the same as other UI buttons"
(e.g., 48x48 default) or "1/4th that size" (e.g., 24x24).
Will scale, allowing for larger buttons when appropriate.
h/t Anat Caspi for pointing out the continuing issue.
Closes https://sourceforge.net/p/tuxpaint/feature-requests/212/
