Final couple of tests to let us avoid creating a template that's
identical to one that already exists. All told, we test the
following (and the first thing that matches causes us to stop
testing that template, and move on to the next, as it appears
to not be identical to the saved image, in its current state)
+ filename prefix (based on saved image's filename)
+ file size
+ image dimensions
+ image contents (via CRC)
Avoid exporting a saved picture to a new template if one already
exists with both the same filename prefix, and now also identical
file sizes (in bytes).
Bugfix - The export function was always dumping chunks that
were the size of the input buffer, which means the final chunk
(which will frequently be smaller) will contain garbage data
beyond the end.
...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.
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.
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.)
Was redrawing color toolbar _before_ changing the chosen color
to be the pipette tool.
Reproducing the bug - Select a built-in color, Ctrl+click in the canvas,
observe built-in color still appears chosen [the bug], paint with e.g.,
paint brush, observe it's using the correct, pipette-selected color,
not the one that appears chosen [this is correct].
Motivation - Without SDL2_Pango, languages like Japanese,
Arabic, and Thai do not render properly. Currently, Debian
(and hence Ubuntu) do not have SDL2_Pango, so Tux Paint 0.9.28
is adversely affected. Fedora DOES have SDL2_Pango, so works well.
This also allows us to delete a lot of ancient cruft code.
Closes https://sourceforge.net/p/tuxpaint/bugs/268/
h/t Pere
(INSTALL docs to be updated momentarily)
This seems to allow me to specify which display (monitor) to make
Tux Paint appear on my two-monitor set-up (laptop + external monitor)!
Closes https://sourceforge.net/p/tuxpaint/bugs/277/
Stalk color not matching leaf & base is more obvious at larger sizes.
Base, petals, and leaf bitmaps need to be drawn (just scaled up, and
made blurry, for the moment).
