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.
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`.
Previously `make install` on macOS created TuxPaint.dmg, but it was a
simple disk image.
Now TuxPaint.dmg is formatted as one would expect from any other macOS app,
with a Tux folder icon, symlink to the /Applications folder, and a
background image with an arrow.
* Added "--joystick-dev" option, for specifying which joystick device
Tux Paint should listen to
* "--joystick-dev list" is now used to list the available devices
* Cleaned up some 'usage' output
mouse accessibility mode (which introduced issues with tools like
'Flower' and 'Fold' (which show previews) and 'Ripples' (which doesn't
involve any dragging)).
even when FORKED_FONTS is not set.
* No longer undef'ing SDL_thread stuff when FORKED_FONTS is
used if we're ALSO not using SDL_Pango, since that now
uses a thread to let fontconfig generate its cache, and
still let Tux Paint be responsive to the OS and user.
(SF.net bug #2944951)
* Spawning a thread and rendering a dummy string with SDL_Pango,
to allow fontconfig to generate its cache.
(SF.net bug #2944951)
* Setting up 'busy' mouse cursor (watch-shaped) earlier
(so it can happen while fontconfig cache thread runs).
* Not spawning forked font scanner (FORKED_FONTS) as early, so
fontconfig can generate its cache first.
(I wasn't sure if calling an SDL_thread after a fork()
occured was safe or not; admittedly, I discovered that
SDL_thread spawning wasn't working due to the re-#defines
of those functions when FORKED_FONTS was set; see above.)
All of this only tested on Ubuntu 9.04. Forced disabling of FORKED_FONTS
by editing fonts.h, and Tux Paint still worked (it just took longer at
the splash screen while the fonts were loaded). Needs testing on various
Windows, Mac OS X and BeOS.
