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.
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.
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.
Ability to bring up the print dialog from the macOS build was removed in
Tux Paint 0.9.23 to support the new build mechanism. It has been re-added.
To access it, option-click the print icon, or configure Tux Paint to always
bring up the dialog upon print.
Added function name to the output of verbose logging. Verbose logging is
the feature introduced in the previous git commit where a call to printf()
automatically adds the source filename and line from where the printf() is
called, and the runtime timestamp at which the call was made. Now this
feature adds the functio name from which the printf() is called. This
feature is enabled if and only if both DEBUG and VERBOSE are defined in
debug.h and the source is compiled with GCC.
Added a new macro DEBUG_PRINTF() that expands to printf() if and only if
DEBUG is defined in debug.h. This feature works with verbose logging if
VERBOSE is also defined and the source is compiled with GCC.
Reduced the launch time. A user reported an issue with Tux Paint taking 7
minutes to launch; an investigation showed that launching Tux Paint with
all stamps and the screen width set wide (~1500 pixels) can cause the
slowdown during the progress bar drawing sequence because progress bar
takes a long time to draw on screens with a wide screen, and it is called
~10 thousand times during the stamp loading process. The issue has been
addressed by calling the progress bar less frequently.
Updated the macOS build version and date, under which these features were
tested.
Beginning to document functions in src/tuxpaint.c, Docbook style
(description, @param's, @return). Also removed a few dead bits
of code.
Eventually, hoping to break this beastly file into pieces.
(Maybe for Tux Paint 0.9.24?)
- Replace any C++ style comments (// ...) with C style (/* ... */).
- Improve calls to fgets() to avoid "ignoring return value
of ‘fscanf’, declared with attribute warn_unused_result
[-Wunused-result]" errors (WIP).
- Removed some unused, commented-out code.
The big one we've all been waiting for -- ran indent on tuxpaint.c
(which itself is ~25K lines long, and really needs to be split up).
Hopefully the code will look less atrocious now :-)
A number of assignments of grid_dims structs were of the form of
(ignoring some carriage returns, which undoubtedly added to the
confusion):
gd_controls = (grid_dims) { 3, 2 };
which confused `indent`, causing it to think certain if/else blocks
were being ended early.
Turning these into assignments, like so, to avoid this:
gd_controls.rows = 3;
gd_controls.cols = 2;
