The list of selected layers may be empty, which doesn't matter much
because we don't actually do much with this list in current export code.
In the code modified in this commit, we were only using existing layers
to set the type of a new layer (which seems very useless right now as
anyway the layer type has to be the image base type with or without
alpha, so a with_alpha boolean parameter would be just as good, unless
we plan to support different color model layers in a same image).
Add a new GIMP_EXPORT_NEEDS_CROP export capability, which causes
gimp_export_image() to crop the exported image content to the image
bounds; this is useful for formats that support layers, but have no
concept of global image bounds, hence cropping is the only way to
enforce the image bounds.
When showing the export dialog, give an option to either crop the
layers to the image bounds, or to resize the image to fit the
layers.
The GDK_WINDOWING_X11 build-time macro check is not enough as GDK can be
built with both X11 and Wayland backends. We need to add a runtime check
of the type of display.
In begin_run() and end_run(), sync string properties set to
GIMP_ARGUMENT_SYNC_PARASITE with image parasites of the same name,
exactly the way "gimp-comment" was handled by begin_export() and
end_export(). Remove the "gimp-comment" handling code from
begin_export() and end_export().
which can be set to GIMP_ARGUMENT_SYNC_NONE (the default) or
GIMP_ARGUMENT_SYNC_PARASITE, which indicates that the argument should
be synced with an image parasite of the same name.
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.