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.
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)
It's been reported that the latest version of Tux Paint does not run on macOS
10.7 (Lion). This change fixes the issue.
BACKGROUND
A user has reported Tux Paint 0.9.23 does not run on macOS 10.7. She also
identified that the issue is due to a system library required by Tux Paint,
/System/Library/Frameworks/CoreGraphics.framework does not exist on macOS 10.7
Some investigation revealed that CoreGraphics.framework is a library required
by libSDL, and it exists under an alternate path in macOS 10.7, underneath
/System/Library/Frameworks/ApplicationServices.framework/Frameworks/.
CoreGraphics.framework also exists underneath this path in newer version of
macOS as a symlink to the real directory as well, so the issue can be fixed by
simply relinking SDL to use the old (compatible) path instead of the new
(default) path to CoreGraphics.framework.
This change adds the code such that, during the `make install` step to create
TuxPaint.app, any library referencing CoreGraphics.framework is re-linked to
the compatible path rather than the path that only exists on the newer version
of macOS.
For more information, see:
https://stackoverflow.com/questions/20206985/xcode-linking-against-applicationservices-framework-with-sdk-10-9-causes-10-7
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.
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.
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.
Verbose logging adds metadata about when it is called and from where to every
printf call. Enable it by uncommenting both DEBUG and VERBOSE defined constants
in debug.h.
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.
Makefile for docs (used also by magic tool docs) expects
things to live in localized subdirectories now, so moved
things there.
Also, rebuilt README.txt (now en/README.txt) using the updated
README.html source.
Added documentation for "MODE_ONECLICK" and "MODE_PAINT_WITH_PREVIEW",
which were added to Tux Paint magic API 0x00000003 in Tux Paint 0.9.22)
to Tux Paint magic tool development docs.
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 :) )
Previously Tux Paint was raising an error informing the user it could not
print even when it did print successfully. This appears to be due to our
lpr printing routine's assumption that errno is reset on success whereas
the C library in macOS does not appear to do so. To address this issue,
errno is reset before calling pclose() (on macOS and macOS only - just in
case this code has an unintended side-effect on other platforms). This
code change assumes we're only interested in errno set by pclose(), and
that our lpr printing routine is not interested in errno raised prior to
pclose().
Previously, testing in macOS required running `make install`, switching
over to the Finder, then double clicking TuxPaint.app, which was a time
consuming process. This change allows the tuxpaint binary to be run
directly from the command line (./tuxpaint) without `make install`, which
makes it easier to test any small code change. Now `make install` is only
required to build the TuxPaint.app bundle for execution from the
Finder.
FYI, `make install` also builds TuxPaint.dmg for distribution. A small
change is included in this commit to allow TuxPaint.dmg to be built without
building TuxPaint.app (if, for example, you delete TuxPaint.dmg by accident
and need to rebuild it.) This is done via `make TuxPaint.dmg`.
