More DEBUG output. Looking into having SDL_ttf open a font,
get its name, and then see whether SDL_Pango can load it.
(If not, fall back to SDL_ttf.)
That code is not working, and "#if 0"'d out, for the moment.
...such as those we seem to be receiving from _nl_locale_name()
on 64-bit Windows under newer MinGW/MSYS (see big thread on
tuxpaint-devel with reports from Shin-ichi).
Every version after when onscreen-keyboard implimented has this bug,
which first became apparent in Windows 10. (Because of more strict
memory handling or something?)
Recommend every windows user to upgrade to 0.9.26-5.
Was blindly calling thumbnail() on what came back
(which would be NULL if the image failed to load).
Also, mend bug where magic group arrays were being cleared
at the same time as stamp group ones; the latter is larger.
- Control debugging via debug.h (previously im.c had its own
defined constant to control this.)
- Remove reference to an undefined symbol im_event_fp within a DEBUG
block.
Also:
- Explicitly include i18n.h required by im.c (though it appears to be
getting included by another file indirectly.) This should be a no-op
change.
Fretwork is in one group; Blocks, Chalk, and Drip in another.
The rest do not currently report (so will not load!).
No UI change to the Magic tool interface yet.
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/
