Previously, both the .desktop.in template and the final .desktop file
were checked into source control.
While in some ways convenient, the manual step of updating it may be
forgotten after updating a translation or adjusting the template. It
also potentially introduces confusion as to which file to modify.
Instead, generate the .desktop file at build time. Since this is now
done using msgfmt rather than intltool, there is no additional
dependency beyond gettext, which is already used at build time to
compile .po files to .mo files.
1. Building the DMG file now requires explicitly calling the 'make
TuxPaint.dmg' target.
2. Messages output after completing a Makefile target has been
customized on macOS.
The motivation here is Apple Silicon. With the instruction of Apple
Silicon, the porting developer may need to sign the app bundle and/or
create the app bundle as universal before creating the DMG file, so the
Makefile no longer auto-creates the DMG file. Instead, macOS-specific
messages have been added so the developer knows what to do next.
Adding snapshot of (basically untranslated) Magic tool docs
in the other locales currently supported by 'tuxpaint-docs'.
Update Makefile to install them.
All old, outdated, manually-generated translations of docs now
go into an "outdated" subdirectory. The "tuxpaint-docs"/gettext-based
ones are the "first-class citizens".
Don't install the docs directory's "Makefile", or the instructions
for how to release Tux Paint, as those are not necessary to end users.
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/
The Makefile variable "HOST" was introduced to cross-compile Tux Paint
for iOS. Unfortunately this variable is often set at the environment
variable level on many Linux distributions so it can cause the Makefile
to think it is attempting to be cross-compiled when that is not the
intention.
This change modifies the Makefile so it attempts to cross compile only
when both HOST and HOSTROOT environment variable (which are both
required for cross compilation) are set.
Luc Schrijvers reported on the Tux Paint Maintainers mailing list an
failure to build magic tools for Tux Paint 0.9.26 rc1 (see the mailing
list for the details). The issue appears to stem from an interesting
interaction between my commit from March
(39cc096ece) and the quotes around
beos_PLUGIN_LIBS on line 1361:
beos_PLUGIN_LIBS:="$(MAGIC_SDL_LIBS) $(MAGIC_ARCH_LINKS) $(MAGIC_SDL_CPPFLAGS)"
My commit had removed a leading argument from $(MAGIC_SDL_LIBS) (whose
value is irrelevant but it was "-L/usr/local/lib"), and the second
argument resolves to nothing on Haiku, so beos_PLUGIN_LIBS now resolves
to a string with a leading space, and it appears `cc` treats a string
argument with a leading space as a single token as opposed to a list of
arguments as it was apparently doing previously. Pere confirms removing
the second argument that resolves to nothing allows binary to compile.
I suppose removing the quotes around beos_PLUGIN_LIBS is another (and
cleaner) possible solution, but the quotes appear to be intentional and
without a Haiku build environment to test the exact behavior this will
be the safer commit to make.
