Check output for "libpng warning:" lines; the tool also echos
its own "test-png warning" lines about other possible concerns
(e.g. strange bitdepths, etc.) which are not necessarily going
to cause Tux Paint to echo things to STDERR.
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/
For the AppStream metadata (appdata.xml), there is a
rule saying that the summary shouldn’t end with a period
(as confirmed by ‘appstream-util validate-strict’).
For the .desktop file, *most* applications omit the period.
The rule is not language-dependent, so I have also
removed the period from all translations (.po files).
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
If you set a color, then come back to Color Mixer and immediately
dismiss the dialog (without setting a color), an indeterminate
color could appear due to uninitialized variables (new_r, _g, _b).
Closes https://sourceforge.net/p/tuxpaint/bugs/251/
h/t @kentonyanamin on Twitter
These are taken from Fedora, which replaces Art with Graphics and adds
KidsGame.
In my opinion, Art is appropriate, but so are 2DGraphics (hence
Graphics) and KidsGame (hence Game).
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.
Since gettext 0.19, gettext itself has been able to extract strings from
and merge translations to .desktop files. As a result, there is no need
to use intltool. More details are available on
https://wiki.gnome.org/MigratingFromIntltoolToGettext, though that page
assumes a project using Autotools, which this project does not.
One advantage of using xgettext rather than intltool is that there is no
need to prefix translatable keys in the .desktop.in file with _. This
patch adjusts tuxpaint.desktop.in accordingly, which makes the input
file itself a valid desktop file.
The LINGUAS file contains the list of supported languages. This could
in principle be generated automatically from one of the other places in
the source tree that has a manually-maintained list of languages; but in
my experience it is generally maintained by hand and checked into the
source tree.
POTFILES.in.in must be updated to remove the intltool-specific file
encoding annotation; instead this is passed to xgettext.
Finally, update-po.sh is rewritten to invoke xgettext and msgfmt rather
than intltool commands.
The mangling of POTFILES.in.in to prefix all filenames with '../' is
only necessary to minimize the churn when updating the .pot and .po
files, to simplify review of this change. The alternative is to pass
--directory=.. to xgettext. This would cause all .po files to be updated
as follows when regenerated:
#. Response to Black (0, 0, 0) color selected
-#: ../colors.h:86
+#: colors.h:86
msgid "Black!"
msgstr "Noir !"
614f6573e7 made this "a no-op script, for
now", in September 2006. It seems safe to assume, 16 years later, that
if it is needed it can be recovered from the Git history.
...HOWEVER, the auto-repeat of scroll buttons in the Open dialog
do not seem to work, despite the code being identical to what
I just added to New and Slideshow...!?
