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.
as in, sync it with a "comment" property on the config if one
exists. Also allow gimp_procedure_config_begin_export() and
end_export() to skip GimpMetadata handling, for file formats which
don't support it.
No need to introspect deprecated API, especially for the new non-C APIs
after a major version update.
This also sync both the autotools and meson-generated GIR files.
See also #4018.
More of the files were wrong, or at least not absolutely identical to
the files generated by the autotools. I am not doing any code change
other than trying to make both build systems produce identical files
(except for slight differences on 2 files not worth the effort) even
though maybe some things can be improved (especially on the include
list). Maybe to be improved later.
Also fixing 2 of the previously autotools-generated files because of
space typos which should have been committed earlier.
Finally it is to be noted that there is no logics to copy the generated
files back to the source directory in the meson rules. I am not sure
anyway this is really worth it and maybe we should just stop tracking
these generated files eventually.
This is listed twice and is not needed for libgimpui (not listed in
autotools build) and apparently it provokes introspection warnings on
MSYS2 builds.
Thanks to lillolollo and Massimo for debugging this.
I had this warning when cross-building for Windows 64-bit:
> libgimp/gimpui.c:187:52: warning: passing argument 2 of
> 'gdk_win32_window_foreign_new_for_display' makes pointer from integer
> without a cast [-Wint-conversion]
> note: expected 'HWND' {aka 'struct HWND__ *'} but argument is of type 'guint32' {aka 'unsigned int'}
Similar to commit 9b328167ab. Apparently the same function is duplicated
into app/.
Also add some comments to detail a bit more where this Win32 different
comes from (i.e. bug 359538 on Bugzilla, commit eac61e1e12).
Moreover I tested the same steps as comment 4 in bug 359538 on master
code. The same hanging issue still exists with GTK+ 3.24.1 (in a Windows
VM at least). I have not investigated further, just wanted to check if
this ifndef could not simply be removed by now. Apparently not.
Thanks to Massimo for helping:
> To reduce the number of warnings down to 2, it is necessary to list
> gimptypes.h and gimpenums.h right after gimp.h and gimpui.h
> gimpuitypes.h at the start of libgimpui_headers_introspectable like
> they are in the corresponding list in Makefile.gi.
>
> Their order evidently matters
See #4018.
Some stuff are still wrong, but this is a first step in the right
direction.
export it to libgimp via GPConfig and add new API gimp_export_comment().
Bump the protocol version and improve variable names in both GPConfig
and libgimp/gimp.c.
Add gimp_procedure_config_begin_export() and end_export() which
are wrappers around begin_run() and end_run() and additionally
pretty much completely manage GimpMetadata handling.
A GimpProcedureConfig can provide boolean properties "save-exif",
"save-xmp" etc. in order to have them automatically managed by
begin_export() and end_export(). This also restores the feature of
overriding the procedure's saved default values with export
preferences, but not the values from the last export, like it
used to be in 2.10.
Move gimp_image_metadata_save_prepare() and save_finish() (which are
now completely handled by GimpProcedureConfig) from libgimpui to
libgimp, but keep their declarations in the libgimpui header. Not
perfect, but not finished either.
Also fix gimp_image_metadata_save_prepare() to set the affected
GimpMetadataSaveFlags to 0 when the image has no metadata at all.
They all had "class" as first argument (copied from gimpconfig-params.h)
and only worked accidentially because all functions they are used in
happen to have the right local "procedure" variable...
Add internal GimpProcedureConfig API to load/save "default values"
which are to be treated as if they were the hardcoded GParamSpec
defaults, but user-configurable. Also make all other load/save
functions available to other libgimp files.
In gimp_procedure_run(), if incomplete arguments are passed, don't
just complete them with the GParamSpec defaults, but look up the
user-saved defaults and use them if they exist. This happens before
everything else and brings back the PNG export feature of using
user-saved defaults also in non-interactive mode (but for all
procedures not just PNG export).
In GimpProcedureDialog, add "Load Defaults" and "Save Defaults"
buttons, they are the only way of managing the user-configurable
procedure defaults.
When clicking "Reset", show a popover with the reset options "Initial
Values" and "Factory Defaults".
and remember them internally between begin_run() and end_run().
Simplifies plug-in code even more.
Move the begin_run() before gimp_export_image() block in all export
plug-ins.
In libgimp/gimp.c: gimp_main() make sure that GIMP_TYPE_OBJECT_ARRAY
and GIMP_TYPE_PARAM_OBJECT_ARRAY are known to the type system and can
be looked up by name.
Aux arguments are arbitrary values the procedure wants managed and
remembered across invocations in GimpProcedureConfig. They are not
passed to run() and are not known to the PDB, they only exist in the
procedure's config object.
When non-NULL, the code tries to load/save image-specific last used
values from/to the image using a parasite. This is meant to be used by
file export plug-ins.
This is hopefully a temporary setback since we want to consider the
introspected API as a core feature (otherwise we'd end up with third
party builds deactivating the feature, and get a very random experience
depending on where you got GIMP) hence don't want it to be optional
(note that I haven't added a configure option).
Anyway for now, it seems that cross-building introspected data is not
really supported (or I'm still figuring it out).
Apart from some obvious typo, libgimpui link was failing with meson
because it now relies on a function from libgimpconfig (i.e.
gimp_config_reset()), since commit bfb7f43dbc. This fixes:
> /usr/bin/ld: libgimp/gimpproceduredialog.c:223: undefined reference to `gimp_config_reset'
Don't drop references we do not own. Turns out bindings can have
things referenced even after all procedure code has returned. Keep the
old code there in #if 0 and keep the debug warning for now, maybe we
can do something generic about this.
and in an attack of madness, changes almost all file plug-in
code to use GFile instead of filenames, which means passing
the GFile down to the bottom and get its filename at the very
end where it's actually needed.
Which means support for GParamSpecObject with value_type ==
G_TYPE_FILE, and converting between GFile and its URI for wire
communication directly above the protocol layer.
This change requires passing a GParamSpec's value type as generic
member of GPParamDef, which in turn makes some members of its
sub-structures obsolete.
It's an ancient concept from ancient times when we didn't have URIs
and only filenames (not to speak of GFile), and actually even from
before the ancient time before that ancient time when we first had
ones and zeros, and only had zeros.
Mention and guarantee the order of procedure registration (see
previous thumbnail loader commit). Remove duplicate docs from the
GimpPlugIn class comments that are needed for introspection, it's too
cumbersome to keep two identical texts in sync, and the removed text
is used nowhere.
GTK-docs needs the struct member documentations in the main struct
comment. So let's get this back, while keeping the proper GI
introspection for each method this time.
As discussed with Mitch.
Commit 005143a43e completely broke all the
introspected plug-ins, so I am reverting only the relevant changes.
If some things need to be improved in this part of the docs, let's do it
without breaking major stuff.
In particular: abstract methods must be properly documented (with
parameters, return values and annotations) like any function, and must
be named Class::method, e.g. GimpPlugInClass::query_procedures.
Other we break GObject Introspection, i.e. we break all plug-ins using
these.
Break reference cycles between the objects and the procedures they
keep by moving procedure destruction to dispose() and calling
g_object_run_dispose() before unrefing PLUG_IN and PDB in gimp.c.
Also some formatting and "Since: 3.0" annotation .
and call it gimp_pdb_set_proc_icon(). Change icon registration code in
libgimp/ and app/ so it's now possible to register icons for temporary
procedures.
- remove the menu path and image types from "gimp-plugins-query",
they are available via GimpProcedure, also reorder and rename
its remaining return values to make sense
- remove the "menu_path" parameter to gimp_proc_view_new(),
it can also ask GimpProcedure
- adapt plugin-browser to the new API and make it use GimpProcedure
- fix plugin-browser's tree view to show all menu hierarchies
completely, it was still expecting menu paths that contain
the menu label too
When exporting to a format that supports layers, but doesn't
support layer masks, merge layer groups with a mask before applying
their mask, since masks can't be applied to layer groups.
which frees exactly what _gimp_value_array_to_gp_params() has
allocated, honors its "full_copy" parameter, and plugs the last
libgimp refactoring leaks I'm currently aware of.
In the generated libgimp wrappers, we can't return object arrays
from a call to GIMP_VALUES_DUP_OBJECT_ARRAY() because it returns
a deep copy and adds a reference to all objects, which the caller
would have to unref.
But we want a shallow (transfer container) copy because we don't want
libgimp proxy objects to be refed or unrefed by any user code.
Therefore, add a HACK that simply memdup()s and returns the
GimpObjectArray's array memory, and leaves the contained object
pointers alone.
becuse some plug-ins really want the ID for good reasons and not the
object, and code looks so much nicer when the entire list of arguments
is extracted using the macros.
because we were simply destroying the proxy hashes when the last
procedure is done. Now we run gimp_plug_in_destroy_proxies() with the
right flag from gimp_plug_in_pop_procedure() before destroying the
hashes and get the proper debug warnings.
move the code to gimpparamspecs-body.c and include it from both app/
and libgimp/. They are the same apart from a minor difference which we
Also share the entire libgimp/gimpparamspecs.h header with the core.
No GimpParamSpecItem subclass needs its own validate function,
checking against pspec->value_type and gimp_item_is_vaid() in
gimp_param_item_validate() is good enough, no item ID can change its
type during the lifetime of the proxy.
GimpDisplay contains only the ID logic and the "gimp" and "config"
pointers, and lives in the core.
GimpDisplayImpl is a subclass and contains all the actual display
stuff. The subclass is only an implementation detail and doesn't
appear in any API.
Remove all hacks which pass displays as gpointer, GObject or
GimpObject through the core, or even lookup its type by name,
just use GimpDisplay.
which call gimp_item_get_by_id() and additionally check if the
returned item has the right type, and return NULL if not.
This is both shorter and more readable than
layer = GIMP_LAYER (gimp_item_get_by_id (id));
and additionally makes sure we don't cast e.g. a non-layer with
GIMP_LAYER(), which will give criticals but shouldn't, because the
wrong IDs can come from anywhere and are an input problem and not a
programming error (criticals are for programming errors).
Even when the function names may have stayed the same in most cases, the
API has changed. The "Since:" tag must therefore be bumped.
Also adding docs for gimp_drawable_get_sub_thumbnail_data() which had
none.
Basically creating a GParamSpecObject with type GimpImage would be
synonym to creating a GimpParamSpecImage (and similarly for items,
drawables, layers, and so on).
The only missing feature is therefore none_ok when using
GParamSpecObject (or to be more accurate: it implies none_ok=TRUE).
This is particularly needed for the Python API where a bug prevents to
manipulate GParamSpec types and pass them back to libgimp. Hence we want
to manipulate object specs using the binding specific API instead.
It used to work fine but this specific piece of code got removed by
commit 392f00baf5. This now works again fine.
- hand out and leak proxy object objects to legacy API like candy,
bypassing the factory in GimpPlugIn, because there is no plug-in
singleton.
- gimpgpcompat.c: image, item etc. are now objects, simply forgot this
file.
Need to push the current procedure around the entire body of
gimp_plug_in_proc_run_internal() because
_gimp_gp_params_to_value_array() needs access to proxy objects now.
Turn all ID param specs into object param specs (e.g. GimpParamImageID
becomes GimpParamImage) and convert between IDs and objects in
gimpgpparams.c directly above the the wire protocol, so all of app/,
libgimp/ and plug-ins/ can deal directly with objects down to the
lowest level and not care about IDs.
Use the actual object param specs for procedure arguments and return
values again instead of a plain g_param_spec_object() and bring back
the none_ok parameter.
This implies changing the PDB type checking functions to work on pure
integers instead of IDs (one can't check whether object creation is
possible if performing that check requires the object to already
exist).
For example gimp_foo_is_valid() becomes gimp_foo_id_is_valid() and is
not involved in automatic object creation magic at the protocol
level. Added wrappers which still say gimp_foo_is_valid() and take the
respective objects.
Adapted all code, and it all becomes nicer and less convoluted, even
the generated PDB wrappers in app/ and libgimp/.
Add an additional ref count to all proxies handed out by
GimpPlugIn, and when destroying the proxies, warn about any
proxy that has been unrefed, or additionally refed.
This catches and warns about only one broken unref, any more will
simply crash like before.
Seems underscored APIs are not visible on Win32. Anyway even if we fixed
this, this would only be temporary as all these deprecated APIs are only
meant to stay around temporarily, then be actually unavailable.
I hesitated to actually undeprecate the `_gimp_*_is_valid()` (like
making a `gimp_image_is_valid_id()` API for instance) but this is
actually quite similar to just create the GimpImage: if
gimp_image_get_by_id() returns NULL, then the ID was not valid.
We now have both variants, one returning a GList, and another
returning an array. Turns out that while a list is often nicer,
sometimes a random-access array really keeps the code much simpler.
Adapt all plug-ins, and clean up a bit (like use g_list_reverse() once
instead of iterating the list reversed).
Same for returned value though it seems we have no function with none_ok
as return value. At least we have the rule in the generation script for
when this will happen.
Use direct GType comparisons where possible, special case layer
because it has core subclasses but only one PDB type, special case
display because it's not visible from app/plug-in/, make code for
GPParamDef and GPParam look the same.
Turn GimpPlugIn into the main factory for all proxies and keep the
main hash tables there. The hash tables keep the initial reference.
For each GimpProcedure::run(), have s "sub-factory" which hands out
proxies to the actual procedure code. Each run() has hash tables of
its own which hold additional references. When run() is done, get rid
of its hash tables and their references, *and* drop the main plug-in
reference counts from the global hashes if the proxies' refcount has
dropped to one.
It is theoretically possible for an id to be reused. Normally here this
should not happen, since the previous item would have been removed from
the hash table anyway, when it got destroyed. Let's still be thorough.
This means that images' ownership is not given to caller in particular.
libgimp will now keep a reference of all GimpImage-s it creates and
return this same reference if called again. It also means that you can
now compare images by pointer comparison (as 2 GimpImage objects
representing the same image ID will be equal).
Obviously as a side effect, gimp_image_list() is changed to (transfer
container) as you must only free the container now, not the elements.
Also various other functions creating new images are now (transfer none)
too.
Long-time plug-ins will have to be taken in consideration in a further
step (we currently never free GimpImage for destroyed images in
particular).
I.e.: gimp_image_get_(layers|channels|vectors)(), gimp_image_list() and
gimp_item_get_children().
Instead of returning an array of IDs, these will now return a GList with
the right objects ready to use.
No need of is_id_arg() anymore in pdb/lib.pl. Let's reuse the {id}
value. Also I had to add an additional trick for GimpDisplay which we
will now generate as such in libgimp PDB files, but still need to show
as GimpObject on app/pdb/.
As previously, only the new classes and the PDB generation for a first
step.
I did the same trick with GIMP_DEPRECATED_REPLACE_NEW_API macro, apart
for some minor widget API to preview drawable, which I will fix right
away in our plug-ins.
Though it is still possible to use an image ID as procedure parameter,
it is now possible to pass a GimpImage GParamSpecObject.
Over the wire, this will transform back and forth into a GimpImageID,
totally transparently for the plug-in which will only always get a
GimpImage.
Same as previous commit: by default the new API will be used. But if a
plug-in builds with GIMP_DEPRECATED_REPLACE_NEW_API macro, then the same
function names will call the old API with ids.
By default the new API will be used. But if we build with
GIMP_DEPRECATED_REPLACE_NEW_API macro, then the same function names will
call the old API with ids.
This way, we don't have to update all our plug-ins at once (which I
tried and is very tedious work).
Note that bindings won't have access to the deprecated API at all.
This means that all functions which were returning or taking as
parameter an image id (as gint32) are now taking a GimpImage object
instead.
The PDB is still passing around an id only over the wire. But we create
an object for plug-ins to work on.
This is quite a huge API break, but is probably the best bet for the
future quality. It will make nicer API instrospection (and nicer API in
binding), will fix the issues with pspec on GimpImageID in Python
bindings (which makes the current Python API unusable as soon as we need
to work on images, which is most of our plug-ins!), etc.
Also it will allow to use signals on images, which will be a great asset
when we will finally have bi-directionnal communications (i.e. plug-ins
would be able to connect to image changes, destructions, and whatnot).
that make dealing with value arrays easier and shorter, e.g.
g_value_get_boolean (gimp_value_array_index (args, n)):
becomes:
GIMP_VALUES_GET_BOOLEAN (args, n);
It's just too weird to be public. Remove its properties from the wire
protocol and from pluginrc. Instead, have all GParamSpecs' flags on
the wire and in pluginrc, so we can use stuff like
GIMP_PARAM_NO_VALIDATE.
Port the remaining few places to GIMP_PROC_ARG_STRING().
I'm sure something is broken now wrt UTF-8 validation,
will add tighter checks in the next commit.
And always pass URIs to all file procedures, the ones what didn't
register as "handles remove" will only ever get local file:// URIs.
Change all file plug-ins (also legacy ones) to expect URIs instead
of filenames, and convert to local paths in the plug-in.
The wire protocol should now be almost 100% clean of non-UTF-8 strings.
which looks much like gimpconfig-params.h and contains macros
(e.g. GIMP_PROC_ARG_BOOLEAN() and GIMP_PROC_VAL_BOOLEAN()) for all
GimpProcedure argument and return value types supported by the
protocol, and makes the boilerplate of setting up a procedure more
readable and much less indented.
This file is C-only and not introspected.
Jehan