Don't disable color-to-alpha for grayscale drawable, since the
operation is applicable to grayscale images (in particular, it
doesn't add color where there was none), and since we no longer
distinguish between layers and channels according to the drawable
format when updating the filters actions.
... (used to add one automatically)
In GimpFilterTool and gimp_drawable_apply_operation(), use
gimp_drawable_filter_set_add_alpha() to add an alpha channel when
applying an operation that specifies "needs-alpha" to a drawable
that can have alpha.
Don't disable gegl:color-to-alpha (which has "needs-alpha") when
the drawable doesn't have an alpha channel, if one can be added.
Change all action callbacks so they can be invoked by a GAction:
- add GimpActionCallback typedef:
void (* cb) (GimpAction*, GVariant*, gpointer)
- change all action callbacks to the GimpActionCallback signature
- add "gimp-activate" and "gimp-change-state" signals to GimpAction,
with the same signature as the resp. GAction signals
- remove all other custom action signals and only use the new
GimpAction signals
- pass around appropriate GVariants containing booleans, int32,
strings
- badly hack around to force a GimpProcedure pointer into a
uint64 variant
- remove all G_CALLBACK() casts from all action callbacks,
they all have the same signature now
Step one: get rid of all those deprecation warnings that make
it hard to see any other warnings:
- add a lot of dummy API to GimpAction, GimpActionGroup, GimpUIManager
etc. which simply forwards to the deprecated GTK functions, they
will all go away again later
- rename GimpAction to GimpActionImpl
- add interface GimpAction that is implemented by all action classes,
creates a common interface and allows to remove some duplicated
logic from GimpToggleAction and GimpRadioAction, and at the same
time adds more features
Add a new Offset filter tool, as a front-end to gimp:offset. The
tool replaces, and provides the same interface as, the drawable-
offset dialog, while also providing live preview and on-canvas
interaction.
Note that we don't simply use a custom propgui constructor for
gimp:offset, since we need a little more control.
Return an optional tooltip from gimp_procedure_get_sensitive(), in
GimpPlugInProcedure, build that tooltip from the image types the
procedure works on.
filters-commands.c always needs an image and a drawable, so use
return_if_no_drawable(), not return_if_no_display().
Also fix the sensitivity of the shadows-highlights actions, which made
this bug triggerable at all.
The four remaining "classic" color tools (Brightness-Contrast, Curves,
Levels and Threshold) are in fact just special UIs for otherwise
completely normal filter ops.
Add normal filter actions for them and invoke them like all
other filters, which makes them show up in the filter history
automatically.
The only small hack needed is to special case them in
gimp_gegl_procedure_execute_async() so the right tools are created
instead of the default GimpOperationTool. Also, blacklist the
automatically generated tools actions from action search and the
shortcut editor.
by encoding them directly in the string attached to all filter
actions. The code now supports both "gegl:some-operation" and
"gegl:some-operation\n<serialized config>".
Add "default_settings" to GimpGeglProcedure to store the settings of
the invoking action, much like the "default_run_mode" member.
Change filters-commands.c to parse the new operation string, create
GimpGeglProcedures with the deserialized settings, and use those
settings when the procedures are ran.
Change the filter history to be smarter about what is already in the
history, there can now be several different procedures with the same
name.
Remove the dilate and erode actions from the drawable group, and add
them to filters, they are just special cases of value-propagate with
fixed settings.
which determines if a filter is applied directly (RUN_NONINTERACTIVE)
or asynchronously using GimpOperationTool (RUN_INTERACTIVE).
Split filter actions in two groups, one for direct apply and one for
interactive apply, which have separate callbacks that create
GimpGeglProcedures with the right default_run_mode set.
(After doing this distinction automatically based on the existance of
editable properties, I figured will might want direct apply also for
filters that do have properties, such as e.g. dilate and erode, which
are just value-propagate with some constant property values)
so they show up in recent filters, and don't need their own callbacks.
This has the problem that they now show a GUI with no options, but
that simply puts on more pressure to fix this general uglyness of ops
without editable properties.
Try to sort all GIMP_ICON_* defines into FDO categories like in
https://specifications.freedesktop.org/icon-naming-spec/latest/ar01s04.html
Add defines for all icons we override, rename some icons to their FDO
standard names, and mark the ones we duplicate with a comment so we
don't forget to rename those to standard names in 3.0.
Ell