See the commit 28467cb on the gimp-data-extras repo where I moved this
data in. Not sure why this metadata file was ever pushed to the main
repo as it is obviously for the data-extras package (or else I am
missing some information!).
The old 2017 report where it was originally added:
https://bugzilla.gnome.org/show_bug.cgi?id=763398
appstreamcli on CI fails with error:
> E: org.gimp.GIMP:394: release-time-missing date
I didn't have such error on my local build, because it is a new check
only recently added. The CI appstreamcli errored-out this way.
It forces us to add a bogus release date since we don't know it yet. I
chose May 29, because we usually release on Sundays, and it might soon
be time to make a dev release (so who knows, we might get lucky and it
might happen this day), though it should not be taken as a promise or a
real plan just now. I just needed to fill something in, in order to fix
the CI.
I opened a report to ask that appstreamcli proposes a relaxed check mode
where we can test on the <release> tag before knowing the future date:
https://github.com/ximion/appstream/issues/398
appstreamcli returns an info message:
> I: org.gimp.GIMP:3: cid-missing-affiliation-gnome org.gimp.GIMP
Checking the message, it happens because the application ID does not
start with "org.gnome." (but "org.gimp.").
Double-checking AppStream docs, a note says:
> You should only identify with an umbrella project if you use all their
> infrastructure and policies, for instance string freezes dates,
> bugtracker and source control instance.
GNOME Foundation is indeed an umbrella for us for the infrastructure and
obviously part of its policies. But we are still independant and don't
depend on GNOME's freeze dates, or release dates, or design rules
(though we try to follow what makes sense), and so on. So I guess it
means we should not set this metadata tag? 🤷 Let's drop it.
See: https://freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-project_group
Adding a TODO as date was passing through with appstream-util in relax
validation mode, but there is no such mode in appstreamcli.
Anyway since I have manual check steps for the AppStream files in
devel-docs/release-howto.txt, I never missed setting the date right (so
far! Knocks on wood…) in the AppStream metadata. Therefore let's drop
this trick for now and see how it goes.
It should fix the appstream unit check, but only when using appstreamcli
0.15.3 or over (this version is already on Debian testing).
See issue #8140.
As told to us, this is the reference AppStream file testing tool, and it
understands more of the spec.
Also since commit 73e2e701da, appstream-util chokes on newer url types
from the spec. These tags are now supported both in appstream-util and
appstreamcli source code, except that appstreamcli had release 0.15.3,
available in Debian testing, whereas there were apparently no recent
appstream-glib/util release (and none since 2020). So for these various
reasons, let's go with the appstreamcli tool.
The only downside is that appstream package (where appstreamcli lives)
is not available on MSYS2, but since it's only an optional test tool for
XML files which should be common on all platforms, it's probably
acceptable.
It's better to start early as these need to be translated too and are
now even visible in GIMP itself.
Note that I wrote 2.99.11 in the version attribute, but only to be able
to test this easily during development. It will have to be edited to the
right version at release.
We want it to work whatever the level in the item tree. We only care
about whether the items are selected or not.
Also fixing the AppStream release tag for the description of this
feature.
Without this entry, when starting GIMP as a flatpak application on
elementaryOS, the Dock icon would get duplicated, as if the application
was detached from its launcher. This entry fixes that by allowing the
dock to associate the app's window with the desktop entry.
More information on the type of problem this caused can be found here:
https://github.com/elementary/dock/issues/119
Instead of a target, let's make it a test. Also I realize it already
existed as desktop_file test. But it's simpler to run it directly (no
need of an external script).
Note: I still leave the test-desktop.sh script as it is used for the
autotools test.
Both files should always be synchronized (as development branch will one
day continue on the 2.10 series). Best practice would be that any change
to the AppData is first done on `master`, then cherry-picked to
`gimp-2-10` (even for stable release metadata).
It just says "The GIMP team" so it's kind of redundant/useless, but I
noticed that Flathub would just display an empty "Developer" section
because the tag is absent. Well at least it emphasizes the
community-developed side of GIMP.
I wrote down the wrong option name (based on some Gaussian Blur specific
option). My mistake was to make a quick check in GIMP itself instead of
properly looking at the relevant commit message and code change.
Thanks to Sabri Ünal for raising this issue.