Cf. discussions on IRC with Alx.
Since this is editable directly in the Path tool options, we likely
don't need to have the separate action for it. It feels redundant.
It is still available on a double-click, though I am not sure if it's a
good idea. Maybe the double-click should rather activate the path tool,
from which you can edit all these (just as what happens with the text
tool). To be continued after more UX discussions?
Based on the label, and also "retrieve" was just too generic. It made
sense in the context of rasterizable items, but with the more generic
"layers" context, it would raise uncertainty.
These 2 new actions are meant to be usable on all 3 types of non-raster
(and non-group) layers, i.e. link, text and vector layers, to
respectively rasterize and un-rasterize them.
This will also work with multiple selected layers, and is not specific
to one type of layers.
I also change how gimp_text_layer_discard() used to work, by marking the
text layer as modified instead of actually discarding all text
information. The main consequence of this was that a layer rasterized
this way was forever lost. Now it can actually be revived as a text
layer, not only through the new layers-retrieve action, but also by
trying to edit it with the Text tool, which will trigger the same dialog
as when a text layer had been rasterized by editing it with a paint
tool.
Whereas the label of "layers-rasterize" seem to be quite straightforward
(simply "Rasterize" per discussions in gimp-ux#252), I am really unsure
of the label for "layers-retrieve". Further UX discussions should help
on this front.
These are layers who content depends on another source (right now only
an external image). This can be useful when for instance working at
several people on a single artwork, hence being able to load new
versions of an image without even touching anything in the XCF (for
instance, say you draw an animated character while someone else is
taking care of the background).
Similarly to what we do for text layers, once you start modifying the
contents, it turns into a "normal" layer. The link information is still
available though, so it is possible to revert to the monitoring state
with the menu item "Monitor Linked Image" which appear when a link layer
became a normal layer.
This is not finale as I'm still experimenting. In particular, I have not
implemented XCF saving/loading yet for this new layer type.
In previous versions what has been stored/specified as perceptual blending or
compositing spaces has really been the non-linear variant of the images babl
space.
To maintain loading of old files, the code has been updated to actually mean
non-linear and a new perceptual value has been added to the GimpLayerColorSpace
enum, while preserving all old enum values.
This change bumps XCF file version to 23
Several menus can be triggered either as popups on their own when right-clicking
the dockable or on items, or as a submenu in the docks main menu.
In the former case, we want the menu items to be at the root level, whereas in
the latter case, we want them inside a properly named submenu.
To handle this, I wrap these in a properly labelled <submenu> in the .ui files,
and I add a boolean flag to gimp_menu_shell_fill() which will drop the top
submenu if and only if this is the only top item. I use this flag only when
using these menus as popup menu on their own.
Also fixing a few memory leaks around these pieces of code.
