… gimp_parasite_data_size().
gimp_parasite_data() was non introspection friendly because calling code
needs to know the size of returned data a way or another (the concept of
data pointer with random contents, no known size and no way to know the
end of the buffer is not usable in many languages other than C).
Now that all usage have been replaced by gimp_parasite_get_data(), we
can just remove the functions from the v3 API.
Allow @num_bytes to be nullable, but add text in the documentation that
this is only useful when you want to check if there is contents.
Also make @num_bytes into a guint32, and finally set it to 0 when there
is no parasite.
In GIMP 3, plug-ins are mandatorily under a subdirectory. Though on GIMP
2.10.x, both cases are still possible. So only the previous commit
should be backported to gimp-2-10 branch.
See discussion in !392.
Thanks also to Christopher Nielsen for helping.
Although most GObject bindings can't really deal with struct fields,
it's still a nice thing to be able to see that these are actually arrays
(it also becomes visible in the Vala VAPI file).
Similar code was used in 2 places basically (GimpLabelSpin and
GimpProcedureDialog) so just make it an utils function. It's good anyway
to have a generic function to estimate suitable increments and decimal
places depending on a range.
As a consequence also gimp_label_spin_new() now takes a gint digits
(instead of guint), with -1 meaning we want digits computed from the
range.
Similarly gimp_prop_scale_entry_new() docs adds the -1 meaning too.
This is one of the problems mentioned in issue #5863. This commit only fixes
our loading (and saving) of this metadata.
Certain iptc tags like "Keywords" can appear multiple times. We were using
gexiv2_metadata_get_tag_string to get the value but that always returns
the first value so we replaced that by gexiv2_metadata_get_tag_multiple.
`man snprintf` clearly says (in NOTES) that when source and target
overlap, the result in undefined.
g_snprintf() conforms to the same standard hence would not get the
expected result. In my case, the result was just tzstr (e.g. "+01:00").
There were still a few references to functions which have been removed
from GIMP 3 (because they were deprecated in previous versions), which I
found as I was doing an inventory of removed functions.
Partially based on the comments of Massimo Valentini we block all Pentax and PentaxDng
exif Preview tags from being exported. We leave finding a more flexible solution for
problematic tags to a future contributor.
Plug-ins that work from different bindings probably want to use their
own list-type to specify arguments, rather than working with a more
cumbersome `GimpValueArray`.
This new API should make it less verbose. For example:
```
args = Gimp.ValueArray.new(5)
args.insert(0, GObject.Value(Gimp.RunMode, Gimp.RunMode.NONINTERACTIVE))
args.insert(1, GObject.Value(Gimp.Image, image))
args.insert(2, GObject.Value(Gimp.Drawable, mask))
args.insert(3, GObject.Value(GObject.TYPE_INT, int(time.time())))
args.insert(4, GObject.Value(GObject.TYPE_DOUBLE, turbulence))
Gimp.get_pdb().run_procedure('plug-in-plasma', args)
```
becomes
```
Gimp.get_pdb().run_procedure('plug-in-plasma', [
GObject.Value(Gimp.RunMode, Gimp.RunMode.NONINTERACTIVE),
GObject.Value(Gimp.Image, image),
GObject.Value(Gimp.Drawable, mask),
GObject.Value(GObject.TYPE_INT, int(time.time())),
GObject.Value(GObject.TYPE_DOUBLE, turbulence),
])
```
... by qualifying them with "extern", in addition to
"__declspec(dllexport)". Omitting "extern" happened to work in the
past, but recent GCC versions require it.
I assume that we won't need most of these explicitly in bindings, but
_if_ it's needed, then it's best to make sure that people don't struggle
because they don't have proper API without annotations.
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.
This member of the GTypeInfo structure is the size of the object
instance (not of the parent instance). Let's fix it for all static type
registrations in this file, which had the same bug as commit
0eb6ff41cf.
Happy new year everyone!
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.
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.
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.
The second parameter should be GStatBuf*, which will be defined to be
the right struct depending on the actual platform. Using `struct stat*`
was good on Linux but was outputting warnings on other platforms (at
least on Win32).
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.
