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.
Created "safe_" variations of 'strncpy()', 'strncat()',
and 'snprintf()', to ensure a truncated source string doesn't
leave the destination buffer without a NUL termination character.
Replaced all calls (in "tuxpaint.c" only, so far) to the standard
functions with calls to the new safer versions.
Replaced most calls to plain 'strcpy()', 'strcat()' and
'sprintf()' (which can cause buffer overruns) with the new functions.
From "Open" dialog, select an image (single click, or use
arrow keys / etc., to highlight the image), then select the
"Export" button at the lower right.
The image will be saved in the export directory. By default
this will be based on the config found via the XDG_CONFIG_HOME
environment variable, which is scanned for a "XDG_PICTURES_DIR"
setting. If none is found, "Pictures" in the directory specified
by the HOME env. var. will be used. In both cases, a new
"TuxPaint" subdirectory will be created, and exports will be placed
there.
The export location may be overridden using the "--exportdir"
command-line option or "exportdir" config file option
(e.g., "--exportdir /path/to/dir" or "exportdir=/path/to/dir",
respectively). In this case, the directory is assumed to preexist,
and no "TuxPaint" subdirectory will be made.
There's currently no way to disable the export feature altogether.
If there's demand, we can add it as a simplification option.
Finally, this feature simply copies the PNG file (but no extra
data files) from Tux Paint's "saved" directory to the export dir.
Closes https://sourceforge.net/p/tuxpaint/feature-requests/192/
Using XDG's user dir settings to determine where pictures are
stored for a user (e.g., "~/Pictures" -- used as a fallback).
May be overridden using "--exportdir".
Also, while I was updating some docs, replace references to
"Mac OS X" with "macOS", the new name of that OS these days.
Beginning addition of an option to export animated GIFs
from the Open -> Slideshow dialog, after choosing the images.
Non-operable at this time, but a button has been added (and will
provide a hint to select 2 or more images, when clicked).
TOYAMA Shin-ichi noticed that when building for Win32 under mingw/msys,
an #include of "librsvg-cairo.h" was also necessary.
He also bumped the version # in win32/resources.rc
(and I put his credit in there).
I updated docs/RELEASE.txt to mention that .rc file also needing
updated when preparing a new release.
Wrapped some debug output in "#ifdef DEBUG" tests,
and made sure some warnings and errors were going to
STDERR, rather than STDOUT.
Motivation: Less noise while launching/using Tux Paint,
unless it matters.
Replaced KDE (older, KDE4, in fact) specific icon and
launcher (.desktop file) installation & uninstallaton
invocations in Makefile with those that use Freedesktop.org
`xdg-...` tools.
Ability to disable stereo panning effect (e.g., paint brush, UI
elements sound effect feedback, etc.), useful for users with
hearing impairment in one ear, or situations where one speaker or
headphone is being used. Use "--nostereo" command-line option
or "nostereo=yes" config. file option.
The thumbnails for starters & templates are NOT being re-generated
when the source images are modified -- only when the thumbnail is
missing. Needs an update to the target's prerequisites
(but I'm very rusty with this level of Makefile magic).
Also, update some Starter source images so they work better with
flood fill (Bald Eagle, World map, Gecko).
"Fill", as a new main-toolbar tool, was not recording snapshots
of the image for the "Undo" tool. Mended.
However, also updated the tool so that it doesn't _bother_ recording
into the undo buffer if the fill action is a no-op (e.g., clicking
the same spot a second time, or otherwise attempting to fill an
area with a color that's identical to what's already on the canvas).
Also generating and installing thumbnails of Template images,
thus getting "New" dialog to open extremely quickly.
(Pretty much "instantaneously" on my 8 year old laptop with
Intel i3 @ ~2GHz and Intel 320-series SSD (214 MB/s).)
Providing better command-line args to ImageMagick `convert` to
produce nice-looking thumbnail PNGs of Starter images.
(N.B. - I'm using "ImageMagick" Version: 8:6.9.7.4+dfsg-16ubuntu6.7)
Replace the somewhat-recently-added "nothing" item in the tool bar
with the "Fill" tool, which has been converted back from a Magic tool
to a regular tool.
Also, change bash "==" to sh "=" in "if [ ... ]" tests in Makefile.
Also, link to math library (via "-lm") to make sure "max()" is available to
magic tools.
Also, add missing mention of "--newcolorslast" and "--newcolorsfirst" to manpage.
Respond to a SIGUSR1 or SIGUSR2 signal by configuring itself
for autosave, saving a new file, or overwriting the current,
respectively, and sending itself a SIGTERM (which _generally_
causes Tux Paint to quit, depending on where you are in the UI).
Closes https://sourceforge.net/p/tuxpaint/feature-requests/188/
New option to place color palette items at the end of the "New"
dialog, rather than at the beginning. Useful for when users
would want to pick from a set of Starters and/or Templates,
e.g., in a school or museum environment.
Available via command-line option "--newcolorslast", and
config file setting "newcolorslast=yes". (And anti-option to
override config file settings, "--newcolorsfirst" and "...=no",
which represents the original behavior, which continues to be
the default).
Suggested by Bernard Verhaeghe.
Bumping to 0.9.24; going to add a new feature momentarily.
Improved usage output (e.g., that of "tuxpaint --help"); broke
the options into groups that match the tabs in Tux Paint Config.,
added some missing options.
They're in a new location over on John P.'s website
(should we purhapse integrate them into Tux Paint proper?)
(h/t sechidis & whoever on #tux4kids IRC channel who helped them)
Documenting Mark Kim's recent changes:
* Less CPU-hungry progress bar (during Stamp loading)
* Verbose debugging options
* (Also, mentioned debugging _at all_, in INSTALL.txt)
Bumping version to 0.9.23a, to match the test build he's working
on for macOS.
I forgot to make sure macos/Info.plist had the latest version # and
release date, before tagging and releasing source code. Adding a checklist
of places to double-check for properly-updated version #s and/or release dates.
No longer saying "By Bill Kendrick", since so many more people
have added so much to the project over the years.
(I'm basically website maintainer & project manager these days :) )
