Unlike "directional" brushes, in which a 3x3 grid representing the
8 cardinal directions (45 degree steps) is used, only a single brush
image is required, and Tux Paint will rotate it between 0 and 360 degrees,
depending on the direction the mouse is going.
The brush's ".dat" file should contain a line consisting of the word
"rotate".
Note: This adds a dependency on "SDL_gfx" library (Homepage:
https://www.ferzkopp.net/wordpress/2016/01/02/sdl_gfx-sdl2_gfx/
SourceForge project page: https://sourceforge.net/projects/sdlgfx/)
as this feature use it's "rotozoom" functionality.
WIP -- Doesn't handle animated brushes correctly yet!
Closes https://sourceforge.net/p/tuxpaint/feature-requests/122/
Always show the appropriate instructions at the bottom when the
"Fill" (depends on which sub-tool chosen) and "Shapes" (depends
on whether "simpleshapes" option is set) tools are selected
(e.g., when returning from the "Open" dialog).
Closes https://sourceforge.net/p/tuxpaint/feature-requests/186/
Ensured Tux Paint's built-in help ("tuxpaint --help"),
Unix manual ("man page"), and command-line option
tab-completion list all cover the full set of Tux Paint
options. Some were missing in a few places.
simulate_flood_fill_outside_check() could spin in an
infinite loop because it could sometimes set values in the
`touched[]` array to 0, which means the spot was never seen.
Values going in there are not boolean, but a 0-255 gradient,
for smoother fills on antialiased edges.
This change forces it to be a 1-255 value, ensuring that
a 'touched' spot on the canvas will have a non-zero `touched[]`
value.
h/t Pere for noticing the bug, providing some details,
and best of all providing a sample image to play with which
consistently invoked the crash. (It made mending this a
10 minute task for me, rather than an hours-long hunt to reproduce!
Big 'thanks' for doing that ahead of time!!!)
