...based on saved files. So far, only looking for identical
template prefix (which is based on the save file's filename).
Next will be to check other fingerprints, in case the saved file
changed after an earlier template was created.
Example
mkdir /tmp/tp
tuxpaint --datadir /tmp/tp
without this fix, choosing "Template" (make a new templat)
from "Open" dialog would result in an error, since
`/tmp/tp/templates` did not exist.
We now `mkdir()` it. This requires, of course, that the
directory specified by `--datadir` _itself_ exists. (We will
not attempt to create anything higher up.)
Places where we attempt to save thumbnails of starters & templates
was trying to `mkdir()` a `.thumbs/` subdirectory in non-existent
`starters/` and `templates/` subdirectories of the "savedir"
location; should be the "datadir" one.
To replicate
mkdir -p /tmp/tp/starters
cp SOMEFILE.png /tmp/tp/starters
tuxpaint --datadir /tmp/tp
then click "New"; observer the warning
Error: Couldn't save thumbnail of saved image!
/tmp/tp/starters/.thumbs/SOMEFILE.png
The error that occurred was:
No such file or directory
When specifying "datadir", Tux Paint's "New" dialog
was able to present templates found in that directory,
but would attempt to load from whatever the user's
"savedir" was, instead.
h/t Giancarlo Orru for reporting the bug.
https://sourceforge.net/p/tuxpaint/feature-requests/238/
h/t Pere for the suggestion
Needs to support color, thickness (size controls), and have
a round brush shape (anti-aliased would be nice, considering
the objective is smoothness ;-) )
Was failing to compile on Haiku for Luc (apparently building with
no SVG support), since I started using that function outside of
SVG-related places.
Also, to continue being able to compile on Linux with no SVG support --
* Always use SDL_TRUE & SDL_FALSE, not TRUE & FALSE
* Always link tuxpaint with "-lm"
Finally, verbose version info ("tuxpaint --verbose-version") now states which
SVG build (new RSVG or old Cairo)
I noticed that buttonsize=90 or =91 would end up with UI buttons
images ere one pixel smaller (89x89 or 90x90, respectively) than
expected, hence they layout would end up with one row and one
column of unused pixels between them. Any button content (e.g.
stamp thumbnails) that might render into the full size would end
up leaving garbage pixels behind.
Applying ceil() to the new_x and new_y (but then making sure they do
not exceed the requested max_x and max_y) calculated sizes inside the
thumbnail2() function. (We do not simply use max_x and max_y directly,
because we are usually trying to maintain the original image's aspect
ratio.)
