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
The goal of this function is to give the focus to the active image
display. This is implemented as a core GimpDisplay virtual function
(with the actual implementation in GimpDisplayImpl), allowing to be used
even in core code, without actual GUI code (this was not necessary right
now, but I think it will be useful in future use).
This function is now called from the toolbox code (cf. 2 commits
earlier), avoiding code duplication. I also added a usage at the end of
toolbox_paste_received() so that a newly opened image by middle-click
paste in the toolbox directly gains focus.
Toolbox buttons don't require focus keeping (no further keyboard input
needed and navigating through/selecting tools can be done in various
other ways with a keyboard), which is why I removed focusability of
toolbox buttons years ago (cf. commit c83ee61c07).
Nevertheless this is not enough, and since toolbox is meant to work on
the canvas anyway, let's give back canvas focus as soon as any click
happens on dead areas of the toolbox, as well as on the Wilber (dnd)
drawing, but also each time a toolbox button is selected (though not on
the longer clicks to see tool groups' contents without selecting a tool
in the end).
This will allow to directly start working on the image without requiring
a click first (for instance panning with Space or similar interactions
which would not give focus to the image canvas).
This can also count as an alternative to the "Esc" shortcut to get
canvas focus back, with a mouse click instead of a keyboard key.
In tool-group GimpToolButton tooltips, in addition to showing the
description of the currently-active tool, list the other tools in
the group as well, to improve discoverability.
When the active tool of the tool group associated with the
currently-selected tool changes, we select the new active tool;
this is currently handled in GimpToolButton. Move this logic to
GimpToolManager, which already handles the other half of the
problem: updating the group's active tool when one of its tools is
selected.
Add a new GimpToolButton class, used for tool-buttons in the
toolbox, instead of implementing them directly in GimpToolPalette.
Each GimpToolButton is associated with a GimpToolItem, which can be
either an individual tool or a group.
When a tool button is associated with a group, it displays the
group's active tool, with an arrow at the corner. Clicking the
button selects the active tool, while clicking-and-holding, or
right-clicking, shows a menu of all the tools in the group.
Alternatively, the active tool can be changed using the scroll
wheel.