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.
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/
GIF export button now jumps to a process that iterates through the
chosen saved images, loading each (but not yet saving as a GIF).
It then returns to the Open->Slideshow dialog, and displays a
pop-up dialog that shows a success/fail message.
Also, adding an icon for a regular static image "Export" option,
to be added to the main Open dialog.
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.
Manpage still showed that "--fullscreen" (with no value) could be
specified. Lately, it requires =yes, =no, or =native.
For https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769368
Also, remove a duplicated credit from the contributor list.
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.
"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).
I cannot recall[*] why we disabled the steps to generate thumbnails of
starters (".thumbs/STARTERNAME-t.png") and install them in the system
directory (e.g., /usr/local/share/tuxpaint/starters/.thumbs/),
but every time one goes to create a new image ("New"), it took a very
long time to show.
[*] If anyone remembers ~a decade ago, and has a good reason, let me know!
Also, remove "Makefile" as a prerequisite for some targets; if anything
major changes in there, it's expected one will run "make clean" or
remove the binary/etc. target and rebuild. (Rebuilding "tuxpaint.o"
every time I edited something unrelated in Makefile was really annoying :) )
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.
A word-wrapped line of code using an array to access a
function was confusing `indent` (causing it to change back & forth
everytime `indent` was invoked!)
Cleaned it up and wrapped in /* *INDENT-OFF* */.../* *INDENT-ON* */
to prevent further confusion.
Some commentary lines kept increasing indent every time
`indent` was ran!? Wrapped in /* *INDENT-OFF* */ ... /* *INDENT-ON* */
to prevent this, and mended them.
