New tool, "test-png", which exercises libpng library on
a set of PNG image files, allowing us to find those which
cause Tux Paint (via SDL_image, in turn via libpng) to
report back warnings to STDERR.
h/t Tim Dickson, per https://sourceforge.net/p/tuxpaint/bugs/252/
If given more than one argument, 'which' prints the path to each one (if
found). Previously, which was passed two arguments: 'xdg-icon-resource',
and 'install'. But in the contained block of statements, 'install' is
an argument passed to 'xdg-icon-resource'. Pass only 'xdg-icon-resource'
to which.
gettext 0.19.7 gained support for translating appdata files, whereas
support for metainfo files was added in 0.20. These file formats are
effectively the same: as documented in the AppStream specification,
desktop applications can install files with the suffix .appdata.xml
rather than .metainfo.xml and these will still be handled correctly.
It is desirable for this project to support RHEL 7, which has gettext
0.19.8.1, so let's use the older filename.
As noted in the same section of the specification, appdata files were
previously installed to /usr/share/appdata rather than
/usr/share/metainfo, but the spec asserts that the newer metainfo path
works all the way back to RHEL 7, so we keep the newer installation
path.
Thanks to Shin-ichi TOYAMA for flagging this issue.
https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#spec-component-location
This is used by software centres such as GNOME Software to display
information about the app, both before and after it is installed.
The <id> used here follows the recommendations in the Appstream
specification, with the exception of violating the spec's strong
encouragement to use only lowercase characters. This is because the
version that is already published by Flathub uses an uppercase T in the
final component of the ID.[0] The file shipped by Fedora followed an older
convention of using the desktop file name as the ID. This is
acknowledged by the <provides> section near the bottom of the file,
which will allow software centres to associate the reverse-domain-name
ID with the older ID.[1]
Many fields in this file are translatable. This was the motivation for
the preceeding two changes:
- By using xgettext rather than intltool, the untranslated template may
be written using the normal appstream XML tags, rather than needing to
use (for example) <_name>Tux Paint</_name> to mark that field for
translation, which renders the template not valid for tools like
'appstreamcli validate'.
- Merging translations at build time, rather than committing the
translated XML to the repo as well, avoids another potentially
error-prone manual step when updating the source file or translations.
The release notes are taken from the press releases on the Tuxpaint
website. They will be extracted for translation. Another option is to
replace the <description> with <url type="details">...</url>, but AFAIK
no software centres currently show these URLs.[2]
[0]: https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-id-generic
[1]: https://www.freedesktop.org/software/appstream/docs/sect-Metadata-Application.html#tag-id-desktopapp
[2]: https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-releases
TODO:
- align comment
Fixes: https://sourceforge.net/p/tuxpaint/feature-requests/172/
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.
Early resolution of iphone*_ARCH_LINKS calls pkg-config even when compiling for
non-ios platforms, slowing down compilation unnecessarily and possibly raise
errors about nonexisting libraries that are not used.
This change modifies the iphone*_ARCH_LINKS to resolve lazily upon use so
pkg-config is not called unless the variables are used.
Known Issues
------------
- No printing support.
- No typing support using the OS virtual keyboard. iOS needs to be signalled
to bring up the virtual keyboard when the text tool is active. We also may
need to do some finagling to make IM work with the virtual keyboard.
- OS language detection doesn't work yet.
- Quitting doesn't close the app. It just displays a black screen until it is
force-closed.
- Need to include cross-compilation instructions.
Possible Issues
---------------
- No text display. This is likely an issue with how pango and related
libraries were cross-compiled rather than an issue with Tux Paint code. From
the error output it appears to be a font rendering issue.
- SVG integration couldn't be tested because RSVG library has not yet be
cross-compiled successfully.
- Only tested under the iOS Simulator (and not on an actual iOS device yet.)
The 'Resources' directory is used in macOS development to test the binary
without building TuxPaint.app bundle, which is helpful for rapid application
development since creating the app bundle takes a long time.
It's been reported that the symlink in the Resources directory was causing the
'release' target to copy the files in the 'data' directory twice into the
source release tarball.
This change removes the static Resources directory but creates it dynamically
when the 'tuxpaint' target is built and removes it via 'clean' target so the
'release' target does not copy the files in the 'data' directory into the
source release tarball twice.
The `echo` command built into the default macOS shell doesn't understand -n.
This commit changes it to use "printf" instead which should be fairly portable
across other OS's. Feel free to change it back if it breaks anything.
