This implied a lot of other core changes, which also pushed me into
improving some of the edit actions and PDB calls to be multi-layer aware
in the same time.
Note that it is still work-in-progress, but I just had to commit
something in an acceptable intermediate state otherwise I was just going
crazy.
In particular now the various transform tools are multi-layer aware and
work simultaneously on all selected layers (and the linked layers if any
of the selected layers is linked too). Both preview and final transform
processing works.
In the limitations, preview doesn't work well (only one layer in the
preview) when there is a selection (though the actual transform works).
Also I am left to wonder how we should process this case of canvas
selection+transform on multi-layers. Indeed currently I am just creating
a floating selection (like we used to for the selection+transform case)
containing a transform result of the composited version of all selected
layers. This is a possible expected result, but another could be to get
several transformed layers (without composition). But then should the
"Floating Selection" concept allow for multiple Floating Selections?
Sooo many questions left to answer.
We're exposing symbols in our header files like `GType`, `GFile` and
others, without actually including the proper headers. This also gives
errors in the GIR scanner (who can't resolve those symbols).
This fixes bugs introduced in commit a7c59277fb where I obviously didn't
properly checked all the places where gimp_selection_float() was used
after its parameters changed.
Color picking on a single layer still works as it used to. On multiple
layer, it will now pick on the composited color, similarly to sample
merged if only selected layers were made visible.
The PDB/libgimp function gimp_image_pick_color() is also updated to work
on multiple drawables too, giving the same ability to plug-ins (the only
call to this function in core plug-ins have been updated).
When several layers are selected, select their render, similar to how
"edit-copy-visible" would have copied an image with only these layers
made visible.
Also apply the same logics to PDB function gimp_edit_copy() which can
now be used on several drawables at once.
This commit just changes our saving API (i.e. the GimpSaveProcedure
class) to take an array of drawables as argument instead of a single
drawable.
It actually doesn't matter much for exporting as the whole API seems
more or less bogus there and all formats plug-ins mostly care only
whether they will merge/flatten all visible layers (the selected ones
don't really matter) or if the format supports layers of some sort. It
may be worth later strengthening a bit this whole logics, and maybe
allow partial exports for instance.
As for saving, it was not even looking at the passed GimpDrawable either
and was simply re-querying the active layer anyway.
Note that I don't implement the multi-selection saving in XCF yet in
this commit. I only updated the API. The reason is that the current
commit won't be backportable to gimp-2-10 because it is an API break. On
the other hand, the code to save multi-selection can still be backported
even though the save() API will only pass a single drawable (as I said
anyway, this argument was mostly bogus until now, hence it doesn't
matter much for 2.10 logics).
By using Meson's `declare_dependency()`, we can avoid specifying the
linked libraries, dependencies and includes we need over and over again.
Basically, this conceptually acts like an internal pkg-config.
Especially need to watch out with forgetting `(array)` and `(out)`
annotations, as they can really give a different API in certain (if not
most) bindings.
When using GIR-based bindings that will eventually include the header
files (like Vala), we need to make sure to tell the gir-scanner what
file that is. Otherwise tools like `vapigen` have to make an educated
guess (which will be wrong).
GObject introspection has issues handling random vfuncs (i.e. not part
of a GObject). Most of all, it needs to be able to give these a name
(so they can be used to cast in some higher level languages for
example). As such, give each vfunc in `GimpProgressVtable` a separate
typedef.
Copy gimp_param_specs_get_desc() to libgimp and make it also mention
default values. Don't install its header for now, because it's pretty
much a utility function of GimpProcView. It also doesn't handle most
GParamSpec types yet.
As a side effect, this fixed issue #3947.
… and additional source from python POTFILES.
These 2 fixes allow `make distcheck` to work fine.
You'll notice that I just commented the pygimp files out instead of just
deleting them. That's because there have been discussions and a patch
proposal lately about porting the pygimp API to Python 3/master. We are
not sure we want this yet for maintainability reason (and I was supposed
to be the one to wipe these files out!) but we'll see.
* Don't generate our own marshallers if they are available in GLib
already
* Don't set the c_marshaller parameter in `g_signal_new()` if it's a
default marshaller provided by GLib. See commit message of commit
39e4aa3c57 on why this is the case.
The first property of a GimpProcedureConfig is the related
GimpProcedure. All others are the procedure arguments.
Also fixing the pspecs index while looping since we want to start at 1
to loop through arguments for the same reason.
Among other things, this was breaking the calls to file_save() and
several unit tests.
(cherry picked from commit 48acb361a3)
like in the fix for issue #4392. Remove the reference to the issue
from gimp_param_spec_layer() because we can't have it in all places
that now do checks.
... property name validation.
Slightly different fix on master compared to the gimp-2-10 branch. Here
the GParamSpec creation will happen already on the plug-in process in
libgimp. Let's just make sure we abort before we segfault.
This will be enough for the plug-in developer to start debugging one's
code. At least the core process is not crashing when the plug-in dev
provides invalid param names.
in gimp_procedure_config_begin_export() and end_export(). It uses
both the "gimp-comment" parasite and gimp_get_default_comment() and
syncs them with the config's "comment" property if it has one.
Michael Natterer