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.
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.)
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/
Magic Controls (paint vs fullscreen) and Sizes (coming soon)
can be enabled/disabled independently, and the list of Magic tools
sizes itself accordingly.
On touch devices, the color pipette tool could easilly be
immediately dismissed due to the 'button up' event happening
right where the "Back" dismissal/cancel button appeared.
Now only pays attention to 'release' if the button was down.
(h/t Pere for reporting this)
On my laptop the prompt was basically not coming up at all
(only one animation step every few seconds), because apparently
it was stuck doing "w += 0" due to how few ticks went by within
the loop! :-D
We'll end up with things like "132/245 red, 90/245 yellow, 23/245 blue".
Getting it to work will likely require some massive brute-forcing.
If people want to take an existing color and make subtle changes, they
can just use the rainbow palette HSV color picker.
More sensible rotation when using the drag-from-corner mode
(rotates around center of the shape, as you'd expect, rather than
around one of the corners of the shape's bounding box, as it has
been doing all this time).
Stretching a shape from bottom to top causes an upside-down shape
(e.g., before, a triangle would always start out up-pointing
regardless as to whether you clicked and drag downwards or upwards;
now, it will start out down-pointing if you drag upwards when
initially placing & stretching the shape).
...deactivate all code for this within color mixer, since it's
not actually implemented yet (going to be tricky! -- probably
holding off to a future version).
Also, sound effect for cross-color grabbing within rainbow palette
dialog.
