... as a drop-in replacement for gegl_buffer_dup(), which COWs all
tiles of the source buffer, including ones that aren't fully
included within buffer's extent.
In gimp_gegl_buffer_copy(), assume that the area outside the abyss
is empty, and so, when the abyss policy is NONE, allow data otuside
the source/destination abyss to be copied, by temporarily modifying
the abyss. This allows tiles that aren't fully contained within
the abyss to be COWed, unlike gegl_buffer_copy(), which has to be
more general.
This fixes such warning:
> Warning: gvalue.c:188: cannot initialize GValue with type 'GEnum',
> this type is abstract with regards to GValue use, use a more specific
> (derived) type
And obviously all subsequent errors because we failed to initialize and
set enum values. Such as:
> Warning: g_value_set_enum: assertion 'G_VALUE_HOLDS_ENUM (value)' failed
I have only fixed this in gimp_image_pdb. If enum types are used in
other places with GimpValueArray, we must fix them the same way.
The latter is broken and doesn't guarantee a decimal point with the
current bug. Also, g_ascii_dtostr() doesn't need the format parameter
and produces nicer output.
(skip) various variable length functions (va_list functions are not
introspectable anyway, but adding manual annotations shows we've have
been through them).
Also (skip) gimp_dialogs_show_help_button even though it could be
introspected without any problem. Yet it's written that's an
internal-only function, so let's forbid bindings from using it.
Finally fix gimp_dialog_add_button() introspection by properly including
Gtk-3.0 introspected library so that g-ir-* knows the GtkWidget type.
A number without a decimal point can be put into a gdouble just fine,
no need to refuse them. Moreover, g_ascii_dtostr() serializes doubles
without fractional part without a decimal point, and we are soon going
to use it.
... gimp_dialog_set_alternative_button_order_from_array()
Macros are not introspectable, which means this call would not be
available for non-C plug-ins. Also adding a "Since: 3.0" since these
macros were added in commit 3be0d13be3.
Note that I don't do the same for the macro
gimp_dialog_set_alternative_button_order() because varargs functions
won't be introspected anyway. So this one can just stay a macro for C
plug-ins only.
I may have missed things. That is the problem of non-compiled script
languages. There is also a known warning:
> DeprecationWarning: Gtk.Dialog.set_alternative_button_order_from_array is deprecated
I'll see later about this one.
Push-time note: calling various functions is actually broken right now
in the console since the late API changes (it was working fine yesterday
evening when I tested the same python-console code). Pushing anyway for
now.
Only leave behind gimpcolorscale, gimpcolorscales and gimpcolorselect
for now. There are some GI compilation errors and I don't have the time
right now to look into it. Most of libgimpwidgets is available to GI
bindings now anyway.
All foo_pdb.c functions in libgimp regenerated. I have reviewed this a
dozen times, but please have a look, there might well be glitches and
our public API is sortof important...
Validation is not the job of a GValue setter, we have the GParamSpec's
value_validate for that. Also, we will use the new GType-based API in
the libgimp PDB wrappers soon, and it's really a bad idea to
implicitly call e.g. gimp_image_is_valid() from the generated
gimp_image_is_valid() wrapper.
and _new_from_types_valist()
which take a va_list of GTypes and creates a GimpValueArray
initialized with these types, so one can simply have a list of
g_value_set_foo (gimp_value_array_index (array, i), foo);
in the next lines. I'm not so sure this is the best API ever...
Python scripts should already properly run, whether you run them with a
direct python shebang or a `env python` one (cf. previous commit). But
it's still nice to install a `.interp` file, which allows to control
exactly the interpreter to use, overriding the shebang. With this file,
Python scripts will use installation-time Python interpreter.
Also update old code to make the interp contents about Python 3 instead
of 2.
In particular, if the shebang is `#!/usr/bin/env lang` and we have not
registered a specific interpreter for `lang`, the system should leave
the env tool search the right interpreter for us. We only bypass env
when we set our own explicit interpreter.
Apply this to palette-to-gradient.py plug-in.
which takes and returns GimpValueArrays. This or something similar is
the new central function for running core procedures. Use the new
function from gimp_run_procedure2().
- libgimpbase: change GPParam to transfer all information about the
GValues we use, in the same way done for GPParamDef. GPParam is now
different from GimpParam from libgimp, pointers can't be casted any
longer. The protocol is now completely GimpPDBArgType-free. Remove
gp_params_destroy() from the public API.
- libgimp: add API to convert between an array of GPParams and
GimpValueArray, the latter is now the new official API for dealing
with procedure arguments and return values, GimpParam is cruft (the
wire now talks with GimpPlugIn more directly than with the members
of GimpPlugInInfo, which need additional compat conversions).
- libgimp, app: rename gimpgpparamspecs.[ch] to simply
gimpgpparams.[ch] which is also more accurate because they now
contain GValue functions too. The code that used to live in
app/plug-in/plug-in-params.h is now completely in libgimp.
- app: contains no protocol compat code any longer, the only place
that uses GimpPDBArgType is the PDB query procedure implementation,
which also needs to change.
- app: change some forgotten int32 run-modes to enums.
Michael Natterer