While we weren't attempting to save thumbnail PNG files of the
starter and templates that are scanned in the system-wide Tux Paint
directory, we WERE trying to incorrectly `mkdir` such directories
within the user's personal directory.
(e.g., "/home/kendrick/.tuxpaint//usr/local/share/tuxpaint/templates")
Mended.
Avoid shapes flipping upside-down during rotation step,
when stretching from right-to-left -- also when using the
original, center-based shape stretching mode.
Keyboard's goal is to not be > 90% of the width of the drawing
canvas. Was misinterpreting the incoming argument ('canvas'),
so have to account for the toolbar (left) and selector (right)
buttons in the UI.
So e.g., `tuxpaint --900x768 --onscreen-keyboard` will use the
small keyboard buttons, while `... --1024x768 ...` will use the large.
On-screen keyboard (visible when the feature is enabled, while
using the "Text" and "Label" tools) now appears with larger
(48x48 pixel, vs 24x24 pixel) buttons, when Tux Paint's window
(or fullscreen) size is large enough to fit them with the
chosen layout.
(h/t Anat & Aviv, who suggested it to help with users of
eye-tracking systems)
Also, on-screen keyboard buttons use a slightly larger font
(16pt vs 12pt, previously seen on the small keyboard;
32pt on the large keyboard).
(h/t Jackson Bray for the suggestion)
Also, slight improvements to how circular eraser size calculations
are handled, to allow for radius down to ERASER_MIN of 5.
Adding control buttons to the Shapes tool, allowing for shapes
to be drawn from the center (as before) or from a corner
(more like other paint packages). The controls do nothing
at this time, but are visible and can be clicked. This is a
work in progress.
The controls may be removed using a configuration option.
Tux Paint can export an animated GIF to the export directory
(e.g., ~/Pictures/TuxPaint) from the Open->Slideshow dialog.
To do -- GIF's animated speed should be based on speed slider
in Slideshow dialog.
To do -- Document this new feature (and single image (PNG) export)
in the README documentation.
i18n code was checking for local-related environment variables
(e.g., "getenv("LANGUAGE")") coming back as a NULL if unset.
However, on my laptop, under Kubuntu 20.04 with GLIBC 2.31, a
"LANGUAGE" env. var. is set, but it's blank.
Tux Paint failed to attempt any fallback (e.g., checking "LANG")
in that situation, which was causing the description text corruption
that was corrected in a previous commit.
That commit also mistakenly suggested that the issue might've been a
difference with GCC versions, but the problem was deeper in Tux Paint's
code (in i18n.c), and was triggered by an unexpected environment.
WORK IN PROGRESS -- Attempting to mend an issue where stamp descriptions
are not loading.
Also, making things safer when a problem occurs.
Using gcc 9.3.0 compiler, this was happening in 0.9.25 during
development, but also affected 0.9.24 and 0.9.23, which worked
fine under earlier versions of gcc.
