Since we are pre-processing anyway the AppStream metadata file (because
appstream-glib doesn't pass unknown XML attributes, cf. a previous
commit), it does feel silly now to continue loading the file at runtime
too. Let's just pre-process more data into the constructed C files, i.e.
get the introduction paragraphs and the change items too.
The only other remaining advantage of appstream-glib was that it was
handling the localization but since we also have these localized strings
in our gettext files, we can as well translate with gettext as any other
strings and it works just fine.
It will also get rid of any packaging issue, forgetting to package the
metadata file (as we had on the Windows installer, and still have on the
macOS package). Now it will just always work because data is internal.
The changes include:
* A popover will be displayed on tool buttons and relevant property
widgets.
* Now the welcome dialog gives focus up to its parent window because
really the whole focus styling issue in GTK is a bit maddening. The
colors are all faded, the popover widgets are barely visible, and so
on.
* Timing is tweaked a bit to give more time reading the popover tips.
… blinking it.
This will be necessary to demo new features available only in some
situations. E.g. a new option in line art detection mode of bucket fill
would require said mode to be enabled.
First I strip now every pieces of text. What it allows it to span the
script elements for instance on several lines, indent them and all that.
The second thing is that since all the dockable start with "gimp-", we
may as well allow use shorter names (both are allowed). Same for tool
(which we special-case), all the tool buttons ID start with "tools-"
since we reused the action names. So let's just allow the shorter
versions.
Finally I create a new gimp_blink_toolbox() which is a specialized
gimp_blink_dockable() for the toolbox in particular. I also move there
the whole code about selecting the right tool.
Make a different bullet points for items with demos and items without,
and add an info text explaining you can click on items with the right
bullet point to get a demo.
Even when using a GtkListBox, it's just prettier and clearer when having
a text list with dots IMO, especially since some text might wrap on
several lines. Let's just go with that.
The idea is to add some "demo" attribute to a list item inside the
<release> tag, since we already decided that (for now at least) we'd
keep a strict "intro + list" logics, as we did until now.
This demo attribute uses an internal format to specify successive
widgets to blink (like a demo path towards a feature). For now, what it
allows is:
* raise the toolbox, select a tool and blink the tool button.
* raise a dockable, blink any widgets in there.
Now it is still limited and needs to evolve. In particular:
* What happens if the blinked tool button was explicitly removed from
Preferences? Should we re-add it for the demo? And once done, should
we remove it again? Then should we select back the tool previously
selected?
* What happens if the dockable widget is not visible? Should we allow
changing the settings to be able to demo correctly the new/changed
settings? Should it be temporary? If temporary, it can be annoying as
you'd still have to look attentively the demo to find back the path to
the new settings. If not temporary, some people may dislike we touch
their settings.
* What if docks are hidden? Should we unhide them, then hide them back
after demo time?
Also regarding the implementation: originally I wanted to just grab the
demo attribute directly from the AppStream metadata file, but I realized
that appstream-glib cleans out unknown attribute from the XML. I could
then simply parse the file with a generic XML parser, but I found
simpler to pre-parse it into a header built within GIMP. I still use
appstream-glib at runtime as it takes care of localization for us
(though in the same time, we also have the localization in the main po
files, so maybe we could just embed the release note strings as well).
See appstream-glib report: https://github.com/hughsie/appstream-glib/issues/431
What it means is that we will be a bit strict over our <release>
formatting which will have to always be a <p> introduction followed by a
list of items. This is what gimp_appstream_to_pango_markups() expects.
Since so far, this is how all our <release> tags were formatted anyway,
this is not too much of a problem.
Note that I keep the less strict gimp_appstream_to_pango_markup() and
use it for extension's appstream description as we will have no control
over these.
The main reason for this new rule and new display of our release notes
is that I am going to add the ability to click independent release items
so that people can get "blinking" indications of what changed when
relevant.
For some reason, our flatpak is moving the appstream file elsewhere,
after installation (since all our scripts explicitly install it under
metainfo/).
So in flatpak, it is in /app/share/appdata/ (i.e. $DATADIR/appdata/).
This is not right and should not be done by the flatpak system, but
let's still verify this other location as it is legacy so it would not
be totally impossible that some distributions do something similar when
packaging GIMP.
See also: https://github.com/flatpak/flatpak/issues/4775
As Jacob reports in #6445, on a big-size monitor, the dialog is just too
big, this can be seen in particular with all the space left between info
text. Trying a new logic where I simply leave the dialog to be
allocated, then once I get its size, I generate an image roughly this
same size. This should avoid overly big images.
Thanks to Liam for the fix/feedback on IRC. There was a typo (s/if/it)
and some better wording proposition.
s/You can call if again/You can show it again/
