dnrops
/
gimp
mirror of https://github.com/GNOME/gimp.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
gimp/libgimp/gimpgpparams-body.c

1614 lines
55 KiB
C
Raw Normal View History

app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
/* LIBGIMP - The GIMP Library
* Copyright (C) 1995-2003 Peter Mattis and Spencer Kimball
*
* gimpgpparams-body.c
app, libgimp: add copyright notices to the new stuff, minor cleanup
2019-07-31 06:12:36 +08:00
* Copyright (C) 2019 Michael Natterer <mitch@gimp.org>
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
*
* This library is free software: you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 3 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library. If not, see
* <https://www.gnu.org/licenses/>.
*/
/* this file is included by both
*
* libgimp/gimpgpparams.c
* app/plug-in/gimpgpparams.c
*/
app, libgimp, pdb, plug-ins: add ability to default to context for all resource args. Also fixes the passing of the resource param definitions through PDB. There was some weird assumption, with a comment, in commit 73733335c8 that this was unneeded, which meant that we were not able to properly recreate the right param spec over the wire.
2024-09-06 19:38:43 +08:00
static GimpImage * get_image_by_id (gpointer gimp,
gint id);
static GimpItem * get_item_by_id (gpointer gimp,
gint id);
static GimpDisplay * get_display_by_id (gpointer gimp,
gint id);
static GObject * get_resource_by_id (gint id);
static gint get_resource_id (GObject *resource);
static GimpUnit * get_unit_by_id (gpointer gimp,
gint id);
app, libgimp: don't duplicate _gimp_gp_param_def_to_param_spec() they are virtually the same now (except GimpParamEnum, but that one is still the same because its special feature doesn't go over the wire).
2019-09-04 16:41:19 +08:00
GParamSpec *
app, libgimp: make two functions of gimpgpparams private and remove a "gimp" parameter that is no longer needed.
2019-09-05 22:07:15 +08:00
_gimp_gp_param_def_to_param_spec (const GPParamDef *param_def)
app, libgimp: don't duplicate _gimp_gp_param_def_to_param_spec() they are virtually the same now (except GimpParamEnum, but that one is still the same because its special feature doesn't go over the wire).
2019-09-04 16:41:19 +08:00
{
const gchar *name = param_def->name;
const gchar *nick = param_def->nick;
const gchar *blurb = param_def->blurb;
GParamFlags flags = param_def->flags;
flags &= ~G_PARAM_STATIC_STRINGS;
switch (param_def->param_def_type)
{
case GP_PARAM_DEF_TYPE_DEFAULT:
if (! strcmp (param_def->type_name, "GimpParamInt32Array"))
return gimp_param_spec_int32_array (name, nick, blurb, flags);
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/. Several types functions were using the wording "float" historically to mean double-precision, e.g. the float array type (which was in fact a double array). Or the scanner function gimp_scanner_parse_float() was in fact returning a double value. What if we wanted someday to actually add float (usually this naming means in C the single-precision IEEE 754 floating point representation) support? How would we name this? Now technically it's not entirely wrong (a double is still a floating point). So I've been wondering if that is because maybe we never planned to have float and double precision may be good enough for all usage in a plug-in API (which doesn't have to be as generic so the higher precision is enough)? But how can we be sure? Also we already had some functions using the wording double (e.g. gimp_procedure_add_double_argument()), so let's just go the safe route and use the accurate wording. The additional change in PDB is internal, but there too, I was also finding very confusing that we were naming double-precision float as 'float' type. So I took the opportunity to update this. It doesn't change any signature. In fact the whole commit doesn't change any type or code logic, only naming, except for one bug fix in the middle which I encountered while renaming: in gimp_scanner_parse_deprecated_color(), I discovered a hidden bug in scanning (color-hsv*) values, which was mistakenly using a double type for an array of float.
2024-11-02 21:03:37 +08:00
if (! strcmp (param_def->type_name, "GimpParamDoubleArray"))
return gimp_param_spec_double_array (name, nick, blurb, flags);
app, libgimp: don't duplicate _gimp_gp_param_def_to_param_spec() they are virtually the same now (except GimpParamEnum, but that one is still the same because its special feature doesn't go over the wire).
2019-09-04 16:41:19 +08:00
if (! strcmp (param_def->type_name, "GimpParamParasite"))
return gimp_param_spec_parasite (name, nick, blurb, flags);
libgimpbase, libgimp, app: add libgimp support for passing GFiles 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.
2019-09-12 03:40:17 +08:00
if (! strcmp (param_def->type_name, "GParamParam"))
return g_param_spec_param (name, nick, blurb,
g_type_from_name (param_def->value_type_name),
flags);
if (! strcmp (param_def->type_name, "GParamObject") &&
! strcmp (param_def->value_type_name, "GFile"))
return g_param_spec_object (name, nick, blurb, G_TYPE_FILE, flags);
libgimp, libgimpconfig: recognize RGB boxed args containing GimpRGB. Still the same problem as ever with the Python binding where we have a hard time creating GParamSpec, hence we make them from object properties. See: https://gitlab.gnome.org/GNOME/pygobject/-/issues/227#note_570031 But then again, the Python binding way to create GObject properties does not seem to give us a way to use our custom param types (or I didn't find how). So when I create a property with Gimp.RGB type in Python, it doesn't appear as a GIMP_PARAM_SPEC_RGB to our C code, but as a G_PARAM_SPEC_BOXED. So my trick is to check the value type instead. Note that I check the default value, but in reality it doesn't seem to work much either. Better than no support at all anyway.
2021-04-20 20:10:37 +08:00
Remove GimpStringArray in favor of GStrv GLib has a specific type of NULL-terminated string arrays: `G_TYPE_STRV`, which is the `GType` of `char**` aka `GStrv`. By using this type, we can avoid having a `GimpStringArray` which is a bit cumbersome to use for both the C API, as well as bindings. By using `GStrv`, we allow other languages to pass on string lists as they are used to, while the bindings will make sure to do the right thing. In the end, it makes the API a little bit simpler for everyone, and reduces confusion for people who are used to working with string arrays in other C/GLib based code (and not having 2 different types to denote the same thing). Related: https://gitlab.gnome.org/GNOME/gimp/-/issues/5919
2020-12-24 04:15:43 +08:00
if (! strcmp (param_def->type_name, "GParamBoxed") &&
! strcmp (param_def->value_type_name, "GStrv"))
return g_param_spec_boxed (name, nick, blurb, G_TYPE_STRV, flags);
Remove GimpUint8Array in favor of GBytes GLib has a specific type for byte arrays: `GBytes` (and it's underlying GType `G_TYPE_BYTES`). By using this type, we can avoid having a `GimpUint8Array` which is a bit cumbersome to use for both the C API, as well as bindings. By using `GBytes`, we allow other languages to pass on byte arrays as they are used to, while the bindings will make sure to do the right thing. In the end, it makes the API a little bit simpler for everyone, and reduces confusion for people who are used to working with byte arrays in other C/GLib based code (and not having 2 different types to denote the same thing). Related: https://gitlab.gnome.org/GNOME/gimp/-/issues/5919
2023-05-24 05:37:46 +08:00
if (! strcmp (param_def->type_name, "GParamBoxed") &&
! strcmp (param_def->value_type_name, "GBytes"))
return g_param_spec_boxed (name, nick, blurb, G_TYPE_BYTES, flags);
Issue #10885: gimp-palette-get-colors warning and critical. We were missing GimpColorArray support in one function. Note that the specific example in Python in #10885 still doesn't work, but for a second reason: gimp_value_array_index() returns a GValue which pygobject automatically tries to transform to the contained data. And unfortunately it doesn't know about our GimpColorArray type so we end with unusable boxed type generic data.
2024-02-28 05:31:15 +08:00
if (! strcmp (param_def->type_name, "GParamBoxed") &&
! strcmp (param_def->value_type_name, "GimpColorArray"))
return g_param_spec_boxed (name, nick, blurb, GIMP_TYPE_COLOR_ARRAY, flags);
app, libgimp*, pdb: new "format" type in the PDB. We have a bunch of special-casing format passing through the PDB, but either we were only passing the encoding, or else we were reconstructing the full format through private intermediate functions. In the space-invasion world, this is not right. Let's have a proper "format" type for PDB which does all the relevant data-passing for us, once and for all! Note that I am creating a wrapper boxed type GimpBablFormat whose only goal is to have recognizable GValue since Babl types don't have GType-s. Moreover I'm not using the GeglParamSpecFormat either, because it just uses pointers which again are a bit annoying in our various PDB code. Having a simple boxed arg is better.
2024-09-21 03:55:21 +08:00
if (! strcmp (param_def->type_name, "GParamBoxed") &&
! strcmp (param_def->value_type_name, "GimpBablFormat"))
return g_param_spec_boxed (name, nick, blurb, GIMP_TYPE_BABL_FORMAT, flags);
app, libgimp: don't duplicate _gimp_gp_param_def_to_param_spec() they are virtually the same now (except GimpParamEnum, but that one is still the same because its special feature doesn't go over the wire).
2019-09-04 16:41:19 +08:00
break;
app, libgimp: new GimpChoice procedure argument. These will replace the int arguments used in place of enums. The problem of int arguments used as list of choices is that it makes calling PDB functions very opaque. This is especially bad when a list is long, so you constantly have to refer to the documentation to understand what a series of numbers mean in argument lists. And the second issue is that plug-in developers have to manually maintain a list of values both in the GUI and in the documentation string. This help text may get out-of-sync, may end up with missing values or whatnot. Also if it is used as tooltips, it makes for very weird tooltips in the graphical interface, with an overlong technical list of int-values mapping which should ideally only be made visible in the PDB procedure browser listing.
2023-08-03 05:55:33 +08:00
case GP_PARAM_DEF_TYPE_CHOICE:
if (! strcmp (param_def->type_name, "GimpParamChoice"))
{
return gimp_param_spec_choice (name, nick, blurb,
g_object_ref (param_def->meta.m_choice.choice),
param_def->meta.m_choice.default_val,
flags);
}
break;
app, libgimp: don't duplicate _gimp_gp_param_def_to_param_spec() they are virtually the same now (except GimpParamEnum, but that one is still the same because its special feature doesn't go over the wire).
2019-09-04 16:41:19 +08:00
case GP_PARAM_DEF_TYPE_INT:
if (! strcmp (param_def->type_name, "GParamInt"))
return g_param_spec_int (name, nick, blurb,
param_def->meta.m_int.min_val,
param_def->meta.m_int.max_val,
param_def->meta.m_int.default_val,
flags);
if (! strcmp (param_def->type_name, "GParamUInt"))
return g_param_spec_uint (name, nick, blurb,
param_def->meta.m_int.min_val,
param_def->meta.m_int.max_val,
param_def->meta.m_int.default_val,
flags);
if (! strcmp (param_def->type_name, "GParamUChar"))
return g_param_spec_uchar (name, nick, blurb,
param_def->meta.m_int.min_val,
param_def->meta.m_int.max_val,
param_def->meta.m_int.default_val,
flags);
break;
case GP_PARAM_DEF_TYPE_UNIT:
if (! strcmp (param_def->type_name, "GimpParamUnit"))
return gimp_param_spec_unit (name, nick, blurb,
param_def->meta.m_unit.allow_pixels,
param_def->meta.m_unit.allow_percent,
Issue #8900 and #9923: reimplementing GimpUnit as a proper class. This fixes all our GObject Introspection issues with GimpUnit which was both an enum and an int-derived type of user-defined units *completing* the enum values. GIR clearly didn't like this! Now GimpUnit is a proper class and units are unique objects, allowing to compare them with an identity test (i.e. `unit == gimp_unit_pixel ()` tells us if unit is the pixel unit or not), which makes it easy to use, just like with int, yet adding also methods, making for nicer introspected API. As an aside, this also fixes #10738, by having all the built-in units retrievable even if libgimpbase had not been properly initialized with gimp_base_init(). I haven't checked in details how GIR works to introspect, but it looks like it loads the library to inspect and runs functions, hence triggering some CRITICALS because virtual methods (supposed to be initialized with gimp_base_init() run by libgimp) are not set. This new code won't trigger any critical because the vtable method are now not necessary, at least for all built-in units. Note that GimpUnit is still in libgimpbase. It could have been moved to libgimp in order to avoid any virtual method table (since we need to keep core and libgimp side's units in sync, PDB is required), but too many libgimpwidgets widgets were already using GimpUnit. And technically most of GimpUnit logic doesn't require PDB (only the creation/sync part). This is one of the reasons why user-created GimpUnit list is handled and stored differently from other types of objects. Globally this simplifies the code a lot too and we don't need separate implementations of various utils for core and libgimp, which means less prone to errors.
2024-07-26 02:55:21 +08:00
gimp_unit_get_by_id (param_def->meta.m_unit.default_val),
app, libgimp: don't duplicate _gimp_gp_param_def_to_param_spec() they are virtually the same now (except GimpParamEnum, but that one is still the same because its special feature doesn't go over the wire).
2019-09-04 16:41:19 +08:00
flags);
break;
case GP_PARAM_DEF_TYPE_ENUM:
if (! strcmp (param_def->type_name, "GParamEnum"))
return g_param_spec_enum (name, nick, blurb,
libgimpbase, libgimp, app: add libgimp support for passing GFiles 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.
2019-09-12 03:40:17 +08:00
g_type_from_name (param_def->value_type_name),
app, libgimp: don't duplicate _gimp_gp_param_def_to_param_spec() they are virtually the same now (except GimpParamEnum, but that one is still the same because its special feature doesn't go over the wire).
2019-09-04 16:41:19 +08:00
param_def->meta.m_enum.default_val,
flags);
if (! strcmp (param_def->type_name, "GimpParamEnum"))
/* FIXME GimpParamEnum */
return g_param_spec_enum (name, nick, blurb,
libgimpbase, libgimp, app: add libgimp support for passing GFiles 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.
2019-09-12 03:40:17 +08:00
g_type_from_name (param_def->value_type_name),
app, libgimp: don't duplicate _gimp_gp_param_def_to_param_spec() they are virtually the same now (except GimpParamEnum, but that one is still the same because its special feature doesn't go over the wire).
2019-09-04 16:41:19 +08:00
param_def->meta.m_enum.default_val,
flags);
break;
case GP_PARAM_DEF_TYPE_BOOLEAN:
if (! strcmp (param_def->type_name, "GParamBoolean"))
return g_param_spec_boolean (name, nick, blurb,
param_def->meta.m_boolean.default_val,
flags);
break;
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/. Several types functions were using the wording "float" historically to mean double-precision, e.g. the float array type (which was in fact a double array). Or the scanner function gimp_scanner_parse_float() was in fact returning a double value. What if we wanted someday to actually add float (usually this naming means in C the single-precision IEEE 754 floating point representation) support? How would we name this? Now technically it's not entirely wrong (a double is still a floating point). So I've been wondering if that is because maybe we never planned to have float and double precision may be good enough for all usage in a plug-in API (which doesn't have to be as generic so the higher precision is enough)? But how can we be sure? Also we already had some functions using the wording double (e.g. gimp_procedure_add_double_argument()), so let's just go the safe route and use the accurate wording. The additional change in PDB is internal, but there too, I was also finding very confusing that we were naming double-precision float as 'float' type. So I took the opportunity to update this. It doesn't change any signature. In fact the whole commit doesn't change any type or code logic, only naming, except for one bug fix in the middle which I encountered while renaming: in gimp_scanner_parse_deprecated_color(), I discovered a hidden bug in scanning (color-hsv*) values, which was mistakenly using a double type for an array of float.
2024-11-02 21:03:37 +08:00
case GP_PARAM_DEF_TYPE_DOUBLE:
app, libgimp: don't duplicate _gimp_gp_param_def_to_param_spec() they are virtually the same now (except GimpParamEnum, but that one is still the same because its special feature doesn't go over the wire).
2019-09-04 16:41:19 +08:00
if (! strcmp (param_def->type_name, "GParamDouble"))
return g_param_spec_double (name, nick, blurb,
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/. Several types functions were using the wording "float" historically to mean double-precision, e.g. the float array type (which was in fact a double array). Or the scanner function gimp_scanner_parse_float() was in fact returning a double value. What if we wanted someday to actually add float (usually this naming means in C the single-precision IEEE 754 floating point representation) support? How would we name this? Now technically it's not entirely wrong (a double is still a floating point). So I've been wondering if that is because maybe we never planned to have float and double precision may be good enough for all usage in a plug-in API (which doesn't have to be as generic so the higher precision is enough)? But how can we be sure? Also we already had some functions using the wording double (e.g. gimp_procedure_add_double_argument()), so let's just go the safe route and use the accurate wording. The additional change in PDB is internal, but there too, I was also finding very confusing that we were naming double-precision float as 'float' type. So I took the opportunity to update this. It doesn't change any signature. In fact the whole commit doesn't change any type or code logic, only naming, except for one bug fix in the middle which I encountered while renaming: in gimp_scanner_parse_deprecated_color(), I discovered a hidden bug in scanning (color-hsv*) values, which was mistakenly using a double type for an array of float.
2024-11-02 21:03:37 +08:00
param_def->meta.m_double.min_val,
param_def->meta.m_double.max_val,
param_def->meta.m_double.default_val,
app, libgimp: don't duplicate _gimp_gp_param_def_to_param_spec() they are virtually the same now (except GimpParamEnum, but that one is still the same because its special feature doesn't go over the wire).
2019-09-04 16:41:19 +08:00
flags);
break;
case GP_PARAM_DEF_TYPE_STRING:
if (! strcmp (param_def->type_name, "GParamString"))
return g_param_spec_string (name, nick, blurb,
param_def->meta.m_string.default_val,
flags);
break;
Issue #10811: implement GeglParamColor missing in some places. Though I had already implemented passing GeglColor through the PDB, it was not complete. In particular, the protocol was not able to pass GeglParamColor specs. Fixes: > LibGimp-WARNING **: 16:06:09.451: _gimp_gp_param_def_to_param_spec: GParamSpec type unsupported 'GeglParamColor' This is part of the fix to issue #10811, though it's not complete yet.
2024-02-13 23:07:24 +08:00
case GP_PARAM_DEF_TYPE_GEGL_COLOR:
app, libgimp*, modules, pdb, plug-ins: new GimpParamColor. This is meant to obsolete GeglParamColor with at least an additional argument has_alpha which we need in GIMP. It allows to advertize when a parameter wants an opaque color, which in particular means we know when displaying a GUI to pick colors with alpha or not.
2024-04-20 05:02:29 +08:00
if (! strcmp (param_def->type_name, "GeglParamColor") ||
! strcmp (param_def->type_name, "GimpParamColor"))
Issue #10811: implement GeglParamColor missing in some places. Though I had already implemented passing GeglColor through the PDB, it was not complete. In particular, the protocol was not able to pass GeglParamColor specs. Fixes: > LibGimp-WARNING **: 16:06:09.451: _gimp_gp_param_def_to_param_spec: GParamSpec type unsupported 'GeglParamColor' This is part of the fix to issue #10811, though it's not complete yet.
2024-02-13 23:07:24 +08:00
{
GeglColor *default_color = NULL;
if (param_def->meta.m_gegl_color.default_val)
{
GPParamColor *default_val = param_def->meta.m_gegl_color.default_val;
const Babl *format = NULL;
const Babl *space = NULL;
gint bpp;
default_color = gegl_color_new ("black");
app, libgimp*, pdb: new "format" type in the PDB. We have a bunch of special-casing format passing through the PDB, but either we were only passing the encoding, or else we were reconstructing the full format through private intermediate functions. In the space-invasion world, this is not right. Let's have a proper "format" type for PDB which does all the relevant data-passing for us, once and for all! Note that I am creating a wrapper boxed type GimpBablFormat whose only goal is to have recognizable GValue since Babl types don't have GType-s. Moreover I'm not using the GeglParamSpecFormat either, because it just uses pointers which again are a bit annoying in our various PDB code. Having a simple boxed arg is better.
2024-09-21 03:55:21 +08:00
if (default_val->format.profile_data)
Issue #10811: implement GeglParamColor missing in some places. Though I had already implemented passing GeglColor through the PDB, it was not complete. In particular, the protocol was not able to pass GeglParamColor specs. Fixes: > LibGimp-WARNING **: 16:06:09.451: _gimp_gp_param_def_to_param_spec: GParamSpec type unsupported 'GeglParamColor' This is part of the fix to issue #10811, though it's not complete yet.
2024-02-13 23:07:24 +08:00
{
GimpColorProfile *profile;
app, libgimp*, pdb: new "format" type in the PDB. We have a bunch of special-casing format passing through the PDB, but either we were only passing the encoding, or else we were reconstructing the full format through private intermediate functions. In the space-invasion world, this is not right. Let's have a proper "format" type for PDB which does all the relevant data-passing for us, once and for all! Note that I am creating a wrapper boxed type GimpBablFormat whose only goal is to have recognizable GValue since Babl types don't have GType-s. Moreover I'm not using the GeglParamSpecFormat either, because it just uses pointers which again are a bit annoying in our various PDB code. Having a simple boxed arg is better.
2024-09-21 03:55:21 +08:00
profile = gimp_color_profile_new_from_icc_profile (default_val->format.profile_data,
default_val->format.profile_size,
Issue #10811: implement GeglParamColor missing in some places. Though I had already implemented passing GeglColor through the PDB, it was not complete. In particular, the protocol was not able to pass GeglParamColor specs. Fixes: > LibGimp-WARNING **: 16:06:09.451: _gimp_gp_param_def_to_param_spec: GParamSpec type unsupported 'GeglParamColor' This is part of the fix to issue #10811, though it's not complete yet.
2024-02-13 23:07:24 +08:00
NULL);
if (profile)
{
GError *error = NULL;
space = gimp_color_profile_get_space (profile,
GIMP_COLOR_RENDERING_INTENT_RELATIVE_COLORIMETRIC,
&error);
if (! space)
{
g_printerr ("%s: failed to create Babl space from profile: %s\n",
G_STRFUNC, error->message);
g_clear_error (&error);
}
g_object_unref (profile);
}
}
app, libgimp*, pdb: new "format" type in the PDB. We have a bunch of special-casing format passing through the PDB, but either we were only passing the encoding, or else we were reconstructing the full format through private intermediate functions. In the space-invasion world, this is not right. Let's have a proper "format" type for PDB which does all the relevant data-passing for us, once and for all! Note that I am creating a wrapper boxed type GimpBablFormat whose only goal is to have recognizable GValue since Babl types don't have GType-s. Moreover I'm not using the GeglParamSpecFormat either, because it just uses pointers which again are a bit annoying in our various PDB code. Having a simple boxed arg is better.
2024-09-21 03:55:21 +08:00
format = babl_format_with_space (default_val->format.encoding, space);
Issue #10811: implement GeglParamColor missing in some places. Though I had already implemented passing GeglColor through the PDB, it was not complete. In particular, the protocol was not able to pass GeglParamColor specs. Fixes: > LibGimp-WARNING **: 16:06:09.451: _gimp_gp_param_def_to_param_spec: GParamSpec type unsupported 'GeglParamColor' This is part of the fix to issue #10811, though it's not complete yet.
2024-02-13 23:07:24 +08:00
bpp = babl_format_get_bytes_per_pixel (format);
if (bpp != default_val->size)
g_printerr ("%s: encoding \"%s\" expects %d bpp but data size is %d bpp.\n",
app, libgimp*, pdb: new "format" type in the PDB. We have a bunch of special-casing format passing through the PDB, but either we were only passing the encoding, or else we were reconstructing the full format through private intermediate functions. In the space-invasion world, this is not right. Let's have a proper "format" type for PDB which does all the relevant data-passing for us, once and for all! Note that I am creating a wrapper boxed type GimpBablFormat whose only goal is to have recognizable GValue since Babl types don't have GType-s. Moreover I'm not using the GeglParamSpecFormat either, because it just uses pointers which again are a bit annoying in our various PDB code. Having a simple boxed arg is better.
2024-09-21 03:55:21 +08:00
G_STRFUNC, default_val->format.encoding, bpp, default_val->size);
Issue #10811: implement GeglParamColor missing in some places. Though I had already implemented passing GeglColor through the PDB, it was not complete. In particular, the protocol was not able to pass GeglParamColor specs. Fixes: > LibGimp-WARNING **: 16:06:09.451: _gimp_gp_param_def_to_param_spec: GParamSpec type unsupported 'GeglParamColor' This is part of the fix to issue #10811, though it's not complete yet.
2024-02-13 23:07:24 +08:00
else
gegl_color_set_pixel (default_color, format, default_val->data);
}
app, libgimp*, modules, pdb, plug-ins: new GimpParamColor. This is meant to obsolete GeglParamColor with at least an additional argument has_alpha which we need in GIMP. It allows to advertize when a parameter wants an opaque color, which in particular means we know when displaying a GUI to pick colors with alpha or not.
2024-04-20 05:02:29 +08:00
return gimp_param_spec_color (name, nick, blurb,
param_def->meta.m_gegl_color.has_alpha,
default_color, flags);
Issue #10811: implement GeglParamColor missing in some places. Though I had already implemented passing GeglColor through the PDB, it was not complete. In particular, the protocol was not able to pass GeglParamColor specs. Fixes: > LibGimp-WARNING **: 16:06:09.451: _gimp_gp_param_def_to_param_spec: GParamSpec type unsupported 'GeglParamColor' This is part of the fix to issue #10811, though it's not complete yet.
2024-02-13 23:07:24 +08:00
}
break;
app, libgimp: don't duplicate _gimp_gp_param_def_to_param_spec() they are virtually the same now (except GimpParamEnum, but that one is still the same because its special feature doesn't go over the wire).
2019-09-04 16:41:19 +08:00
case GP_PARAM_DEF_TYPE_ID:
if (! strcmp (param_def->type_name, "GimpParamDisplay"))
return gimp_param_spec_display (name, nick, blurb,
param_def->meta.m_id.none_ok,
flags);
if (! strcmp (param_def->type_name, "GimpParamImage"))
return gimp_param_spec_image (name, nick, blurb,
param_def->meta.m_id.none_ok,
flags);
if (! strcmp (param_def->type_name, "GimpParamItem"))
return gimp_param_spec_item (name, nick, blurb,
param_def->meta.m_id.none_ok,
flags);
if (! strcmp (param_def->type_name, "GimpParamDrawable"))
return gimp_param_spec_drawable (name, nick, blurb,
param_def->meta.m_id.none_ok,
flags);
if (! strcmp (param_def->type_name, "GimpParamLayer"))
return gimp_param_spec_layer (name, nick, blurb,
param_def->meta.m_id.none_ok,
flags);
libgimp: fix #9304 API TextLayer Adds needed change missing in commit that added class GimpTextLayer
2023-06-08 19:18:14 +08:00
if (! strcmp (param_def->type_name, "GimpParamTextLayer"))
return gimp_param_spec_text_layer (name, nick, blurb,
param_def->meta.m_id.none_ok,
flags);
app, libgimp, pdb, plug-ins: new GimpGroupLayer class in libgimp. Also: - renaming gimp_layer_group_new() to gimp_group_layer_new() in order to keep the same name as in core code (i.e. GimpGroupLayer, not GimpLayerGroup). - renaming gimp_image_merge_layer_group() to gimp_group_layer_merge() - new functions: gimp_procedure_add_group_layer_argument(), gimp_procedure_add_group_layer_aux_argument() and gimp_procedure_add_group_layer_return_value(). This can be tested, e.g. in Python with these calls: ```py i = Gimp.get_images()[0] g = Gimp.GroupLayer.new(i, "hello") i.insert_layer(g, None, 1) g2 = Gimp.GroupLayer.new(i, "world") i.insert_layer(g2, g, 1) g.merge() ``` This was work started long ago, stored in an old stash which I finally finish now! :-)
2024-07-06 23:24:11 +08:00
if (! strcmp (param_def->type_name, "GimpParamGroupLayer"))
return gimp_param_spec_group_layer (name, nick, blurb,
param_def->meta.m_id.none_ok,
flags);
libgimp: fix #9304 API TextLayer Adds needed change missing in commit that added class GimpTextLayer
2023-06-08 19:18:14 +08:00
app, libgimp: don't duplicate _gimp_gp_param_def_to_param_spec() they are virtually the same now (except GimpParamEnum, but that one is still the same because its special feature doesn't go over the wire).
2019-09-04 16:41:19 +08:00
if (! strcmp (param_def->type_name, "GimpParamChannel"))
return gimp_param_spec_channel (name, nick, blurb,
param_def->meta.m_id.none_ok,
flags);
if (! strcmp (param_def->type_name, "GimpParamLayerMask"))
return gimp_param_spec_layer_mask (name, nick, blurb,
param_def->meta.m_id.none_ok,
flags);
if (! strcmp (param_def->type_name, "GimpParamSelection"))
return gimp_param_spec_selection (name, nick, blurb,
param_def->meta.m_id.none_ok,
flags);
libgimp, app, pdb: Rename GimpVectors to GimpPath This commit renames the GimpVectors object to GimpPath in both app/core and in libgimp. It also renames the files to gimppath.[ch] and updates the relevant build and translation files. There are still outstanding gimp_vectors_* () functions on the app side that need to be renamed in a subsequent commit.
2024-07-12 14:16:25 +08:00
if (! strcmp (param_def->type_name, "GimpParamPath"))
return gimp_param_spec_path (name, nick, blurb,
param_def->meta.m_id.none_ok,
flags);
app, libgimp: don't duplicate _gimp_gp_param_def_to_param_spec() they are virtually the same now (except GimpParamEnum, but that one is still the same because its special feature doesn't go over the wire).
2019-09-04 16:41:19 +08:00
break;
libgimp: add support for object arrays to gimpgpparams-body.c
2019-09-05 17:39:13 +08:00
case GP_PARAM_DEF_TYPE_ID_ARRAY:
libgimp*: get rid of GimpObjectArray and GimpParamSpecObjectArray. These have now been completely replace with the new GimpCoreObjectArray.
2024-10-24 00:48:29 +08:00
if (! strcmp (param_def->type_name, "GimpParamCoreObjectArray"))
return gimp_param_spec_core_object_array (name, nick, blurb,
g_type_from_name (param_def->meta.m_id_array.type_name),
flags);
app, libgimp, pdb, plug-ins: add ability to default to context for all resource args. Also fixes the passing of the resource param definitions through PDB. There was some weird assumption, with a comment, in commit 73733335c8 that this was unneeded, which meant that we were not able to properly recreate the right param spec over the wire.
2024-09-06 19:38:43 +08:00
break;
core, pdb, plug-ins: Create GimpExportOptions class This patch creates a GimpExportOptions class in both libgimpbase and in libgimp. Currently it is a mostly empty object, but it will be added to after 3.0 to allow for additional export options (like resizing on export while leaving the original image intact) libgimp/gimpexport.c was removed, and most of its content was copied into libgimp/gimpexportoptions.c. gimp_export_image () was replaced with gimp_export_options_get_image () in all export plug-ins. GimpExportProcedure has a new function to set the default image capabilities for each plug-in on creation. It also sets up a new callback function, which allows the options to respond to user setting changes (such as toggling 'Save as Animation' in the GIF or WEBP Plug-in).
2024-05-07 02:38:12 +08:00
case GP_PARAM_DEF_TYPE_EXPORT_OPTIONS:
if (! strcmp (param_def->type_name, "GimpParamExportOptions"))
{
app, libgimp*, pdb, plug-ins: capabilities should not be part of GimpParamSpecExportOptions. The param option just contains an options object, not a separate capabilities. Also even when passing the options object across the wire, the capabilities within this object are not part of the "options". These are actually handled separated by GimpExportProcedure. Therefore the changes are: * GimpExportCapabilities moved to gimpbaseenums.h with a proper GType. * "capabilities" properties are changed to flags param spec with type GimpExportCapabilities. * GimpParamSpecExportOptions doesn't have a capabilities variable anymore. * Consequently gimp_param_spec_export_options() doesn't have a capabilities arg. * Wire protocol updated as we don't need to pass any capabilities neither for the param definition, nor for the argument values. * GimpExportOptionsEditFunc renamed GimpExportGetCapabilitiesFunc and returning GimpExportCapabilities flags, instead of setting the "capabilities" property. I believe it makes it much more obvious what this callback is for and how to use it. * Annotations improved or completed. * Don't make the GimpParamSpecExportOptions public anymore since it is the same as its parent.
2024-11-02 02:13:02 +08:00
return gimp_param_spec_export_options (name, nick, blurb, flags);
core, pdb, plug-ins: Create GimpExportOptions class This patch creates a GimpExportOptions class in both libgimpbase and in libgimp. Currently it is a mostly empty object, but it will be added to after 3.0 to allow for additional export options (like resizing on export while leaving the original image intact) libgimp/gimpexport.c was removed, and most of its content was copied into libgimp/gimpexportoptions.c. gimp_export_image () was replaced with gimp_export_options_get_image () in all export plug-ins. GimpExportProcedure has a new function to set the default image capabilities for each plug-in on creation. It also sets up a new callback function, which allows the options to respond to user setting changes (such as toggling 'Save as Animation' in the GIF or WEBP Plug-in).
2024-05-07 02:38:12 +08:00
}
app, libgimp: don't duplicate _gimp_gp_param_def_to_param_spec() they are virtually the same now (except GimpParamEnum, but that one is still the same because its special feature doesn't go over the wire).
2019-09-04 16:41:19 +08:00
break;
app, libgimp, pdb, plug-ins: add ability to default to context for all resource args. Also fixes the passing of the resource param definitions through PDB. There was some weird assumption, with a comment, in commit 73733335c8 that this was unneeded, which meant that we were not able to properly recreate the right param spec over the wire.
2024-09-06 19:38:43 +08:00
case GP_PARAM_DEF_TYPE_RESOURCE:
if (g_type_from_name (param_def->type_name) != 0 &&
g_type_is_a (g_type_from_name (param_def->type_name), GIMP_TYPE_PARAM_RESOURCE))
return gimp_param_spec_resource (name, nick, blurb, g_type_from_name (param_def->type_name),
param_def->meta.m_resource.none_ok,
param_def->meta.m_resource.default_to_context ?
NULL : GIMP_RESOURCE (get_resource_by_id (param_def->meta.m_resource.default_resource_id)),
param_def->meta.m_resource.default_to_context,
flags);
break;
app, libgimp: don't duplicate _gimp_gp_param_def_to_param_spec() they are virtually the same now (except GimpParamEnum, but that one is still the same because its special feature doesn't go over the wire).
2019-09-04 16:41:19 +08:00
}
Introduce a global ID space for GimpData/GimpResource objects Much like for images and items. Change the PDB to transmit IDs instead of names for brush, pattern etc. and refactor a whole lot of libgimp code to deal with it. modified: libgimp/gimpplugin-private.h
2023-05-31 22:12:04 +08:00
g_warning ("%s: GParamSpec type unsupported '%s'", G_STRFUNC,
param_def->type_name);
app, libgimp: don't duplicate _gimp_gp_param_def_to_param_spec() they are virtually the same now (except GimpParamEnum, but that one is still the same because its special feature doesn't go over the wire).
2019-09-04 16:41:19 +08:00
return NULL;
}
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
void
_gimp_param_spec_to_gp_param_def (GParamSpec *pspec,
GPParamDef *param_def)
{
libgimpbase, libgimp, app: add libgimp support for passing GFiles 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.
2019-09-12 03:40:17 +08:00
GType pspec_type = G_PARAM_SPEC_TYPE (pspec);
GType value_type = G_PARAM_SPEC_VALUE_TYPE (pspec);
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
libgimpbase, libgimp, app: add libgimp support for passing GFiles 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.
2019-09-12 03:40:17 +08:00
param_def->param_def_type = GP_PARAM_DEF_TYPE_DEFAULT;
param_def->type_name = (gchar *) g_type_name (pspec_type);
param_def->value_type_name = (gchar *) g_type_name (value_type);
param_def->name = (gchar *) g_param_spec_get_name (pspec);
param_def->nick = (gchar *) g_param_spec_get_nick (pspec);
param_def->blurb = (gchar *) g_param_spec_get_blurb (pspec);
param_def->flags = pspec->flags;
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
Remove GIMP_TYPE_INT16 and GimpParamSpecInt16 Use gint and GParamSpecInt with the right value range instead.
2019-08-15 20:17:17 +08:00
if (pspec_type == G_TYPE_PARAM_INT)
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
{
GParamSpecInt *ispec = G_PARAM_SPEC_INT (pspec);
param_def->param_def_type = GP_PARAM_DEF_TYPE_INT;
param_def->meta.m_int.min_val = ispec->minimum;
param_def->meta.m_int.max_val = ispec->maximum;
param_def->meta.m_int.default_val = ispec->default_value;
}
Remove GIMP_TYPE_INT8 and GimpParamSpecInt8 Use guchar and GParamSpecUChar instead.
2019-08-15 19:34:11 +08:00
else if (pspec_type == G_TYPE_PARAM_UINT)
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
{
GParamSpecUInt *uspec = G_PARAM_SPEC_UINT (pspec);
param_def->param_def_type = GP_PARAM_DEF_TYPE_INT;
Remove GIMP_TYPE_INT8 and GimpParamSpecInt8 Use guchar and GParamSpecUChar instead.
2019-08-15 19:34:11 +08:00
param_def->meta.m_int.min_val = uspec->minimum;
param_def->meta.m_int.max_val = uspec->maximum;
param_def->meta.m_int.default_val = uspec->default_value;
}
else if (pspec_type == G_TYPE_PARAM_UCHAR)
{
GParamSpecUChar *uspec = G_PARAM_SPEC_UCHAR (pspec);
param_def->param_def_type = GP_PARAM_DEF_TYPE_INT;
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
param_def->meta.m_int.min_val = uspec->minimum;
param_def->meta.m_int.max_val = uspec->maximum;
param_def->meta.m_int.default_val = uspec->default_value;
}
app, libgimp, libgimpbase: forgot to support GIMP_TYPE_UNIT on the wire This commit can serve as an example how to add new types to GimpProtocol, note that zero public API changes.
2019-07-30 21:04:06 +08:00
else if (pspec_type == GIMP_TYPE_PARAM_UNIT)
{
GimpParamSpecUnit *uspec = GIMP_PARAM_SPEC_UNIT (pspec);
param_def->param_def_type = GP_PARAM_DEF_TYPE_UNIT;
Issue #8900 and #9923: reimplementing GimpUnit as a proper class. This fixes all our GObject Introspection issues with GimpUnit which was both an enum and an int-derived type of user-defined units *completing* the enum values. GIR clearly didn't like this! Now GimpUnit is a proper class and units are unique objects, allowing to compare them with an identity test (i.e. `unit == gimp_unit_pixel ()` tells us if unit is the pixel unit or not), which makes it easy to use, just like with int, yet adding also methods, making for nicer introspected API. As an aside, this also fixes #10738, by having all the built-in units retrievable even if libgimpbase had not been properly initialized with gimp_base_init(). I haven't checked in details how GIR works to introspect, but it looks like it loads the library to inspect and runs functions, hence triggering some CRITICALS because virtual methods (supposed to be initialized with gimp_base_init() run by libgimp) are not set. This new code won't trigger any critical because the vtable method are now not necessary, at least for all built-in units. Note that GimpUnit is still in libgimpbase. It could have been moved to libgimp in order to avoid any virtual method table (since we need to keep core and libgimp side's units in sync, PDB is required), but too many libgimpwidgets widgets were already using GimpUnit. And technically most of GimpUnit logic doesn't require PDB (only the creation/sync part). This is one of the reasons why user-created GimpUnit list is handled and stored differently from other types of objects. Globally this simplifies the code a lot too and we don't need separate implementations of various utils for core and libgimp, which means less prone to errors.
2024-07-26 02:55:21 +08:00
param_def->meta.m_unit.allow_pixels = uspec->allow_pixel;
app, libgimp, libgimpbase: forgot to support GIMP_TYPE_UNIT on the wire This commit can serve as an example how to add new types to GimpProtocol, note that zero public API changes.
2019-07-30 21:04:06 +08:00
param_def->meta.m_unit.allow_percent = uspec->allow_percent;
Issue #8900 and #9923: reimplementing GimpUnit as a proper class. This fixes all our GObject Introspection issues with GimpUnit which was both an enum and an int-derived type of user-defined units *completing* the enum values. GIR clearly didn't like this! Now GimpUnit is a proper class and units are unique objects, allowing to compare them with an identity test (i.e. `unit == gimp_unit_pixel ()` tells us if unit is the pixel unit or not), which makes it easy to use, just like with int, yet adding also methods, making for nicer introspected API. As an aside, this also fixes #10738, by having all the built-in units retrievable even if libgimpbase had not been properly initialized with gimp_base_init(). I haven't checked in details how GIR works to introspect, but it looks like it loads the library to inspect and runs functions, hence triggering some CRITICALS because virtual methods (supposed to be initialized with gimp_base_init() run by libgimp) are not set. This new code won't trigger any critical because the vtable method are now not necessary, at least for all built-in units. Note that GimpUnit is still in libgimpbase. It could have been moved to libgimp in order to avoid any virtual method table (since we need to keep core and libgimp side's units in sync, PDB is required), but too many libgimpwidgets widgets were already using GimpUnit. And technically most of GimpUnit logic doesn't require PDB (only the creation/sync part). This is one of the reasons why user-created GimpUnit list is handled and stored differently from other types of objects. Globally this simplifies the code a lot too and we don't need separate implementations of various utils for core and libgimp, which means less prone to errors.
2024-07-26 02:55:21 +08:00
param_def->meta.m_unit.default_val = gimp_unit_get_id (uspec->default_value);
app, libgimp, libgimpbase: forgot to support GIMP_TYPE_UNIT on the wire This commit can serve as an example how to add new types to GimpProtocol, note that zero public API changes.
2019-07-30 21:04:06 +08:00
}
app, libgimp: support GParamParam as a GParamSpec also add forgotten support for GimpParamEnum.
2019-08-05 20:14:32 +08:00
else if (G_IS_PARAM_SPEC_ENUM (pspec))
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
{
libgimpbase, libgimp, app: add libgimp support for passing GFiles 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.
2019-09-12 03:40:17 +08:00
GParamSpecEnum *espec = G_PARAM_SPEC_ENUM (pspec);
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
param_def->param_def_type = GP_PARAM_DEF_TYPE_ENUM;
libgimp: fix s/m_float/m_enum/ for GP_PARAM_DEF_TYPE_ENUM.
2019-08-04 23:20:02 +08:00
param_def->meta.m_enum.default_val = espec->default_value;
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
}
else if (pspec_type == G_TYPE_PARAM_BOOLEAN)
{
GParamSpecBoolean *bspec = G_PARAM_SPEC_BOOLEAN (pspec);
param_def->param_def_type = GP_PARAM_DEF_TYPE_BOOLEAN;
param_def->meta.m_boolean.default_val = bspec->default_value;
}
else if (pspec_type == G_TYPE_PARAM_DOUBLE)
{
GParamSpecDouble *dspec = G_PARAM_SPEC_DOUBLE (pspec);
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/. Several types functions were using the wording "float" historically to mean double-precision, e.g. the float array type (which was in fact a double array). Or the scanner function gimp_scanner_parse_float() was in fact returning a double value. What if we wanted someday to actually add float (usually this naming means in C the single-precision IEEE 754 floating point representation) support? How would we name this? Now technically it's not entirely wrong (a double is still a floating point). So I've been wondering if that is because maybe we never planned to have float and double precision may be good enough for all usage in a plug-in API (which doesn't have to be as generic so the higher precision is enough)? But how can we be sure? Also we already had some functions using the wording double (e.g. gimp_procedure_add_double_argument()), so let's just go the safe route and use the accurate wording. The additional change in PDB is internal, but there too, I was also finding very confusing that we were naming double-precision float as 'float' type. So I took the opportunity to update this. It doesn't change any signature. In fact the whole commit doesn't change any type or code logic, only naming, except for one bug fix in the middle which I encountered while renaming: in gimp_scanner_parse_deprecated_color(), I discovered a hidden bug in scanning (color-hsv*) values, which was mistakenly using a double type for an array of float.
2024-11-02 21:03:37 +08:00
param_def->param_def_type = GP_PARAM_DEF_TYPE_DOUBLE;
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/. Several types functions were using the wording "float" historically to mean double-precision, e.g. the float array type (which was in fact a double array). Or the scanner function gimp_scanner_parse_float() was in fact returning a double value. What if we wanted someday to actually add float (usually this naming means in C the single-precision IEEE 754 floating point representation) support? How would we name this? Now technically it's not entirely wrong (a double is still a floating point). So I've been wondering if that is because maybe we never planned to have float and double precision may be good enough for all usage in a plug-in API (which doesn't have to be as generic so the higher precision is enough)? But how can we be sure? Also we already had some functions using the wording double (e.g. gimp_procedure_add_double_argument()), so let's just go the safe route and use the accurate wording. The additional change in PDB is internal, but there too, I was also finding very confusing that we were naming double-precision float as 'float' type. So I took the opportunity to update this. It doesn't change any signature. In fact the whole commit doesn't change any type or code logic, only naming, except for one bug fix in the middle which I encountered while renaming: in gimp_scanner_parse_deprecated_color(), I discovered a hidden bug in scanning (color-hsv*) values, which was mistakenly using a double type for an array of float.
2024-11-02 21:03:37 +08:00
param_def->meta.m_double.min_val = dspec->minimum;
param_def->meta.m_double.max_val = dspec->maximum;
param_def->meta.m_double.default_val = dspec->default_value;
libgimp, libgimpbase, libgimpconfig: GimpParamSpecChoise's parent should be GParamSpecString.
2024-11-02 05:52:02 +08:00
}
/* Must be before G_IS_PARAM_SPEC_STRING() because it's a parent. */
else if (pspec_type == GIMP_TYPE_PARAM_CHOICE)
{
GimpParamSpecChoice *cspec = GIMP_PARAM_SPEC_CHOICE (pspec);
GParamSpecString *sspec = G_PARAM_SPEC_STRING (pspec);
param_def->param_def_type = GP_PARAM_DEF_TYPE_CHOICE;
param_def->meta.m_choice.default_val = sspec->default_value;
param_def->meta.m_choice.choice = cspec->choice;
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
}
Move GimpParamSpecString from libgimp back to app 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.
2019-08-19 18:54:52 +08:00
else if (G_IS_PARAM_SPEC_STRING (pspec))
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
{
libgimp, app: allow usage of GParamSpecString procedure arguments. Just consider these as a GimpParamSpecString with default allow_non_utf8 and non_empty values (FALSE).
2019-08-02 21:55:52 +08:00
GParamSpecString *gsspec = G_PARAM_SPEC_STRING (pspec);
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
libgimp: fix type names: s/FooParamSpecString/FooParamString/
2019-08-28 00:08:58 +08:00
if (! strcmp (param_def->type_name, "GimpParamString"))
param_def->type_name = "GParamString";
Move GimpParamSpecString from libgimp back to app 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.
2019-08-19 18:54:52 +08:00
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
param_def->param_def_type = GP_PARAM_DEF_TYPE_STRING;
Move GimpParamSpecString from libgimp back to app 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.
2019-08-19 18:54:52 +08:00
param_def->meta.m_string.default_val = gsspec->default_value;
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
}
Issue #11319: support GeglColor as generic GParamObject of type GeglColor. In some binding (e.g. Python), we have not found how to create GeglParamColor specs for PDB procedures, so we use GParamObject specs with `GeglColor` object_type. Have our code handle both variants. Fixes: > GIMP-WARNING: _gimp_gp_param_def_to_param_spec: GParamSpec type unsupported 'GeglParamColor' Of course such generic spec won't have any future option which we may add to a dedicated param spec (and despite adding code to handle a default value, adding a default color still doesn't work according to tests).
2024-04-20 00:54:53 +08:00
else if (GEGL_IS_PARAM_SPEC_COLOR (pspec) ||
app, libgimp*, modules, pdb, plug-ins: new GimpParamColor. This is meant to obsolete GeglParamColor with at least an additional argument has_alpha which we need in GIMP. It allows to advertize when a parameter wants an opaque color, which in particular means we know when displaying a GUI to pick colors with alpha or not.
2024-04-20 05:02:29 +08:00
GIMP_IS_PARAM_SPEC_COLOR (pspec) ||
Issue #11319: support GeglColor as generic GParamObject of type GeglColor. In some binding (e.g. Python), we have not found how to create GeglParamColor specs for PDB procedures, so we use GParamObject specs with `GeglColor` object_type. Have our code handle both variants. Fixes: > GIMP-WARNING: _gimp_gp_param_def_to_param_spec: GParamSpec type unsupported 'GeglParamColor' Of course such generic spec won't have any future option which we may add to a dedicated param spec (and despite adding code to handle a default value, adding a default color still doesn't work according to tests).
2024-04-20 00:54:53 +08:00
(pspec_type == G_TYPE_PARAM_OBJECT && value_type == GEGL_TYPE_COLOR))
Issue #10811: implement GeglParamColor missing in some places. Though I had already implemented passing GeglColor through the PDB, it was not complete. In particular, the protocol was not able to pass GeglParamColor specs. Fixes: > LibGimp-WARNING **: 16:06:09.451: _gimp_gp_param_def_to_param_spec: GParamSpec type unsupported 'GeglParamColor' This is part of the fix to issue #10811, though it's not complete yet.
2024-02-13 23:07:24 +08:00
{
GPParamColor *default_val = NULL;
GeglColor *default_color;
app, libgimp*, pdb, plug-ins: remove GimpRGB support in GIMP protocol. There are no plug-ins which uses GimpRGB for procedure argument, nor is there any base PDB procedure. We don't pass this type anymore through from/to core/plug-ins. So let's clean the whole code out as a next step to get rid of GimpRGB from our codebase!
2024-04-19 20:34:22 +08:00
param_def->param_def_type = GP_PARAM_DEF_TYPE_GEGL_COLOR;
app, libgimp*, modules, pdb, plug-ins: new GimpParamColor. This is meant to obsolete GeglParamColor with at least an additional argument has_alpha which we need in GIMP. It allows to advertize when a parameter wants an opaque color, which in particular means we know when displaying a GUI to pick colors with alpha or not.
2024-04-20 05:02:29 +08:00
param_def->meta.m_gegl_color.has_alpha = TRUE;
Issue #10811: implement GeglParamColor missing in some places. Though I had already implemented passing GeglColor through the PDB, it was not complete. In particular, the protocol was not able to pass GeglParamColor specs. Fixes: > LibGimp-WARNING **: 16:06:09.451: _gimp_gp_param_def_to_param_spec: GParamSpec type unsupported 'GeglParamColor' This is part of the fix to issue #10811, though it's not complete yet.
2024-02-13 23:07:24 +08:00
Issue #11319: support GeglColor as generic GParamObject of type GeglColor. In some binding (e.g. Python), we have not found how to create GeglParamColor specs for PDB procedures, so we use GParamObject specs with `GeglColor` object_type. Have our code handle both variants. Fixes: > GIMP-WARNING: _gimp_gp_param_def_to_param_spec: GParamSpec type unsupported 'GeglParamColor' Of course such generic spec won't have any future option which we may add to a dedicated param spec (and despite adding code to handle a default value, adding a default color still doesn't work according to tests).
2024-04-20 00:54:53 +08:00
if (GEGL_IS_PARAM_SPEC_COLOR (pspec))
{
default_color = gegl_param_spec_color_get_default (pspec);
}
app, libgimp*, modules, pdb, plug-ins: new GimpParamColor. This is meant to obsolete GeglParamColor with at least an additional argument has_alpha which we need in GIMP. It allows to advertize when a parameter wants an opaque color, which in particular means we know when displaying a GUI to pick colors with alpha or not.
2024-04-20 05:02:29 +08:00
else if (GIMP_IS_PARAM_SPEC_COLOR (pspec))
{
app, libgimp*, pdb: new GimpParamSpecObject abstract spec type. This abstract spec type is basically a GParamSpecObject with a default value. It will be used by various object spec with default values, such as GimpParamSpecColor, GimpParamSpecUnit and all GimpParamSpecResource subtypes. Also it has a duplicate() class method so that every spec type can implement the proper way to duplicate itself. This fixes the fact that in gimp_config_param_spec_duplicate(), all unknown object spec types (because they are implemented in libgimp, which is invisible to libgimpconfig) are just copied as GParamSpecObject, hence losing default values and other parameters. As a second enhancement, it also makes it easier to detect the object spec types for which we have default value support in gimp_config_reset_properties(). As a side fix, gimp_param_spec_color() now just always duplicates the passed default color, making it hence much easier to avoid bugs when reusing a GeglColor.
2024-09-03 05:38:13 +08:00
default_color = GEGL_COLOR (gimp_param_spec_object_get_default (pspec));
app, libgimp*, modules, pdb, plug-ins: new GimpParamColor. This is meant to obsolete GeglParamColor with at least an additional argument has_alpha which we need in GIMP. It allows to advertize when a parameter wants an opaque color, which in particular means we know when displaying a GUI to pick colors with alpha or not.
2024-04-20 05:02:29 +08:00
param_def->meta.m_gegl_color.has_alpha = gimp_param_spec_color_has_alpha (pspec);
}
Issue #11319: support GeglColor as generic GParamObject of type GeglColor. In some binding (e.g. Python), we have not found how to create GeglParamColor specs for PDB procedures, so we use GParamObject specs with `GeglColor` object_type. Have our code handle both variants. Fixes: > GIMP-WARNING: _gimp_gp_param_def_to_param_spec: GParamSpec type unsupported 'GeglParamColor' Of course such generic spec won't have any future option which we may add to a dedicated param spec (and despite adding code to handle a default value, adding a default color still doesn't work according to tests).
2024-04-20 00:54:53 +08:00
else
{
const GValue *value = g_param_spec_get_default_value (pspec);
default_color = g_value_get_object (value);
param_def->type_name = "GeglParamColor";
}
app, libgimp*, modules, pdb, plug-ins: new GimpParamColor. This is meant to obsolete GeglParamColor with at least an additional argument has_alpha which we need in GIMP. It allows to advertize when a parameter wants an opaque color, which in particular means we know when displaying a GUI to pick colors with alpha or not.
2024-04-20 05:02:29 +08:00
Issue #10811: implement GeglParamColor missing in some places. Though I had already implemented passing GeglColor through the PDB, it was not complete. In particular, the protocol was not able to pass GeglParamColor specs. Fixes: > LibGimp-WARNING **: 16:06:09.451: _gimp_gp_param_def_to_param_spec: GParamSpec type unsupported 'GeglParamColor' This is part of the fix to issue #10811, though it's not complete yet.
2024-02-13 23:07:24 +08:00
if (default_color != NULL)
{
const Babl *format;
format = gegl_color_get_format (default_color);
default_val = g_new0 (GPParamColor, 1);
app, libgimp*, pdb: new "format" type in the PDB. We have a bunch of special-casing format passing through the PDB, but either we were only passing the encoding, or else we were reconstructing the full format through private intermediate functions. In the space-invasion world, this is not right. Let's have a proper "format" type for PDB which does all the relevant data-passing for us, once and for all! Note that I am creating a wrapper boxed type GimpBablFormat whose only goal is to have recognizable GValue since Babl types don't have GType-s. Moreover I'm not using the GeglParamSpecFormat either, because it just uses pointers which again are a bit annoying in our various PDB code. Having a simple boxed arg is better.
2024-09-21 03:55:21 +08:00
default_val->size = babl_format_get_bytes_per_pixel (format);
default_val->format.encoding = (gchar *) g_strdup (babl_format_get_encoding (format));
Issue #10811: implement GeglParamColor missing in some places. Though I had already implemented passing GeglColor through the PDB, it was not complete. In particular, the protocol was not able to pass GeglParamColor specs. Fixes: > LibGimp-WARNING **: 16:06:09.451: _gimp_gp_param_def_to_param_spec: GParamSpec type unsupported 'GeglParamColor' This is part of the fix to issue #10811, though it's not complete yet.
2024-02-13 23:07:24 +08:00
app, libgimp*, pdb: new "format" type in the PDB. We have a bunch of special-casing format passing through the PDB, but either we were only passing the encoding, or else we were reconstructing the full format through private intermediate functions. In the space-invasion world, this is not right. Let's have a proper "format" type for PDB which does all the relevant data-passing for us, once and for all! Note that I am creating a wrapper boxed type GimpBablFormat whose only goal is to have recognizable GValue since Babl types don't have GType-s. Moreover I'm not using the GeglParamSpecFormat either, because it just uses pointers which again are a bit annoying in our various PDB code. Having a simple boxed arg is better.
2024-09-21 03:55:21 +08:00
default_val->format.profile_data = NULL;
default_val->format.profile_size = 0;
Issue #10811: implement GeglParamColor missing in some places. Though I had already implemented passing GeglColor through the PDB, it was not complete. In particular, the protocol was not able to pass GeglParamColor specs. Fixes: > LibGimp-WARNING **: 16:06:09.451: _gimp_gp_param_def_to_param_spec: GParamSpec type unsupported 'GeglParamColor' This is part of the fix to issue #10811, though it's not complete yet.
2024-02-13 23:07:24 +08:00
if (babl_format_get_space (format) != babl_space ("sRGB"))
{
const char *icc;
int icc_length;
icc = babl_space_get_icc (babl_format_get_space (format), &icc_length);
if (icc_length > 0)
{
app, libgimp*, pdb: new "format" type in the PDB. We have a bunch of special-casing format passing through the PDB, but either we were only passing the encoding, or else we were reconstructing the full format through private intermediate functions. In the space-invasion world, this is not right. Let's have a proper "format" type for PDB which does all the relevant data-passing for us, once and for all! Note that I am creating a wrapper boxed type GimpBablFormat whose only goal is to have recognizable GValue since Babl types don't have GType-s. Moreover I'm not using the GeglParamSpecFormat either, because it just uses pointers which again are a bit annoying in our various PDB code. Having a simple boxed arg is better.
2024-09-21 03:55:21 +08:00
default_val->format.profile_data = g_new0 (guint8, icc_length);
memcpy (default_val->format.profile_data, icc, icc_length);
Issue #10811: implement GeglParamColor missing in some places. Though I had already implemented passing GeglColor through the PDB, it was not complete. In particular, the protocol was not able to pass GeglParamColor specs. Fixes: > LibGimp-WARNING **: 16:06:09.451: _gimp_gp_param_def_to_param_spec: GParamSpec type unsupported 'GeglParamColor' This is part of the fix to issue #10811, though it's not complete yet.
2024-02-13 23:07:24 +08:00
}
app, libgimp*, pdb: new "format" type in the PDB. We have a bunch of special-casing format passing through the PDB, but either we were only passing the encoding, or else we were reconstructing the full format through private intermediate functions. In the space-invasion world, this is not right. Let's have a proper "format" type for PDB which does all the relevant data-passing for us, once and for all! Note that I am creating a wrapper boxed type GimpBablFormat whose only goal is to have recognizable GValue since Babl types don't have GType-s. Moreover I'm not using the GeglParamSpecFormat either, because it just uses pointers which again are a bit annoying in our various PDB code. Having a simple boxed arg is better.
2024-09-21 03:55:21 +08:00
default_val->format.profile_size = icc_length;
Issue #10811: implement GeglParamColor missing in some places. Though I had already implemented passing GeglColor through the PDB, it was not complete. In particular, the protocol was not able to pass GeglParamColor specs. Fixes: > LibGimp-WARNING **: 16:06:09.451: _gimp_gp_param_def_to_param_spec: GParamSpec type unsupported 'GeglParamColor' This is part of the fix to issue #10811, though it's not complete yet.
2024-02-13 23:07:24 +08:00
}
}
param_def->meta.m_gegl_color.default_val = default_val;
}
app, libgimp: get rid of all ID GTypes and ID param specs 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/.
2019-08-29 17:25:35 +08:00
else if (pspec_type == GIMP_TYPE_PARAM_IMAGE)
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
{
app, libgimp: get rid of all ID GTypes and ID param specs 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/.
2019-08-29 17:25:35 +08:00
GimpParamSpecImage *ispec = GIMP_PARAM_SPEC_IMAGE (pspec);
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
param_def->param_def_type = GP_PARAM_DEF_TYPE_ID;
param_def->meta.m_id.none_ok = ispec->none_ok;
}
app, libgimp: get rid of all ID GTypes and ID param specs 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/.
2019-08-29 17:25:35 +08:00
else if (GIMP_IS_PARAM_SPEC_ITEM (pspec))
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
{
app, libgimp: get rid of all ID GTypes and ID param specs 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/.
2019-08-29 17:25:35 +08:00
GimpParamSpecItem *ispec = GIMP_PARAM_SPEC_ITEM (pspec);
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
param_def->param_def_type = GP_PARAM_DEF_TYPE_ID;
param_def->meta.m_id.none_ok = ispec->none_ok;
}
app, libgimp: get rid of all ID GTypes and ID param specs 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/.
2019-08-29 17:25:35 +08:00
else if (pspec_type == GIMP_TYPE_PARAM_DISPLAY)
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
{
app, libgimp: get rid of all ID GTypes and ID param specs 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/.
2019-08-29 17:25:35 +08:00
GimpParamSpecDisplay *ispec = GIMP_PARAM_SPEC_DISPLAY (pspec);
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
param_def->param_def_type = GP_PARAM_DEF_TYPE_ID;
2.99 libgimp: add GimpResource, GimpBrush, GimpPropWidgetBrush So procedures can declare args and GimpProcedureDialog show chooser widgets Fix so is no error dialog on id_is_valid for resources Palette.pdb changes and testing Memory mgt changes Gradient pdb Font and Pattern tests Test brush, palette Cleanup, remove generator Rebase, edit docs, install test-dialog.py Whitespace, and fix failed distcheck Fix some clang-format, fix fail distcheck Fix distcheck Cleanup from review Jehan
2022-09-06 07:28:35 +08:00
param_def->meta.m_id.none_ok = ispec->none_ok;
}
libgimp*: support having procedure arguments of generic type GimpResource.
2023-08-17 02:48:32 +08:00
else if (GIMP_IS_PARAM_SPEC_RESOURCE (pspec))
2.99 libgimp: add GimpResource, GimpBrush, GimpPropWidgetBrush So procedures can declare args and GimpProcedureDialog show chooser widgets Fix so is no error dialog on id_is_valid for resources Palette.pdb changes and testing Memory mgt changes Gradient pdb Font and Pattern tests Test brush, palette Cleanup, remove generator Rebase, edit docs, install test-dialog.py Whitespace, and fix failed distcheck Fix some clang-format, fix fail distcheck Fix distcheck Cleanup from review Jehan
2022-09-06 07:28:35 +08:00
{
app, libgimp, pdb, plug-ins: add ability to default to context for all resource args. Also fixes the passing of the resource param definitions through PDB. There was some weird assumption, with a comment, in commit 73733335c8 that this was unneeded, which meant that we were not able to properly recreate the right param spec over the wire.
2024-09-06 19:38:43 +08:00
GimpParamSpecResource *rspec = GIMP_PARAM_SPEC_RESOURCE (pspec);
GObject *default_value = NULL;
2.99 libgimp: add GimpResource, GimpBrush, GimpPropWidgetBrush So procedures can declare args and GimpProcedureDialog show chooser widgets Fix so is no error dialog on id_is_valid for resources Palette.pdb changes and testing Memory mgt changes Gradient pdb Font and Pattern tests Test brush, palette Cleanup, remove generator Rebase, edit docs, install test-dialog.py Whitespace, and fix failed distcheck Fix some clang-format, fix fail distcheck Fix distcheck Cleanup from review Jehan
2022-09-06 07:28:35 +08:00
app, libgimp, pdb, plug-ins: add ability to default to context for all resource args. Also fixes the passing of the resource param definitions through PDB. There was some weird assumption, with a comment, in commit 73733335c8 that this was unneeded, which meant that we were not able to properly recreate the right param spec over the wire.
2024-09-06 19:38:43 +08:00
param_def->param_def_type = GP_PARAM_DEF_TYPE_RESOURCE;
2.99 libgimp: add GimpResource, GimpBrush, GimpPropWidgetBrush So procedures can declare args and GimpProcedureDialog show chooser widgets Fix so is no error dialog on id_is_valid for resources Palette.pdb changes and testing Memory mgt changes Gradient pdb Font and Pattern tests Test brush, palette Cleanup, remove generator Rebase, edit docs, install test-dialog.py Whitespace, and fix failed distcheck Fix some clang-format, fix fail distcheck Fix distcheck Cleanup from review Jehan
2022-09-06 07:28:35 +08:00
app, libgimp, pdb, plug-ins: add ability to default to context for all resource args. Also fixes the passing of the resource param definitions through PDB. There was some weird assumption, with a comment, in commit 73733335c8 that this was unneeded, which meant that we were not able to properly recreate the right param spec over the wire.
2024-09-06 19:38:43 +08:00
if (gimp_param_spec_object_has_default (pspec))
default_value = gimp_param_spec_object_get_default (pspec);
param_def->meta.m_resource.none_ok = rspec->none_ok;
param_def->meta.m_resource.default_to_context = rspec->default_to_context;
if (default_value != NULL && ! rspec->default_to_context)
param_def->meta.m_resource.default_resource_id = get_resource_id (default_value);
else
param_def->meta.m_resource.default_resource_id = 0;
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
}
app, libgimp, pdb, plug-ins: new GimpCoreObjectArray type and drawablearray… … PDB type. This is a first step for #7369. Clearly our GimpObjectArray was meant to be used with C arrays, hence the wrapper function gimp_value_set_object_array() which was taking a C array and actually creating and setting a GimpObjectArray. This is why our new type is actually a C array aliased as a boxed type and containing its own size (thanks to NULL-termination). Eventually GimpCoreObjectArray is meant to replace GimpObjectArray. The only issue is that such a type does not allow NULL as a valid element in such an array, but fact is that I don't think we currently have any use case where this matters. If ever such a case arise in the future, we may introduce back GimpObjectArray. In this first commit, I replaced all itemarray PDB types with a new drawablearray using this new boxed type when relevant.
2024-10-22 03:59:26 +08:00
else if (GIMP_IS_PARAM_SPEC_CORE_OBJECT_ARRAY (pspec))
{
param_def->param_def_type = GP_PARAM_DEF_TYPE_ID_ARRAY;
param_def->meta.m_id_array.type_name =
(gchar *) g_type_name (GIMP_PARAM_SPEC_CORE_OBJECT_ARRAY (pspec)->object_type);
}
core, pdb, plug-ins: Create GimpExportOptions class This patch creates a GimpExportOptions class in both libgimpbase and in libgimp. Currently it is a mostly empty object, but it will be added to after 3.0 to allow for additional export options (like resizing on export while leaving the original image intact) libgimp/gimpexport.c was removed, and most of its content was copied into libgimp/gimpexportoptions.c. gimp_export_image () was replaced with gimp_export_options_get_image () in all export plug-ins. GimpExportProcedure has a new function to set the default image capabilities for each plug-in on creation. It also sets up a new callback function, which allows the options to respond to user setting changes (such as toggling 'Save as Animation' in the GIF or WEBP Plug-in).
2024-05-07 02:38:12 +08:00
else if (pspec_type == GIMP_TYPE_PARAM_EXPORT_OPTIONS)
{
param_def->param_def_type = GP_PARAM_DEF_TYPE_EXPORT_OPTIONS;
}
libgimpbase, libgimp, app: add libgimp support for passing GFiles 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.
2019-09-12 03:40:17 +08:00
else if (pspec_type == G_TYPE_PARAM_OBJECT &&
Issue #11319: support GeglColor as generic GParamObject of type GeglColor. In some binding (e.g. Python), we have not found how to create GeglParamColor specs for PDB procedures, so we use GParamObject specs with `GeglColor` object_type. Have our code handle both variants. Fixes: > GIMP-WARNING: _gimp_gp_param_def_to_param_spec: GParamSpec type unsupported 'GeglParamColor' Of course such generic spec won't have any future option which we may add to a dedicated param spec (and despite adding code to handle a default value, adding a default color still doesn't work according to tests).
2024-04-20 00:54:53 +08:00
value_type != G_TYPE_FILE &&
value_type != GEGL_TYPE_COLOR)
app, libgimp: support GParamParam as a GParamSpec also add forgotten support for GimpParamEnum.
2019-08-05 20:14:32 +08:00
{
libgimp: allow GObject plug-in parameters for known libgimp classes. 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.
2019-08-30 05:37:37 +08:00
const gchar *type_name = NULL;
app: split GimpDisplay in two classes: GimpDisplay and GimpDisplayImpl 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.
2019-09-04 20:27:18 +08:00
if (g_type_is_a (value_type, GIMP_TYPE_DISPLAY))
libgimp: allow GObject plug-in parameters for known libgimp classes. 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.
2019-08-30 05:37:37 +08:00
{
app: split GimpDisplay in two classes: GimpDisplay and GimpDisplayImpl 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.
2019-09-04 20:27:18 +08:00
/* g_type_is_a() because the core has a GimpDisplay subclasses */
libgimp: allow GObject plug-in parameters for known libgimp classes. 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.
2019-08-30 05:37:37 +08:00
type_name = "GimpParamDisplay";
}
else if (value_type == GIMP_TYPE_IMAGE)
{
type_name = "GimpParamImage";
}
else if (value_type == GIMP_TYPE_ITEM)
{
type_name = "GimpParamItem";
}
else if (value_type == GIMP_TYPE_DRAWABLE)
{
type_name = "GimpParamDrawable";
}
app, libgimp: initialize GimpGroupLayer. If the type is not registered, g_type_from_name() is not able to find the GType from the type name. Fixes: > gimp_gp_param_to_value: type name GimpGroupLayer is not registered Also add a bit more type handling code.
2024-07-08 04:17:44 +08:00
else if (value_type == GIMP_TYPE_LAYER)
libgimp: allow GObject plug-in parameters for known libgimp classes. 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.
2019-08-30 05:37:37 +08:00
{
type_name = "GimpParamLayer";
}
app, libgimp: initialize GimpGroupLayer. If the type is not registered, g_type_from_name() is not able to find the GType from the type name. Fixes: > gimp_gp_param_to_value: type name GimpGroupLayer is not registered Also add a bit more type handling code.
2024-07-08 04:17:44 +08:00
else if (value_type == GIMP_TYPE_TEXT_LAYER)
{
type_name = "GimpParamTextLayer";
}
else if (value_type == GIMP_TYPE_GROUP_LAYER)
{
type_name = "GimpParamGroupLayer";
}
libgimp: allow GObject plug-in parameters for known libgimp classes. 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.
2019-08-30 05:37:37 +08:00
else if (value_type == GIMP_TYPE_CHANNEL)
{
type_name = "GimpParamChannel";
}
else if (value_type == GIMP_TYPE_LAYER_MASK)
{
type_name = "GimpParamLayerMask";
}
else if (value_type == GIMP_TYPE_SELECTION)
{
type_name = "GimpParamSelection";
}
libgimp, app, pdb: Rename GimpVectors to GimpPath This commit renames the GimpVectors object to GimpPath in both app/core and in libgimp. It also renames the files to gimppath.[ch] and updates the relevant build and translation files. There are still outstanding gimp_vectors_* () functions on the app side that need to be renamed in a subsequent commit.
2024-07-12 14:16:25 +08:00
else if (value_type == GIMP_TYPE_PATH)
libgimp: allow GObject plug-in parameters for known libgimp classes. 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.
2019-08-30 05:37:37 +08:00
{
libgimp, app, pdb: Rename GimpVectors to GimpPath This commit renames the GimpVectors object to GimpPath in both app/core and in libgimp. It also renames the files to gimppath.[ch] and updates the relevant build and translation files. There are still outstanding gimp_vectors_* () functions on the app side that need to be renamed in a subsequent commit.
2024-07-12 14:16:25 +08:00
type_name = "GimpParamPath";
libgimp: allow GObject plug-in parameters for known libgimp classes. 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.
2019-08-30 05:37:37 +08:00
}
libgimp*: support having procedure arguments of generic type GimpResource.
2023-08-17 02:48:32 +08:00
else if (value_type == GIMP_TYPE_RESOURCE)
{
type_name = "GimpParamResource";
}
2.99 libgimp: add GimpResource, GimpBrush, GimpPropWidgetBrush So procedures can declare args and GimpProcedureDialog show chooser widgets Fix so is no error dialog on id_is_valid for resources Palette.pdb changes and testing Memory mgt changes Gradient pdb Font and Pattern tests Test brush, palette Cleanup, remove generator Rebase, edit docs, install test-dialog.py Whitespace, and fix failed distcheck Fix some clang-format, fix fail distcheck Fix distcheck Cleanup from review Jehan
2022-09-06 07:28:35 +08:00
else if (value_type == GIMP_TYPE_BRUSH)
{
type_name = "GimpParamBrush";
}
else if (value_type == GIMP_TYPE_FONT)
{
type_name = "GimpParamFont";
}
else if (value_type == GIMP_TYPE_GRADIENT)
{
type_name = "GimpParamGradient";
}
else if (value_type == GIMP_TYPE_PALETTE)
{
type_name = "GimpParamPalette";
}
else if (value_type == GIMP_TYPE_PATTERN)
{
type_name = "GimpParamPattern";
}
libgimp: allow GObject plug-in parameters for known libgimp classes. 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.
2019-08-30 05:37:37 +08:00
if (type_name)
{
param_def->param_def_type = GP_PARAM_DEF_TYPE_ID;
param_def->type_name = (gchar *) type_name;
param_def->meta.m_id.none_ok = TRUE;
}
else
{
2.99 libgimp: add GimpResource, GimpBrush, GimpPropWidgetBrush So procedures can declare args and GimpProcedureDialog show chooser widgets Fix so is no error dialog on id_is_valid for resources Palette.pdb changes and testing Memory mgt changes Gradient pdb Font and Pattern tests Test brush, palette Cleanup, remove generator Rebase, edit docs, install test-dialog.py Whitespace, and fix failed distcheck Fix some clang-format, fix fail distcheck Fix distcheck Cleanup from review Jehan
2022-09-06 07:28:35 +08:00
g_warning ("%s: GParamSpecObject for unsupported type '%s:%s'",
Introduce a global ID space for GimpData/GimpResource objects Much like for images and items. Change the PDB to transmit IDs instead of names for brush, pattern etc. and refactor a whole lot of libgimp code to deal with it. modified: libgimp/gimpplugin-private.h
2023-05-31 22:12:04 +08:00
G_STRFUNC,
param_def->type_name, param_def->value_type_name);
libgimp: allow GObject plug-in parameters for known libgimp classes. 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.
2019-08-30 05:37:37 +08:00
}
}
app, libgimp: get rid of all ID GTypes and ID param specs 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/.
2019-08-29 17:25:35 +08:00
}
libgimp: allow object GimpImage as procedure parameter. 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.
2019-08-13 18:34:09 +08:00
app, libgimp: get rid of all ID GTypes and ID param specs 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/.
2019-08-29 17:25:35 +08:00
static GimpImage *
get_image_by_id (gpointer gimp,
gint id)
{
#ifdef LIBGIMP_COMPILATION
return gimp_image_get_by_id (id);
#else
return gimp_image_get_by_id (gimp, id);
#endif
}
libgimp: make gimpgpparams-body.c identical for app/ and libgimp/ again 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.
2019-08-24 05:31:19 +08:00
app, libgimp: get rid of all ID GTypes and ID param specs 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/.
2019-08-29 17:25:35 +08:00
static GimpItem *
get_item_by_id (gpointer gimp,
gint id)
{
#ifdef LIBGIMP_COMPILATION
return gimp_item_get_by_id (id);
#else
return gimp_item_get_by_id (gimp, id);
#endif
}
app: split GimpDisplay in two classes: GimpDisplay and GimpDisplayImpl 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.
2019-09-04 20:27:18 +08:00
static GimpDisplay *
app, libgimp: get rid of all ID GTypes and ID param specs 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/.
2019-08-29 17:25:35 +08:00
get_display_by_id (gpointer gimp,
gint id)
{
#ifdef LIBGIMP_COMPILATION
app: split GimpDisplay in two classes: GimpDisplay and GimpDisplayImpl 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.
2019-09-04 20:27:18 +08:00
return gimp_display_get_by_id (id);
app, libgimp: get rid of all ID GTypes and ID param specs 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/.
2019-08-29 17:25:35 +08:00
#else
app: split GimpDisplay in two classes: GimpDisplay and GimpDisplayImpl 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.
2019-09-04 20:27:18 +08:00
return gimp_display_get_by_id (gimp, id);
app, libgimp: get rid of all ID GTypes and ID param specs 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/.
2019-08-29 17:25:35 +08:00
#endif
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
}
2.99 libgimp: add GimpResource, GimpBrush, GimpPropWidgetBrush So procedures can declare args and GimpProcedureDialog show chooser widgets Fix so is no error dialog on id_is_valid for resources Palette.pdb changes and testing Memory mgt changes Gradient pdb Font and Pattern tests Test brush, palette Cleanup, remove generator Rebase, edit docs, install test-dialog.py Whitespace, and fix failed distcheck Fix some clang-format, fix fail distcheck Fix distcheck Cleanup from review Jehan
2022-09-06 07:28:35 +08:00
static GObject *
Introduce a global ID space for GimpData/GimpResource objects Much like for images and items. Change the PDB to transmit IDs instead of names for brush, pattern etc. and refactor a whole lot of libgimp code to deal with it. modified: libgimp/gimpplugin-private.h
2023-05-31 22:12:04 +08:00
get_resource_by_id (gint id)
2.99 libgimp: add GimpResource, GimpBrush, GimpPropWidgetBrush So procedures can declare args and GimpProcedureDialog show chooser widgets Fix so is no error dialog on id_is_valid for resources Palette.pdb changes and testing Memory mgt changes Gradient pdb Font and Pattern tests Test brush, palette Cleanup, remove generator Rebase, edit docs, install test-dialog.py Whitespace, and fix failed distcheck Fix some clang-format, fix fail distcheck Fix distcheck Cleanup from review Jehan
2022-09-06 07:28:35 +08:00
{
#ifdef LIBGIMP_COMPILATION
Introduce a global ID space for GimpData/GimpResource objects Much like for images and items. Change the PDB to transmit IDs instead of names for brush, pattern etc. and refactor a whole lot of libgimp code to deal with it. modified: libgimp/gimpplugin-private.h
2023-05-31 22:12:04 +08:00
return (GObject *) gimp_resource_get_by_id (id);
2.99 libgimp: add GimpResource, GimpBrush, GimpPropWidgetBrush So procedures can declare args and GimpProcedureDialog show chooser widgets Fix so is no error dialog on id_is_valid for resources Palette.pdb changes and testing Memory mgt changes Gradient pdb Font and Pattern tests Test brush, palette Cleanup, remove generator Rebase, edit docs, install test-dialog.py Whitespace, and fix failed distcheck Fix some clang-format, fix fail distcheck Fix distcheck Cleanup from review Jehan
2022-09-06 07:28:35 +08:00
#else
Introduce a global ID space for GimpData/GimpResource objects Much like for images and items. Change the PDB to transmit IDs instead of names for brush, pattern etc. and refactor a whole lot of libgimp code to deal with it. modified: libgimp/gimpplugin-private.h
2023-05-31 22:12:04 +08:00
return (GObject *) gimp_data_get_by_id (id);
2.99 libgimp: add GimpResource, GimpBrush, GimpPropWidgetBrush So procedures can declare args and GimpProcedureDialog show chooser widgets Fix so is no error dialog on id_is_valid for resources Palette.pdb changes and testing Memory mgt changes Gradient pdb Font and Pattern tests Test brush, palette Cleanup, remove generator Rebase, edit docs, install test-dialog.py Whitespace, and fix failed distcheck Fix some clang-format, fix fail distcheck Fix distcheck Cleanup from review Jehan
2022-09-06 07:28:35 +08:00
#endif
}
Introduce a global ID space for GimpData/GimpResource objects Much like for images and items. Change the PDB to transmit IDs instead of names for brush, pattern etc. and refactor a whole lot of libgimp code to deal with it. modified: libgimp/gimpplugin-private.h
2023-05-31 22:12:04 +08:00
static gint
2.99 libgimp: add GimpResource, GimpBrush, GimpPropWidgetBrush So procedures can declare args and GimpProcedureDialog show chooser widgets Fix so is no error dialog on id_is_valid for resources Palette.pdb changes and testing Memory mgt changes Gradient pdb Font and Pattern tests Test brush, palette Cleanup, remove generator Rebase, edit docs, install test-dialog.py Whitespace, and fix failed distcheck Fix some clang-format, fix fail distcheck Fix distcheck Cleanup from review Jehan
2022-09-06 07:28:35 +08:00
get_resource_id (GObject *resource)
{
#ifdef LIBGIMP_COMPILATION
Introduce a global ID space for GimpData/GimpResource objects Much like for images and items. Change the PDB to transmit IDs instead of names for brush, pattern etc. and refactor a whole lot of libgimp code to deal with it. modified: libgimp/gimpplugin-private.h
2023-05-31 22:12:04 +08:00
return gimp_resource_get_id (GIMP_RESOURCE (resource));
2.99 libgimp: add GimpResource, GimpBrush, GimpPropWidgetBrush So procedures can declare args and GimpProcedureDialog show chooser widgets Fix so is no error dialog on id_is_valid for resources Palette.pdb changes and testing Memory mgt changes Gradient pdb Font and Pattern tests Test brush, palette Cleanup, remove generator Rebase, edit docs, install test-dialog.py Whitespace, and fix failed distcheck Fix some clang-format, fix fail distcheck Fix distcheck Cleanup from review Jehan
2022-09-06 07:28:35 +08:00
#else
Introduce a global ID space for GimpData/GimpResource objects Much like for images and items. Change the PDB to transmit IDs instead of names for brush, pattern etc. and refactor a whole lot of libgimp code to deal with it. modified: libgimp/gimpplugin-private.h
2023-05-31 22:12:04 +08:00
return gimp_data_get_id (GIMP_DATA (resource));
2.99 libgimp: add GimpResource, GimpBrush, GimpPropWidgetBrush So procedures can declare args and GimpProcedureDialog show chooser widgets Fix so is no error dialog on id_is_valid for resources Palette.pdb changes and testing Memory mgt changes Gradient pdb Font and Pattern tests Test brush, palette Cleanup, remove generator Rebase, edit docs, install test-dialog.py Whitespace, and fix failed distcheck Fix some clang-format, fix fail distcheck Fix distcheck Cleanup from review Jehan
2022-09-06 07:28:35 +08:00
#endif
}
Issue #8900 and #9923: reimplementing GimpUnit as a proper class. This fixes all our GObject Introspection issues with GimpUnit which was both an enum and an int-derived type of user-defined units *completing* the enum values. GIR clearly didn't like this! Now GimpUnit is a proper class and units are unique objects, allowing to compare them with an identity test (i.e. `unit == gimp_unit_pixel ()` tells us if unit is the pixel unit or not), which makes it easy to use, just like with int, yet adding also methods, making for nicer introspected API. As an aside, this also fixes #10738, by having all the built-in units retrievable even if libgimpbase had not been properly initialized with gimp_base_init(). I haven't checked in details how GIR works to introspect, but it looks like it loads the library to inspect and runs functions, hence triggering some CRITICALS because virtual methods (supposed to be initialized with gimp_base_init() run by libgimp) are not set. This new code won't trigger any critical because the vtable method are now not necessary, at least for all built-in units. Note that GimpUnit is still in libgimpbase. It could have been moved to libgimp in order to avoid any virtual method table (since we need to keep core and libgimp side's units in sync, PDB is required), but too many libgimpwidgets widgets were already using GimpUnit. And technically most of GimpUnit logic doesn't require PDB (only the creation/sync part). This is one of the reasons why user-created GimpUnit list is handled and stored differently from other types of objects. Globally this simplifies the code a lot too and we don't need separate implementations of various utils for core and libgimp, which means less prone to errors.
2024-07-26 02:55:21 +08:00
static GimpUnit *
get_unit_by_id (gpointer gimp,
gint id)
{
return gimp_unit_get_by_id (id);
}
2.99 libgimp: add GimpResource, GimpBrush, GimpPropWidgetBrush So procedures can declare args and GimpProcedureDialog show chooser widgets Fix so is no error dialog on id_is_valid for resources Palette.pdb changes and testing Memory mgt changes Gradient pdb Font and Pattern tests Test brush, palette Cleanup, remove generator Rebase, edit docs, install test-dialog.py Whitespace, and fix failed distcheck Fix some clang-format, fix fail distcheck Fix distcheck Cleanup from review Jehan
2022-09-06 07:28:35 +08:00
Introduce a global ID space for GimpData/GimpResource objects Much like for images and items. Change the PDB to transmit IDs instead of names for brush, pattern etc. and refactor a whole lot of libgimp code to deal with it. modified: libgimp/gimpplugin-private.h
2023-05-31 22:12:04 +08:00
/* Deserialize a gp_param (from the wire) to an instance of object or
* primitive type.
*
2.99 libgimp: add GimpResource, GimpBrush, GimpPropWidgetBrush So procedures can declare args and GimpProcedureDialog show chooser widgets Fix so is no error dialog on id_is_valid for resources Palette.pdb changes and testing Memory mgt changes Gradient pdb Font and Pattern tests Test brush, palette Cleanup, remove generator Rebase, edit docs, install test-dialog.py Whitespace, and fix failed distcheck Fix some clang-format, fix fail distcheck Fix distcheck Cleanup from review Jehan
2022-09-06 07:28:35 +08:00
* This is used on both the core and plugin (libgimp) side,
* each having its own class definitions for a same named class.
* Thus this creates different objects, depending on which side it is.
* See the conditionally compiled constructors/fetchers above.
*/
app, libgimp: make two functions of gimpgpparams private and remove a "gimp" parameter that is no longer needed.
2019-09-05 22:07:15 +08:00
static void
gimp_gp_param_to_value (gpointer gimp,
const GPParam *param,
GType type,
libgimp: allowing NULL passed as value to a GimpObjectArray PDB argument. A NULL will be transformed into an array of size 0.
2023-10-20 05:34:47 +08:00
GParamSpec *pspec,
libgimp: _gimp_gp_params_to_value_array() remove "gboolean full_copy" With all the GValue and GimpValueArray copying involved, we can't really make a shallow copy anyway, so don't let the API pretend we could.
2019-09-06 02:17:22 +08:00
GValue *value)
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
{
g_return_if_fail (param != NULL);
g_return_if_fail (value != NULL);
libgimp: fix #11813 CRITICAL on NULL GimpObjectArray to plugin We allow passing NULL gvalue for an empty GimpObjectArray, for convenience. For example to plugin sel2path which doesn't use drawables. But crossing the wire, create an empty GimpObjectArray having an arbitrary type for elements.
2024-07-18 03:46:06 +08:00
/* pspec is nullable. */
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
libgimp: fix #11813 CRITICAL on NULL GimpObjectArray to plugin We allow passing NULL gvalue for an empty GimpObjectArray, for convenience. For example to plugin sel2path which doesn't use drawables. But crossing the wire, create an empty GimpObjectArray having an arbitrary type for elements.
2024-07-18 03:46:06 +08:00
/* See also changing of types by caller. */
Fix plugins to use new GimpResource.
2022-09-06 07:28:35 +08:00
if (type == G_TYPE_NONE || type == G_TYPE_INVALID)
{
type = g_type_from_name (param->type_name);
if (type == 0)
Introduce a global ID space for GimpData/GimpResource objects Much like for images and items. Change the PDB to transmit IDs instead of names for brush, pattern etc. and refactor a whole lot of libgimp code to deal with it. modified: libgimp/gimpplugin-private.h
2023-05-31 22:12:04 +08:00
{
if (! strcmp (param->type_name, "GimpResource"))
type = g_type_from_name ("GimpData");
else if (! strcmp (param->type_name, "GimpData"))
type = g_type_from_name ("GimpResource");
else
g_critical ("%s: type name %s is not registered", G_STRFUNC,
param->type_name);
}
Fix plugins to use new GimpResource.
2022-09-06 07:28:35 +08:00
}
/* assert type is not G_TYPE_NONE and type is not G_TYPE_INVALID. */
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
g_value_init (value, type);
Issue #8900 and #9923: reimplementing GimpUnit as a proper class. This fixes all our GObject Introspection issues with GimpUnit which was both an enum and an int-derived type of user-defined units *completing* the enum values. GIR clearly didn't like this! Now GimpUnit is a proper class and units are unique objects, allowing to compare them with an identity test (i.e. `unit == gimp_unit_pixel ()` tells us if unit is the pixel unit or not), which makes it easy to use, just like with int, yet adding also methods, making for nicer introspected API. As an aside, this also fixes #10738, by having all the built-in units retrievable even if libgimpbase had not been properly initialized with gimp_base_init(). I haven't checked in details how GIR works to introspect, but it looks like it loads the library to inspect and runs functions, hence triggering some CRITICALS because virtual methods (supposed to be initialized with gimp_base_init() run by libgimp) are not set. This new code won't trigger any critical because the vtable method are now not necessary, at least for all built-in units. Note that GimpUnit is still in libgimpbase. It could have been moved to libgimp in order to avoid any virtual method table (since we need to keep core and libgimp side's units in sync, PDB is required), but too many libgimpwidgets widgets were already using GimpUnit. And technically most of GimpUnit logic doesn't require PDB (only the creation/sync part). This is one of the reasons why user-created GimpUnit list is handled and stored differently from other types of objects. Globally this simplifies the code a lot too and we don't need separate implementations of various utils for core and libgimp, which means less prone to errors.
2024-07-26 02:55:21 +08:00
if (type == G_TYPE_INT)
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
{
g_value_set_int (value, param->data.d_int);
}
else if (G_VALUE_HOLDS_UINT (value))
{
g_value_set_uint (value, param->data.d_int);
}
else if (G_VALUE_HOLDS_ENUM (value))
{
g_value_set_enum (value, param->data.d_int);
}
else if (G_VALUE_HOLDS_BOOLEAN (value))
{
g_value_set_boolean (value, param->data.d_int ? TRUE : FALSE);
}
else if (G_VALUE_HOLDS_DOUBLE (value))
{
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/. Several types functions were using the wording "float" historically to mean double-precision, e.g. the float array type (which was in fact a double array). Or the scanner function gimp_scanner_parse_float() was in fact returning a double value. What if we wanted someday to actually add float (usually this naming means in C the single-precision IEEE 754 floating point representation) support? How would we name this? Now technically it's not entirely wrong (a double is still a floating point). So I've been wondering if that is because maybe we never planned to have float and double precision may be good enough for all usage in a plug-in API (which doesn't have to be as generic so the higher precision is enough)? But how can we be sure? Also we already had some functions using the wording double (e.g. gimp_procedure_add_double_argument()), so let's just go the safe route and use the accurate wording. The additional change in PDB is internal, but there too, I was also finding very confusing that we were naming double-precision float as 'float' type. So I took the opportunity to update this. It doesn't change any signature. In fact the whole commit doesn't change any type or code logic, only naming, except for one bug fix in the middle which I encountered while renaming: in gimp_scanner_parse_deprecated_color(), I discovered a hidden bug in scanning (color-hsv*) values, which was mistakenly using a double type for an array of float.
2024-11-02 21:03:37 +08:00
g_value_set_double (value, param->data.d_double);
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
}
else if (G_VALUE_HOLDS_STRING (value))
{
libgimp: _gimp_gp_params_to_value_array() remove "gboolean full_copy" With all the GValue and GimpValueArray copying involved, we can't really make a shallow copy anyway, so don't let the API pretend we could.
2019-09-06 02:17:22 +08:00
g_value_set_string (value, param->data.d_string);
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
}
Remove GimpStringArray in favor of GStrv GLib has a specific type of NULL-terminated string arrays: `G_TYPE_STRV`, which is the `GType` of `char**` aka `GStrv`. By using this type, we can avoid having a `GimpStringArray` which is a bit cumbersome to use for both the C API, as well as bindings. By using `GStrv`, we allow other languages to pass on string lists as they are used to, while the bindings will make sure to do the right thing. In the end, it makes the API a little bit simpler for everyone, and reduces confusion for people who are used to working with string arrays in other C/GLib based code (and not having 2 different types to denote the same thing). Related: https://gitlab.gnome.org/GNOME/gimp/-/issues/5919
2020-12-24 04:15:43 +08:00
else if (G_VALUE_HOLDS (value, G_TYPE_STRV))
{
g_value_set_boxed (value, param->data.d_strv);
}
Remove GimpUint8Array in favor of GBytes GLib has a specific type for byte arrays: `GBytes` (and it's underlying GType `G_TYPE_BYTES`). By using this type, we can avoid having a `GimpUint8Array` which is a bit cumbersome to use for both the C API, as well as bindings. By using `GBytes`, we allow other languages to pass on byte arrays as they are used to, while the bindings will make sure to do the right thing. In the end, it makes the API a little bit simpler for everyone, and reduces confusion for people who are used to working with byte arrays in other C/GLib based code (and not having 2 different types to denote the same thing). Related: https://gitlab.gnome.org/GNOME/gimp/-/issues/5919
2023-05-24 05:37:46 +08:00
else if (G_VALUE_HOLDS (value, G_TYPE_BYTES))
{
g_value_set_boxed (value, param->data.d_bytes);
}
libgimp: support all subtypes of GFile. In particular if a GFile is created with g_file_new_for_path(), it will be a GLocalFile. We need this to be supported too.
2023-08-03 04:53:56 +08:00
else if (g_type_is_a (G_VALUE_TYPE (value), G_TYPE_FILE))
libgimpbase, libgimp, app: add libgimp support for passing GFiles 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.
2019-09-12 03:40:17 +08:00
{
g_value_take_object (value, (param->data.d_string ?
g_file_new_for_uri (param->data.d_string) :
NULL));
}
app, libgimp*, pdb: new "format" type in the PDB. We have a bunch of special-casing format passing through the PDB, but either we were only passing the encoding, or else we were reconstructing the full format through private intermediate functions. In the space-invasion world, this is not right. Let's have a proper "format" type for PDB which does all the relevant data-passing for us, once and for all! Note that I am creating a wrapper boxed type GimpBablFormat whose only goal is to have recognizable GValue since Babl types don't have GType-s. Moreover I'm not using the GeglParamSpecFormat either, because it just uses pointers which again are a bit annoying in our various PDB code. Having a simple boxed arg is better.
2024-09-21 03:55:21 +08:00
else if (GIMP_VALUE_HOLDS_BABL_FORMAT (value))
{
const Babl *format = NULL;
const Babl *space = NULL;
const gchar *encoding;
GimpColorProfile *profile;
encoding = param->data.d_format.encoding;
profile = gimp_color_profile_new_from_icc_profile (param->data.d_format.profile_data,
param->data.d_format.profile_size,
NULL);
if (profile)
{
GError *error = NULL;
space = gimp_color_profile_get_space (profile,
GIMP_COLOR_RENDERING_INTENT_RELATIVE_COLORIMETRIC,
&error);
if (! space)
{
g_printerr ("%s: failed to create Babl space from profile: %s\n",
G_STRFUNC, error->message);
g_clear_error (&error);
}
g_object_unref (profile);
}
format = babl_format_with_space (encoding, space);
g_value_set_boxed (value, format);
}
libgimp*, pdb: support of GeglColor in the PDB. Eventually this is meant to fully replace GimpRGB (as well as GimpHSV, GimpHSL and GimpCMYK), both in libgimp and in core code, as part of both the space invasion and the API rework. For this first commit, I keep this new object side by side to GimpRGB.
2023-11-04 04:26:51 +08:00
else if (GIMP_VALUE_HOLDS_COLOR (value))
{
GeglColor *color;
const Babl *format = NULL;
const Babl *space = NULL;
const gchar *encoding;
GimpColorProfile *profile;
gint bpp;
app, libgimp*, pdb: new "format" type in the PDB. We have a bunch of special-casing format passing through the PDB, but either we were only passing the encoding, or else we were reconstructing the full format through private intermediate functions. In the space-invasion world, this is not right. Let's have a proper "format" type for PDB which does all the relevant data-passing for us, once and for all! Note that I am creating a wrapper boxed type GimpBablFormat whose only goal is to have recognizable GValue since Babl types don't have GType-s. Moreover I'm not using the GeglParamSpecFormat either, because it just uses pointers which again are a bit annoying in our various PDB code. Having a simple boxed arg is better.
2024-09-21 03:55:21 +08:00
encoding = param->data.d_gegl_color.format.encoding;
profile = gimp_color_profile_new_from_icc_profile (param->data.d_gegl_color.format.profile_data,
param->data.d_gegl_color.format.profile_size,
libgimp*, pdb: support of GeglColor in the PDB. Eventually this is meant to fully replace GimpRGB (as well as GimpHSV, GimpHSL and GimpCMYK), both in libgimp and in core code, as part of both the space invasion and the API rework. For this first commit, I keep this new object side by side to GimpRGB.
2023-11-04 04:26:51 +08:00
NULL);
if (profile)
{
GError *error = NULL;
space = gimp_color_profile_get_space (profile,
GIMP_COLOR_RENDERING_INTENT_RELATIVE_COLORIMETRIC,
&error);
if (! space)
{
g_printerr ("%s: failed to create Babl space from profile: %s\n",
G_STRFUNC, error->message);
g_clear_error (&error);
}
g_object_unref (profile);
}
libgimp: Use RGB/A u8 format for indexed color params Resolves #11018. Currently, babl formats are saved as strings when passed as params. However, indexed palettes do not use a "standard" encoding string but are created from palettes (with a custom format). This results in an error when we attempt to recreate the babl format from the custom string encoding, as it doesn't exist at that point. This patch mitigates the problem by converting the indexed color to RGB/A 8-bit when used in params. In the future when indexed mode supports different color spaces and higher precision, we will need to remove the hard coding. For now, it solves the immediate problem.
2024-06-24 00:09:38 +08:00
libgimp*, pdb: support of GeglColor in the PDB. Eventually this is meant to fully replace GimpRGB (as well as GimpHSV, GimpHSL and GimpCMYK), both in libgimp and in core code, as part of both the space invasion and the API rework. For this first commit, I keep this new object side by side to GimpRGB.
2023-11-04 04:26:51 +08:00
format = babl_format_with_space (encoding, space);
color = gegl_color_new ("black");
bpp = babl_format_get_bytes_per_pixel (format);
if (bpp != param->data.d_gegl_color.size)
g_printerr ("%s: encoding \"%s\" expects %d bpp but data size is %d bpp.\n",
G_STRFUNC, encoding, bpp, param->data.d_gegl_color.size);
else
gegl_color_set_pixel (color, format, param->data.d_gegl_color.data);
g_value_take_object (value, color);
}
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
else if (GIMP_VALUE_HOLDS_PARASITE (value))
{
libgimp: _gimp_gp_params_to_value_array() remove "gboolean full_copy" With all the GValue and GimpValueArray copying involved, we can't really make a shallow copy anyway, so don't let the API pretend we could.
2019-09-06 02:17:22 +08:00
g_value_set_boxed (value, &param->data.d_parasite);
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
}
else if (GIMP_VALUE_HOLDS_INT32_ARRAY (value))
{
libgimp: _gimp_gp_params_to_value_array() remove "gboolean full_copy" With all the GValue and GimpValueArray copying involved, we can't really make a shallow copy anyway, so don't let the API pretend we could.
2019-09-06 02:17:22 +08:00
gimp_value_set_int32_array (value,
(gint32 *) param->data.d_array.data,
param->data.d_array.size /
sizeof (gint32));
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
}
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/. Several types functions were using the wording "float" historically to mean double-precision, e.g. the float array type (which was in fact a double array). Or the scanner function gimp_scanner_parse_float() was in fact returning a double value. What if we wanted someday to actually add float (usually this naming means in C the single-precision IEEE 754 floating point representation) support? How would we name this? Now technically it's not entirely wrong (a double is still a floating point). So I've been wondering if that is because maybe we never planned to have float and double precision may be good enough for all usage in a plug-in API (which doesn't have to be as generic so the higher precision is enough)? But how can we be sure? Also we already had some functions using the wording double (e.g. gimp_procedure_add_double_argument()), so let's just go the safe route and use the accurate wording. The additional change in PDB is internal, but there too, I was also finding very confusing that we were naming double-precision float as 'float' type. So I took the opportunity to update this. It doesn't change any signature. In fact the whole commit doesn't change any type or code logic, only naming, except for one bug fix in the middle which I encountered while renaming: in gimp_scanner_parse_deprecated_color(), I discovered a hidden bug in scanning (color-hsv*) values, which was mistakenly using a double type for an array of float.
2024-11-02 21:03:37 +08:00
else if (GIMP_VALUE_HOLDS_DOUBLE_ARRAY (value))
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
{
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/. Several types functions were using the wording "float" historically to mean double-precision, e.g. the float array type (which was in fact a double array). Or the scanner function gimp_scanner_parse_float() was in fact returning a double value. What if we wanted someday to actually add float (usually this naming means in C the single-precision IEEE 754 floating point representation) support? How would we name this? Now technically it's not entirely wrong (a double is still a floating point). So I've been wondering if that is because maybe we never planned to have float and double precision may be good enough for all usage in a plug-in API (which doesn't have to be as generic so the higher precision is enough)? But how can we be sure? Also we already had some functions using the wording double (e.g. gimp_procedure_add_double_argument()), so let's just go the safe route and use the accurate wording. The additional change in PDB is internal, but there too, I was also finding very confusing that we were naming double-precision float as 'float' type. So I took the opportunity to update this. It doesn't change any signature. In fact the whole commit doesn't change any type or code logic, only naming, except for one bug fix in the middle which I encountered while renaming: in gimp_scanner_parse_deprecated_color(), I discovered a hidden bug in scanning (color-hsv*) values, which was mistakenly using a double type for an array of float.
2024-11-02 21:03:37 +08:00
gimp_value_set_double_array (value,
libgimp: _gimp_gp_params_to_value_array() remove "gboolean full_copy" With all the GValue and GimpValueArray copying involved, we can't really make a shallow copy anyway, so don't let the API pretend we could.
2019-09-06 02:17:22 +08:00
(const gdouble *)
param->data.d_array.data,
param->data.d_array.size /
sizeof (gdouble));
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
}
app, libgimp, libgimpbase, pdb: GimpColorArray as a typedef to… … NULL-terminated array of GeglColor is now a boxed type usable in PDB.
2023-12-27 00:07:19 +08:00
else if (GIMP_VALUE_HOLDS_COLOR_ARRAY (value))
{
GeglColor **colors;
colors = g_new0 (GeglColor *, param->data.d_color_array.size + 1);
for (gint i = 0; i < param->data.d_color_array.size; i++)
{
GeglColor *color;
const Babl *format = NULL;
const Babl *space = NULL;
GimpColorProfile *profile = NULL;
const gchar *encoding;
gint bpp;
app, libgimp*, pdb: new "format" type in the PDB. We have a bunch of special-casing format passing through the PDB, but either we were only passing the encoding, or else we were reconstructing the full format through private intermediate functions. In the space-invasion world, this is not right. Let's have a proper "format" type for PDB which does all the relevant data-passing for us, once and for all! Note that I am creating a wrapper boxed type GimpBablFormat whose only goal is to have recognizable GValue since Babl types don't have GType-s. Moreover I'm not using the GeglParamSpecFormat either, because it just uses pointers which again are a bit annoying in our various PDB code. Having a simple boxed arg is better.
2024-09-21 03:55:21 +08:00
encoding = param->data.d_color_array.colors[i].format.encoding;
if (param->data.d_color_array.colors[i].format.profile_size > 0)
profile = gimp_color_profile_new_from_icc_profile (param->data.d_color_array.colors[i].format.profile_data,
param->data.d_color_array.colors[i].format.profile_size,
app, libgimp, libgimpbase, pdb: GimpColorArray as a typedef to… … NULL-terminated array of GeglColor is now a boxed type usable in PDB.
2023-12-27 00:07:19 +08:00
NULL);
if (profile)
{
GError *error = NULL;
space = gimp_color_profile_get_space (profile,
GIMP_COLOR_RENDERING_INTENT_RELATIVE_COLORIMETRIC,
&error);
if (! space)
{
g_printerr ("%s: failed to create Babl space from profile: %s\n",
G_STRFUNC, error->message);
g_clear_error (&error);
}
g_object_unref (profile);
}
format = babl_format_with_space (encoding, space);
color = gegl_color_new ("black");
bpp = babl_format_get_bytes_per_pixel (format);
if (bpp != param->data.d_color_array.colors[i].size)
g_printerr ("%s: encoding \"%s\" expects %d bpp but data size is %d bpp.\n",
G_STRFUNC, encoding, bpp, param->data.d_color_array.colors[i].size);
else
gegl_color_set_pixel (color, format, param->data.d_color_array.colors[i].data);
colors[i] = color;
}
g_value_take_boxed (value, colors);
}
app, libgimp, pdb, plug-ins: new GimpCoreObjectArray type and drawablearray… … PDB type. This is a first step for #7369. Clearly our GimpObjectArray was meant to be used with C arrays, hence the wrapper function gimp_value_set_object_array() which was taking a C array and actually creating and setting a GimpObjectArray. This is why our new type is actually a C array aliased as a boxed type and containing its own size (thanks to NULL-termination). Eventually GimpCoreObjectArray is meant to replace GimpObjectArray. The only issue is that such a type does not allow NULL as a valid element in such an array, but fact is that I don't think we currently have any use case where this matters. If ever such a case arise in the future, we may introduce back GimpObjectArray. In this first commit, I replaced all itemarray PDB types with a new drawablearray using this new boxed type when relevant.
2024-10-22 03:59:26 +08:00
else if (GIMP_VALUE_HOLDS_CORE_OBJECT_ARRAY (value))
{
GType object_type = G_TYPE_INVALID;
GObject **objects;
gint i;
if (param->data.d_id_array.type_name != NULL)
{
/* An empty array from a NULL has an arbitrary type_name set earlier. */
object_type = g_type_from_name (param->data.d_id_array.type_name);
}
else if (pspec != NULL)
{
object_type = GIMP_PARAM_SPEC_CORE_OBJECT_ARRAY (pspec)->object_type;
}
if (param->data.d_id_array.size > 1 && ! g_type_is_a (object_type, G_TYPE_OBJECT))
{
g_warning ("%s: GimpCoreObjectArray of unknown type.", G_STRFUNC);
return;
}
/* size might be zero. */
objects = g_new0 (GObject *, param->data.d_id_array.size + 1);
for (i = 0; i < param->data.d_id_array.size; i++)
{
gint id = param->data.d_id_array.data[i];
if (object_type == GIMP_TYPE_IMAGE)
{
objects[i] = (GObject *) get_image_by_id (gimp, id);
}
else if (g_type_is_a (object_type, GIMP_TYPE_ITEM))
{
objects[i] = (GObject *) get_item_by_id (gimp, id);
}
else if (g_type_is_a (object_type, GIMP_TYPE_DISPLAY))
{
objects[i] = (GObject *) get_display_by_id (gimp, id);
}
else if (g_type_is_a (object_type, GIMP_TYPE_RESOURCE))
{
objects[i] = (GObject *) get_resource_by_id (id);
}
}
/* Even when size is zero, set gvalue to an empty GimpObjectArray object,
* having a valid but possibly arbitrary type of its elements.
*/
g_value_set_boxed (value, objects);
}
app, libgimp: get rid of all ID GTypes and ID param specs 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/.
2019-08-29 17:25:35 +08:00
else if (GIMP_VALUE_HOLDS_IMAGE (value))
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
{
app, libgimp: get rid of all ID GTypes and ID param specs 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/.
2019-08-29 17:25:35 +08:00
g_value_set_object (value, get_image_by_id (gimp, param->data.d_int));
}
else if (GIMP_VALUE_HOLDS_ITEM (value))
{
g_value_set_object (value, get_item_by_id (gimp, param->data.d_int));
}
else if (GIMP_VALUE_HOLDS_DISPLAY (value))
{
g_value_set_object (value, get_display_by_id (gimp, param->data.d_int));
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
}
2.99 libgimp: add GimpResource, GimpBrush, GimpPropWidgetBrush So procedures can declare args and GimpProcedureDialog show chooser widgets Fix so is no error dialog on id_is_valid for resources Palette.pdb changes and testing Memory mgt changes Gradient pdb Font and Pattern tests Test brush, palette Cleanup, remove generator Rebase, edit docs, install test-dialog.py Whitespace, and fix failed distcheck Fix some clang-format, fix fail distcheck Fix distcheck Cleanup from review Jehan
2022-09-06 07:28:35 +08:00
else if (GIMP_VALUE_HOLDS_RESOURCE (value))
{
Introduce a global ID space for GimpData/GimpResource objects Much like for images and items. Change the PDB to transmit IDs instead of names for brush, pattern etc. and refactor a whole lot of libgimp code to deal with it. modified: libgimp/gimpplugin-private.h
2023-05-31 22:12:04 +08:00
g_value_set_object (value, get_resource_by_id (param->data.d_int));
2.99 libgimp: add GimpResource, GimpBrush, GimpPropWidgetBrush So procedures can declare args and GimpProcedureDialog show chooser widgets Fix so is no error dialog on id_is_valid for resources Palette.pdb changes and testing Memory mgt changes Gradient pdb Font and Pattern tests Test brush, palette Cleanup, remove generator Rebase, edit docs, install test-dialog.py Whitespace, and fix failed distcheck Fix some clang-format, fix fail distcheck Fix distcheck Cleanup from review Jehan
2022-09-06 07:28:35 +08:00
}
Issue #8900 and #9923: reimplementing GimpUnit as a proper class. This fixes all our GObject Introspection issues with GimpUnit which was both an enum and an int-derived type of user-defined units *completing* the enum values. GIR clearly didn't like this! Now GimpUnit is a proper class and units are unique objects, allowing to compare them with an identity test (i.e. `unit == gimp_unit_pixel ()` tells us if unit is the pixel unit or not), which makes it easy to use, just like with int, yet adding also methods, making for nicer introspected API. As an aside, this also fixes #10738, by having all the built-in units retrievable even if libgimpbase had not been properly initialized with gimp_base_init(). I haven't checked in details how GIR works to introspect, but it looks like it loads the library to inspect and runs functions, hence triggering some CRITICALS because virtual methods (supposed to be initialized with gimp_base_init() run by libgimp) are not set. This new code won't trigger any critical because the vtable method are now not necessary, at least for all built-in units. Note that GimpUnit is still in libgimpbase. It could have been moved to libgimp in order to avoid any virtual method table (since we need to keep core and libgimp side's units in sync, PDB is required), but too many libgimpwidgets widgets were already using GimpUnit. And technically most of GimpUnit logic doesn't require PDB (only the creation/sync part). This is one of the reasons why user-created GimpUnit list is handled and stored differently from other types of objects. Globally this simplifies the code a lot too and we don't need separate implementations of various utils for core and libgimp, which means less prone to errors.
2024-07-26 02:55:21 +08:00
else if (GIMP_VALUE_HOLDS_UNIT (value))
{
g_value_set_object (value, get_unit_by_id (gimp, param->data.d_int));
}
core, pdb, plug-ins: Create GimpExportOptions class This patch creates a GimpExportOptions class in both libgimpbase and in libgimp. Currently it is a mostly empty object, but it will be added to after 3.0 to allow for additional export options (like resizing on export while leaving the original image intact) libgimp/gimpexport.c was removed, and most of its content was copied into libgimp/gimpexportoptions.c. gimp_export_image () was replaced with gimp_export_options_get_image () in all export plug-ins. GimpExportProcedure has a new function to set the default image capabilities for each plug-in on creation. It also sets up a new callback function, which allows the options to respond to user setting changes (such as toggling 'Save as Animation' in the GIF or WEBP Plug-in).
2024-05-07 02:38:12 +08:00
else if (g_type_is_a (G_VALUE_TYPE (value), GIMP_TYPE_EXPORT_OPTIONS))
{
app, libgimp*, pdb, plug-ins: review and enhance MR !1549. - Fix annotations for gimp_export_options_get_image() to make it actually introspectable with the GimpImage being both input and output. Even though the logic doesn't change much (the input image may be overriden or not), it doesn't matter for introspection because images are handled centrally by libgimp and therefore must not be freed. Actually deleting the image from the central list of images though remains a manual action depending on code logic, not some automatic action to be handled by binding engines. - Add G_GNUC_WARN_UNUSED_RESULT to gimp_export_options_get_image() because ignoring the returned value is rarely a good idea (as you usually want to delete the image). - Remove gimp_export_options_new(): we don't need this constructor because at this point, the best is to tell plug-in developers to just pass NULL everywhere. This leaves us free to create a more useful default constructor if needed, in the future. Main description for GimpExportOptions has also been updated to say this. - Add a data_destroy callback for the user data passed in gimp_export_procedure_set_capabilities(). - Fixing annotations of 'export_options' object from pdb/pdb.pl: input args would actually be (nullable) and would not transfer ownership (calling code must still free the object). Return value's ownership on the other hand is fully transfered. - Add C and Python unit testing for GimpExportOptions and gimp_export_options_get_image() in particular. - Fix or improve various details. Note that I have also considered for a long time changing the signature of gimp_export_options_get_image() to return a boolean indicating whether `image` had been replaced (hence needed deletion) or not. This also meant getting rid of the GimpExportReturn enum. Right now it would work because there are no third case, but I was considering the future possibility that for instance we got some impossible conversion for some future capability. I'm not sure it would ever happen; and for sure, this is not desirable because it implies an export failure a bit late in the workflow. But just in case, let's keep the enum return value. It does not even make the using code that much more complicated (well just a value comparison instead of a simple boolean test).
2024-08-17 21:06:27 +08:00
GimpExportOptions *options;
core, pdb, plug-ins: Create GimpExportOptions class This patch creates a GimpExportOptions class in both libgimpbase and in libgimp. Currently it is a mostly empty object, but it will be added to after 3.0 to allow for additional export options (like resizing on export while leaving the original image intact) libgimp/gimpexport.c was removed, and most of its content was copied into libgimp/gimpexportoptions.c. gimp_export_image () was replaced with gimp_export_options_get_image () in all export plug-ins. GimpExportProcedure has a new function to set the default image capabilities for each plug-in on creation. It also sets up a new callback function, which allows the options to respond to user setting changes (such as toggling 'Save as Animation' in the GIF or WEBP Plug-in).
2024-05-07 02:38:12 +08:00
app, libgimp*, pdb, plug-ins: capabilities should not be part of GimpParamSpecExportOptions. The param option just contains an options object, not a separate capabilities. Also even when passing the options object across the wire, the capabilities within this object are not part of the "options". These are actually handled separated by GimpExportProcedure. Therefore the changes are: * GimpExportCapabilities moved to gimpbaseenums.h with a proper GType. * "capabilities" properties are changed to flags param spec with type GimpExportCapabilities. * GimpParamSpecExportOptions doesn't have a capabilities variable anymore. * Consequently gimp_param_spec_export_options() doesn't have a capabilities arg. * Wire protocol updated as we don't need to pass any capabilities neither for the param definition, nor for the argument values. * GimpExportOptionsEditFunc renamed GimpExportGetCapabilitiesFunc and returning GimpExportCapabilities flags, instead of setting the "capabilities" property. I believe it makes it much more obvious what this callback is for and how to use it. * Annotations improved or completed. * Don't make the GimpParamSpecExportOptions public anymore since it is the same as its parent.
2024-11-02 02:13:02 +08:00
/* Recreating the same options when it'll have settings. The
* "capabilities" property doesn't need to be recreated. It is
* managed by the GimpExportProcedure code.
*/
options = g_object_new (GIMP_TYPE_EXPORT_OPTIONS, NULL);
core, pdb, plug-ins: Create GimpExportOptions class This patch creates a GimpExportOptions class in both libgimpbase and in libgimp. Currently it is a mostly empty object, but it will be added to after 3.0 to allow for additional export options (like resizing on export while leaving the original image intact) libgimp/gimpexport.c was removed, and most of its content was copied into libgimp/gimpexportoptions.c. gimp_export_image () was replaced with gimp_export_options_get_image () in all export plug-ins. GimpExportProcedure has a new function to set the default image capabilities for each plug-in on creation. It also sets up a new callback function, which allows the options to respond to user setting changes (such as toggling 'Save as Animation' in the GIF or WEBP Plug-in).
2024-05-07 02:38:12 +08:00
g_value_set_object (value, options);
g_object_unref (options);
}
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
else if (G_VALUE_HOLDS_PARAM (value))
{
GParamSpec *pspec =
app, libgimp: make two functions of gimpgpparams private and remove a "gimp" parameter that is no longer needed.
2019-09-05 22:07:15 +08:00
_gimp_gp_param_def_to_param_spec (&param->data.d_param_def);
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
g_value_take_param (value, pspec);
}
2.99 libgimp: add GimpResource, GimpBrush, GimpPropWidgetBrush So procedures can declare args and GimpProcedureDialog show chooser widgets Fix so is no error dialog on id_is_valid for resources Palette.pdb changes and testing Memory mgt changes Gradient pdb Font and Pattern tests Test brush, palette Cleanup, remove generator Rebase, edit docs, install test-dialog.py Whitespace, and fix failed distcheck Fix some clang-format, fix fail distcheck Fix distcheck Cleanup from review Jehan
2022-09-06 07:28:35 +08:00
else
{
g_warning ("%s: unsupported deserialization to GValue of type '%s'\n",
G_STRFUNC, param->type_name);
}
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
}
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
GimpValueArray *
libgimp: add some const to input parameters, like const GimpValueArray* for procedure arguments. This implies creating a new value array in gimp_procedure_run() if the passed array is too short, instead of just appending to the passed array, which was ugly anyway.
2019-08-07 06:02:29 +08:00
_gimp_gp_params_to_value_array (gpointer gimp,
GParamSpec **pspecs,
gint n_pspecs,
const GPParam *params,
gint n_params,
libgimp: _gimp_gp_params_to_value_array() remove "gboolean full_copy" With all the GValue and GimpValueArray copying involved, we can't really make a shallow copy anyway, so don't let the API pretend we could.
2019-09-06 02:17:22 +08:00
gboolean return_values)
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
{
GimpValueArray *args;
gint i;
g_return_val_if_fail ((params != NULL && n_params > 0) ||
(params == NULL && n_params == 0), NULL);
args = gimp_value_array_new (n_params);
for (i = 0; i < n_params; i++)
{
libgimp: allowing NULL passed as value to a GimpObjectArray PDB argument. A NULL will be transformed into an array of size 0.
2023-10-20 05:34:47 +08:00
GParamSpec *pspec = NULL;
GValue value = G_VALUE_INIT;
GType type;
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
/* first get the GType from the passed GPParam */
type = g_type_from_name (params[i].type_name);
/* then try to try to be more specific by looking at the param
* spec (return values have one additional value (the status),
* skip that, it's not in the array of param specs)
*/
if (i > 0 || ! return_values)
{
gint pspec_index = i;
if (return_values)
pspec_index--;
/* are there param specs left? */
if (pspec_index < n_pspecs)
{
GType pspec_type = G_PARAM_SPEC_VALUE_TYPE (pspecs[pspec_index]);
libgimp: allowing NULL passed as value to a GimpObjectArray PDB argument. A NULL will be transformed into an array of size 0.
2023-10-20 05:34:47 +08:00
pspec = pspecs[pspec_index];
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
if (type != pspec_type)
{
if (g_type_is_a (pspec_type, type))
{
/* if the param spec's GType is more specific
* than the one from the GPParam, use the param
* spec's GType.
*/
type = pspec_type;
}
Remove GIMP_TYPE_INT32 and GimpParamSpecInt32 Use gint and GParamSpecInt instead.
2019-08-15 20:04:56 +08:00
else if (type == G_TYPE_INT)
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
{
if (g_type_is_a (pspec_type, G_TYPE_ENUM))
{
/* if the param spec's type is enum, but an
Remove GIMP_TYPE_INT32 and GimpParamSpecInt32 Use gint and GParamSpecInt instead.
2019-08-15 20:04:56 +08:00
* int was passed, use the enum type.
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
*/
type = pspec_type;
}
else if (g_type_is_a (pspec_type, G_TYPE_BOOLEAN))
{
/* if the param spec's type is boolean, but
Remove GIMP_TYPE_INT32 and GimpParamSpecInt32 Use gint and GParamSpecInt instead.
2019-08-15 20:04:56 +08:00
* an int was passed, use the boolean
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
* type.
*/
type = pspec_type;
}
}
}
}
}
libgimp: allowing NULL passed as value to a GimpObjectArray PDB argument. A NULL will be transformed into an array of size 0.
2023-10-20 05:34:47 +08:00
gimp_gp_param_to_value (gimp, &params[i], type, pspec, &value);
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
gimp_value_array_append (args, &value);
g_value_unset (&value);
}
return args;
}
app, libgimp: make two functions of gimpgpparams private and remove a "gimp" parameter that is no longer needed.
2019-09-05 22:07:15 +08:00
static void
gimp_value_to_gp_param (const GValue *value,
GPParam *param,
gboolean full_copy)
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
{
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
GType type;
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
g_return_if_fail (value != NULL);
g_return_if_fail (param != NULL);
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
libgimp: make gimpgpparams-body.c identical for app/ and libgimp/ again 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.
2019-08-24 05:31:19 +08:00
type = G_VALUE_TYPE (value);
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
param->param_type = -1;
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
if (full_copy)
param->type_name = g_strdup (g_type_name (type));
else
param->type_name = (gchar *) g_type_name (type);
Issue #8900 and #9923: reimplementing GimpUnit as a proper class. This fixes all our GObject Introspection issues with GimpUnit which was both an enum and an int-derived type of user-defined units *completing* the enum values. GIR clearly didn't like this! Now GimpUnit is a proper class and units are unique objects, allowing to compare them with an identity test (i.e. `unit == gimp_unit_pixel ()` tells us if unit is the pixel unit or not), which makes it easy to use, just like with int, yet adding also methods, making for nicer introspected API. As an aside, this also fixes #10738, by having all the built-in units retrievable even if libgimpbase had not been properly initialized with gimp_base_init(). I haven't checked in details how GIR works to introspect, but it looks like it loads the library to inspect and runs functions, hence triggering some CRITICALS because virtual methods (supposed to be initialized with gimp_base_init() run by libgimp) are not set. This new code won't trigger any critical because the vtable method are now not necessary, at least for all built-in units. Note that GimpUnit is still in libgimpbase. It could have been moved to libgimp in order to avoid any virtual method table (since we need to keep core and libgimp side's units in sync, PDB is required), but too many libgimpwidgets widgets were already using GimpUnit. And technically most of GimpUnit logic doesn't require PDB (only the creation/sync part). This is one of the reasons why user-created GimpUnit list is handled and stored differently from other types of objects. Globally this simplifies the code a lot too and we don't need separate implementations of various utils for core and libgimp, which means less prone to errors.
2024-07-26 02:55:21 +08:00
if (type == G_TYPE_INT)
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
{
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
param->param_type = GP_PARAM_TYPE_INT;
param->data.d_int = g_value_get_int (value);
}
Remove GIMP_TYPE_INT8 and GimpParamSpecInt8 Use guchar and GParamSpecUChar instead.
2019-08-15 19:34:11 +08:00
else if (type == G_TYPE_UINT)
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
{
param->param_type = GP_PARAM_TYPE_INT;
param->data.d_int = g_value_get_uint (value);
}
Remove GIMP_TYPE_INT8 and GimpParamSpecInt8 Use guchar and GParamSpecUChar instead.
2019-08-15 19:34:11 +08:00
else if (type == G_TYPE_UCHAR)
{
param->param_type = GP_PARAM_TYPE_INT;
param->data.d_int = g_value_get_uchar (value);
}
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
else if (G_VALUE_HOLDS_ENUM (value))
{
param->param_type = GP_PARAM_TYPE_INT;
param->data.d_int = g_value_get_enum (value);
}
else if (G_VALUE_HOLDS_BOOLEAN (value))
{
param->param_type = GP_PARAM_TYPE_INT;
param->data.d_int = g_value_get_boolean (value);
}
else if (G_VALUE_HOLDS_DOUBLE (value))
{
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/. Several types functions were using the wording "float" historically to mean double-precision, e.g. the float array type (which was in fact a double array). Or the scanner function gimp_scanner_parse_float() was in fact returning a double value. What if we wanted someday to actually add float (usually this naming means in C the single-precision IEEE 754 floating point representation) support? How would we name this? Now technically it's not entirely wrong (a double is still a floating point). So I've been wondering if that is because maybe we never planned to have float and double precision may be good enough for all usage in a plug-in API (which doesn't have to be as generic so the higher precision is enough)? But how can we be sure? Also we already had some functions using the wording double (e.g. gimp_procedure_add_double_argument()), so let's just go the safe route and use the accurate wording. The additional change in PDB is internal, but there too, I was also finding very confusing that we were naming double-precision float as 'float' type. So I took the opportunity to update this. It doesn't change any signature. In fact the whole commit doesn't change any type or code logic, only naming, except for one bug fix in the middle which I encountered while renaming: in gimp_scanner_parse_deprecated_color(), I discovered a hidden bug in scanning (color-hsv*) values, which was mistakenly using a double type for an array of float.
2024-11-02 21:03:37 +08:00
param->param_type = GP_PARAM_TYPE_DOUBLE;
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/. Several types functions were using the wording "float" historically to mean double-precision, e.g. the float array type (which was in fact a double array). Or the scanner function gimp_scanner_parse_float() was in fact returning a double value. What if we wanted someday to actually add float (usually this naming means in C the single-precision IEEE 754 floating point representation) support? How would we name this? Now technically it's not entirely wrong (a double is still a floating point). So I've been wondering if that is because maybe we never planned to have float and double precision may be good enough for all usage in a plug-in API (which doesn't have to be as generic so the higher precision is enough)? But how can we be sure? Also we already had some functions using the wording double (e.g. gimp_procedure_add_double_argument()), so let's just go the safe route and use the accurate wording. The additional change in PDB is internal, but there too, I was also finding very confusing that we were naming double-precision float as 'float' type. So I took the opportunity to update this. It doesn't change any signature. In fact the whole commit doesn't change any type or code logic, only naming, except for one bug fix in the middle which I encountered while renaming: in gimp_scanner_parse_deprecated_color(), I discovered a hidden bug in scanning (color-hsv*) values, which was mistakenly using a double type for an array of float.
2024-11-02 21:03:37 +08:00
param->data.d_double = g_value_get_double (value);
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
}
else if (G_VALUE_HOLDS_STRING (value))
{
param->param_type = GP_PARAM_TYPE_STRING;
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
if (full_copy)
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
param->data.d_string = g_value_dup_string (value);
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
else
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
param->data.d_string = (gchar *) g_value_get_string (value);
}
libgimp: support all subtypes of GFile. In particular if a GFile is created with g_file_new_for_path(), it will be a GLocalFile. We need this to be supported too.
2023-08-03 04:53:56 +08:00
else if (g_type_is_a (G_VALUE_TYPE (value), G_TYPE_FILE))
libgimpbase, libgimp, app: add libgimp support for passing GFiles 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.
2019-09-12 03:40:17 +08:00
{
GFile *file = g_value_get_object (value);
param->param_type = GP_PARAM_TYPE_FILE;
param->data.d_string = file ? g_file_get_uri (file) : NULL;
}
app, libgimp*, pdb: new "format" type in the PDB. We have a bunch of special-casing format passing through the PDB, but either we were only passing the encoding, or else we were reconstructing the full format through private intermediate functions. In the space-invasion world, this is not right. Let's have a proper "format" type for PDB which does all the relevant data-passing for us, once and for all! Note that I am creating a wrapper boxed type GimpBablFormat whose only goal is to have recognizable GValue since Babl types don't have GType-s. Moreover I'm not using the GeglParamSpecFormat either, because it just uses pointers which again are a bit annoying in our various PDB code. Having a simple boxed arg is better.
2024-09-21 03:55:21 +08:00
else if (GIMP_VALUE_HOLDS_BABL_FORMAT (value))
{
const Babl *format;
int icc_length = 0;
param->param_type = GP_PARAM_TYPE_BABL_FORMAT;
format = g_value_get_boxed (value);
/* TODO: For indexed colors, we'll convert to R'G'B'(A) u8 as that
* is currently what we support. As indexed format support improves,
* we'll want to make this space and encoding agnostic. */
if (babl_format_is_palette (format))
{
const Babl *indexed_format = NULL;
gint bpp;
g_warning ("%s: GValue of type '%s' holds an indexed format. "
"This is unsupported and replaced with \"R'G'B' u8\".",
G_STRFUNC, param->type_name);
bpp = babl_format_get_bytes_per_pixel (format);
if (bpp == 1)
indexed_format = babl_format_with_space ("R'G'B' u8",
babl_format_get_space (format));
else if (bpp == 2)
indexed_format = babl_format_with_space ("R'G'B'A u8",
babl_format_get_space (format));
/* TODO: This is to notify us in the future when indexed image can have more than
* 256 colors - we'll need to update encoding support accordingly */
g_return_if_fail (indexed_format != NULL);
format = indexed_format;
}
param->data.d_format.encoding = (gchar *) babl_format_get_encoding (format);
param->data.d_format.profile_data = (guint8 *) babl_space_get_icc (babl_format_get_space (format),
&icc_length);
param->data.d_format.profile_size = icc_length;
}
libgimp*, pdb: support of GeglColor in the PDB. Eventually this is meant to fully replace GimpRGB (as well as GimpHSV, GimpHSL and GimpCMYK), both in libgimp and in core code, as part of both the space invasion and the API rework. For this first commit, I keep this new object side by side to GimpRGB.
2023-11-04 04:26:51 +08:00
else if (GIMP_VALUE_HOLDS_COLOR (value))
{
GeglColor *color;
const Babl *format;
int icc_length = 0;
param->param_type = GP_PARAM_TYPE_GEGL_COLOR;
color = g_value_get_object (value);
format = gegl_color_get_format (color);
libgimp: Use RGB/A u8 format for indexed color params Resolves #11018. Currently, babl formats are saved as strings when passed as params. However, indexed palettes do not use a "standard" encoding string but are created from palettes (with a custom format). This results in an error when we attempt to recreate the babl format from the custom string encoding, as it doesn't exist at that point. This patch mitigates the problem by converting the indexed color to RGB/A 8-bit when used in params. In the future when indexed mode supports different color spaces and higher precision, we will need to remove the hard coding. For now, it solves the immediate problem.
2024-06-24 00:09:38 +08:00
/* TODO: For indexed colors, we'll convert to R'G'B'(A) u8 as that
* is currently what we support. As indexed format support improves,
* we'll want to make this space and encoding agnostic. */
if (babl_format_is_palette (format))
{
const Babl *indexed_format = NULL;
gint bpp;
bpp = babl_format_get_bytes_per_pixel (format);
if (bpp == 1)
indexed_format = babl_format_with_space ("R'G'B' u8",
babl_format_get_space (format));
else if (bpp == 2)
indexed_format = babl_format_with_space ("R'G'B'A u8",
babl_format_get_space (format));
/* TODO: This is to notify us in the future when indexed image can have more than
* 256 colors - we'll need to update encoding support accordingly */
g_return_if_fail (indexed_format != NULL);
format = indexed_format;
}
libgimp*, pdb: support of GeglColor in the PDB. Eventually this is meant to fully replace GimpRGB (as well as GimpHSV, GimpHSL and GimpCMYK), both in libgimp and in core code, as part of both the space invasion and the API rework. For this first commit, I keep this new object side by side to GimpRGB.
2023-11-04 04:26:51 +08:00
param->data.d_gegl_color.size = babl_format_get_bytes_per_pixel (format);
gegl_color_get_pixel (color, format, &param->data.d_gegl_color.data);
app, libgimp*, pdb: new "format" type in the PDB. We have a bunch of special-casing format passing through the PDB, but either we were only passing the encoding, or else we were reconstructing the full format through private intermediate functions. In the space-invasion world, this is not right. Let's have a proper "format" type for PDB which does all the relevant data-passing for us, once and for all! Note that I am creating a wrapper boxed type GimpBablFormat whose only goal is to have recognizable GValue since Babl types don't have GType-s. Moreover I'm not using the GeglParamSpecFormat either, because it just uses pointers which again are a bit annoying in our various PDB code. Having a simple boxed arg is better.
2024-09-21 03:55:21 +08:00
param->data.d_gegl_color.format.encoding = (gchar *) babl_format_get_encoding (format);
param->data.d_gegl_color.format.profile_data = (guint8 *) babl_space_get_icc (babl_format_get_space (format),
&icc_length);
param->data.d_gegl_color.format.profile_size = icc_length;
libgimp*, pdb: support of GeglColor in the PDB. Eventually this is meant to fully replace GimpRGB (as well as GimpHSV, GimpHSL and GimpCMYK), both in libgimp and in core code, as part of both the space invasion and the API rework. For this first commit, I keep this new object side by side to GimpRGB.
2023-11-04 04:26:51 +08:00
}
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
else if (GIMP_VALUE_HOLDS_PARASITE (value))
{
GimpParasite *parasite = (full_copy ?
g_value_dup_boxed (value) :
g_value_get_boxed (value));
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
param->param_type = GP_PARAM_TYPE_PARASITE;
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
if (parasite)
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
{
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
param->data.d_parasite.name = parasite->name;
param->data.d_parasite.flags = parasite->flags;
param->data.d_parasite.size = parasite->size;
param->data.d_parasite.data = parasite->data;
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
if (full_copy)
{
parasite->name = NULL;
parasite->flags = 0;
parasite->size = 0;
parasite->data = NULL;
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
gimp_parasite_free (parasite);
}
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
}
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
else
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
{
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
param->data.d_parasite.name = NULL;
param->data.d_parasite.flags = 0;
param->data.d_parasite.size = 0;
param->data.d_parasite.data = NULL;
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
}
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
}
else if (GIMP_VALUE_HOLDS_INT32_ARRAY (value) ||
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/. Several types functions were using the wording "float" historically to mean double-precision, e.g. the float array type (which was in fact a double array). Or the scanner function gimp_scanner_parse_float() was in fact returning a double value. What if we wanted someday to actually add float (usually this naming means in C the single-precision IEEE 754 floating point representation) support? How would we name this? Now technically it's not entirely wrong (a double is still a floating point). So I've been wondering if that is because maybe we never planned to have float and double precision may be good enough for all usage in a plug-in API (which doesn't have to be as generic so the higher precision is enough)? But how can we be sure? Also we already had some functions using the wording double (e.g. gimp_procedure_add_double_argument()), so let's just go the safe route and use the accurate wording. The additional change in PDB is internal, but there too, I was also finding very confusing that we were naming double-precision float as 'float' type. So I took the opportunity to update this. It doesn't change any signature. In fact the whole commit doesn't change any type or code logic, only naming, except for one bug fix in the middle which I encountered while renaming: in gimp_scanner_parse_deprecated_color(), I discovered a hidden bug in scanning (color-hsv*) values, which was mistakenly using a double type for an array of float.
2024-11-02 21:03:37 +08:00
GIMP_VALUE_HOLDS_DOUBLE_ARRAY (value))
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
{
GimpArray *array = g_value_get_boxed (value);
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
libgimp: fix writing empty array GValues in gimp_value_to_gp_param() When g_value_get_boxed() returns a NULL array, we would encode nonsense on the wire and run into warnings. Now we simply send a zero-length array.
2020-01-06 23:16:18 +08:00
param->param_type = GP_PARAM_TYPE_ARRAY;
libgimp: deal with NULL arrays in _gimp_value_to_gp_param() How did this not crash even once before in my tests...
2019-08-14 04:52:19 +08:00
if (array)
{
param->data.d_array.size = array->length;
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
libgimp: deal with NULL arrays in _gimp_value_to_gp_param() How did this not crash even once before in my tests...
2019-08-14 04:52:19 +08:00
if (full_copy)
app, libgimp*, pdb, plug-ins: use g_memdup2() instead of g_memdup() Since it appeared with GLib 2.68.0, we could not change this until we bumped the dependency which has only become possible a few days ago (since Debian testing is our baseline for dependency bumps). Cf. previous commit. As this is a drop-in replacement (just a guint parameter changed to gsize to avoid integer overflow), search-and-replace with: > sed -i 's/g_memdup\>/g_memdup2/g' `grep -rIl 'g_memdup\>' *` … followed by a few manual alignment tweaks when necessary. This gets rid of the many deprecation warnings which we had lately when building with a recent GLib version.
2021-08-26 23:18:32 +08:00
param->data.d_array.data = g_memdup2 (array->data,
array->length);
libgimp: deal with NULL arrays in _gimp_value_to_gp_param() How did this not crash even once before in my tests...
2019-08-14 04:52:19 +08:00
else
param->data.d_array.data = array->data;
}
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
else
libgimp: deal with NULL arrays in _gimp_value_to_gp_param() How did this not crash even once before in my tests...
2019-08-14 04:52:19 +08:00
{
libgimp: fix writing empty array GValues in gimp_value_to_gp_param() When g_value_get_boxed() returns a NULL array, we would encode nonsense on the wire and run into warnings. Now we simply send a zero-length array.
2020-01-06 23:16:18 +08:00
param->data.d_array.size = 0;
libgimp: deal with NULL arrays in _gimp_value_to_gp_param() How did this not crash even once before in my tests...
2019-08-14 04:52:19 +08:00
param->data.d_array.data = NULL;
}
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
}
app, libgimp, libgimpbase, pdb: GimpColorArray as a typedef to… … NULL-terminated array of GeglColor is now a boxed type usable in PDB.
2023-12-27 00:07:19 +08:00
else if (GIMP_VALUE_HOLDS_COLOR_ARRAY (value))
{
GeglColor **colors = g_value_get_boxed (value);
param->param_type = GP_PARAM_TYPE_COLOR_ARRAY;
if (colors != NULL)
{
param->data.d_color_array.size = gimp_color_array_get_length (colors);
param->data.d_color_array.colors = g_new0 (GPParamColor,
param->data.d_color_array.size);
for (gint i = 0; i < param->data.d_color_array.size; i++)
{
const Babl *format;
int icc_length = 0;
format = gegl_color_get_format (colors[i]);
param->data.d_color_array.colors[i].size = babl_format_get_bytes_per_pixel (format);
gegl_color_get_pixel (colors[i], format, &param->data.d_color_array.colors[i].data);
app, libgimp*, pdb: new "format" type in the PDB. We have a bunch of special-casing format passing through the PDB, but either we were only passing the encoding, or else we were reconstructing the full format through private intermediate functions. In the space-invasion world, this is not right. Let's have a proper "format" type for PDB which does all the relevant data-passing for us, once and for all! Note that I am creating a wrapper boxed type GimpBablFormat whose only goal is to have recognizable GValue since Babl types don't have GType-s. Moreover I'm not using the GeglParamSpecFormat either, because it just uses pointers which again are a bit annoying in our various PDB code. Having a simple boxed arg is better.
2024-09-21 03:55:21 +08:00
param->data.d_color_array.colors[i].format.encoding = (gchar *) babl_format_get_encoding (format);
app, libgimp, libgimpbase, pdb: GimpColorArray as a typedef to… … NULL-terminated array of GeglColor is now a boxed type usable in PDB.
2023-12-27 00:07:19 +08:00
if (babl_format_get_space (format) != babl_space ("sRGB"))
app, libgimp*, pdb: new "format" type in the PDB. We have a bunch of special-casing format passing through the PDB, but either we were only passing the encoding, or else we were reconstructing the full format through private intermediate functions. In the space-invasion world, this is not right. Let's have a proper "format" type for PDB which does all the relevant data-passing for us, once and for all! Note that I am creating a wrapper boxed type GimpBablFormat whose only goal is to have recognizable GValue since Babl types don't have GType-s. Moreover I'm not using the GeglParamSpecFormat either, because it just uses pointers which again are a bit annoying in our various PDB code. Having a simple boxed arg is better.
2024-09-21 03:55:21 +08:00
param->data.d_color_array.colors[i].format.profile_data = (guint8 *) babl_space_get_icc (babl_format_get_space (format),
&icc_length);
param->data.d_gegl_color.format.profile_size = icc_length;
app, libgimp, libgimpbase, pdb: GimpColorArray as a typedef to… … NULL-terminated array of GeglColor is now a boxed type usable in PDB.
2023-12-27 00:07:19 +08:00
}
}
else
{
param->data.d_color_array.size = 0;
param->data.d_color_array.colors = NULL;
}
}
Remove GimpUint8Array in favor of GBytes GLib has a specific type for byte arrays: `GBytes` (and it's underlying GType `G_TYPE_BYTES`). By using this type, we can avoid having a `GimpUint8Array` which is a bit cumbersome to use for both the C API, as well as bindings. By using `GBytes`, we allow other languages to pass on byte arrays as they are used to, while the bindings will make sure to do the right thing. In the end, it makes the API a little bit simpler for everyone, and reduces confusion for people who are used to working with byte arrays in other C/GLib based code (and not having 2 different types to denote the same thing). Related: https://gitlab.gnome.org/GNOME/gimp/-/issues/5919
2023-05-24 05:37:46 +08:00
else if (G_VALUE_HOLDS (value, G_TYPE_BYTES))
{
GBytes *bytes = g_value_get_boxed (value);
param->param_type = GP_PARAM_TYPE_BYTES;
if (bytes != NULL)
{
if (full_copy)
param->data.d_bytes = g_bytes_new (g_bytes_get_data (bytes, NULL),
g_bytes_get_size (bytes));
else
param->data.d_bytes = g_bytes_new_static (g_bytes_get_data (bytes, NULL),
g_bytes_get_size (bytes));
}
}
Remove GimpStringArray in favor of GStrv GLib has a specific type of NULL-terminated string arrays: `G_TYPE_STRV`, which is the `GType` of `char**` aka `GStrv`. By using this type, we can avoid having a `GimpStringArray` which is a bit cumbersome to use for both the C API, as well as bindings. By using `GStrv`, we allow other languages to pass on string lists as they are used to, while the bindings will make sure to do the right thing. In the end, it makes the API a little bit simpler for everyone, and reduces confusion for people who are used to working with string arrays in other C/GLib based code (and not having 2 different types to denote the same thing). Related: https://gitlab.gnome.org/GNOME/gimp/-/issues/5919
2020-12-24 04:15:43 +08:00
else if (G_VALUE_HOLDS (value, G_TYPE_STRV))
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
{
libgimp: minor nitpick fixes. - Use GLib types even if it's the same thing here. - Remove one redundant test (`*sp` is already tested by the for() loop).
2022-05-25 05:52:15 +08:00
gchar **array = g_value_get_boxed (value);
libgimp: fix writing empty array GValues in gimp_value_to_gp_param() When g_value_get_boxed() returns a NULL array, we would encode nonsense on the wire and run into warnings. Now we simply send a zero-length array.
2020-01-06 23:16:18 +08:00
Remove GimpStringArray in favor of GStrv GLib has a specific type of NULL-terminated string arrays: `G_TYPE_STRV`, which is the `GType` of `char**` aka `GStrv`. By using this type, we can avoid having a `GimpStringArray` which is a bit cumbersome to use for both the C API, as well as bindings. By using `GStrv`, we allow other languages to pass on string lists as they are used to, while the bindings will make sure to do the right thing. In the end, it makes the API a little bit simpler for everyone, and reduces confusion for people who are used to working with string arrays in other C/GLib based code (and not having 2 different types to denote the same thing). Related: https://gitlab.gnome.org/GNOME/gimp/-/issues/5919
2020-12-24 04:15:43 +08:00
param->param_type = GP_PARAM_TYPE_STRV;
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
Remove GimpStringArray in favor of GStrv GLib has a specific type of NULL-terminated string arrays: `G_TYPE_STRV`, which is the `GType` of `char**` aka `GStrv`. By using this type, we can avoid having a `GimpStringArray` which is a bit cumbersome to use for both the C API, as well as bindings. By using `GStrv`, we allow other languages to pass on string lists as they are used to, while the bindings will make sure to do the right thing. In the end, it makes the API a little bit simpler for everyone, and reduces confusion for people who are used to working with string arrays in other C/GLib based code (and not having 2 different types to denote the same thing). Related: https://gitlab.gnome.org/GNOME/gimp/-/issues/5919
2020-12-24 04:15:43 +08:00
if (full_copy)
param->data.d_strv = g_strdupv (array);
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
else
Remove GimpStringArray in favor of GStrv GLib has a specific type of NULL-terminated string arrays: `G_TYPE_STRV`, which is the `GType` of `char**` aka `GStrv`. By using this type, we can avoid having a `GimpStringArray` which is a bit cumbersome to use for both the C API, as well as bindings. By using `GStrv`, we allow other languages to pass on string lists as they are used to, while the bindings will make sure to do the right thing. In the end, it makes the API a little bit simpler for everyone, and reduces confusion for people who are used to working with string arrays in other C/GLib based code (and not having 2 different types to denote the same thing). Related: https://gitlab.gnome.org/GNOME/gimp/-/issues/5919
2020-12-24 04:15:43 +08:00
param->data.d_strv = array;
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
}
app, libgimp, pdb, plug-ins: new GimpCoreObjectArray type and drawablearray… … PDB type. This is a first step for #7369. Clearly our GimpObjectArray was meant to be used with C arrays, hence the wrapper function gimp_value_set_object_array() which was taking a C array and actually creating and setting a GimpObjectArray. This is why our new type is actually a C array aliased as a boxed type and containing its own size (thanks to NULL-termination). Eventually GimpCoreObjectArray is meant to replace GimpObjectArray. The only issue is that such a type does not allow NULL as a valid element in such an array, but fact is that I don't think we currently have any use case where this matters. If ever such a case arise in the future, we may introduce back GimpObjectArray. In this first commit, I replaced all itemarray PDB types with a new drawablearray using this new boxed type when relevant.
2024-10-22 03:59:26 +08:00
else if (GIMP_VALUE_HOLDS_CORE_OBJECT_ARRAY (value))
{
GObject **array = g_value_get_boxed (value);
param->param_type = GP_PARAM_TYPE_ID_ARRAY;
param->data.d_id_array.type_name = NULL;
if (array && array[0])
{
GType element_type = G_TYPE_NONE;
gsize array_length;
gint i;
for (i = 0; array[i] != NULL; i++)
{
if (element_type != G_TYPE_NONE)
{
if (! g_type_is_a (G_TYPE_FROM_INSTANCE (array[i]), element_type))
{
g_warning ("%s: GimpCoreObjectArray with element type %s holds unsupported element of type '%s'", G_STRFUNC,
g_type_name (element_type), g_type_name (G_TYPE_FROM_INSTANCE (array[i])));
break;
}
continue;
}
if (GIMP_IS_IMAGE (array[i]))
{
element_type = GIMP_TYPE_IMAGE;
}
else if (GIMP_IS_ITEM (array[i]))
{
element_type = GIMP_TYPE_ITEM;
}
else if (GIMP_IS_DISPLAY (array[i]))
{
element_type = GIMP_TYPE_DISPLAY;
}
else if (GIMP_IS_RESOURCE (array[i]))
{
element_type = GIMP_TYPE_RESOURCE;
}
else
{
g_warning ("%s: GimpCoreObjectArray holds unsupported type '%s'", G_STRFUNC,
g_type_name (G_TYPE_FROM_INSTANCE (array[i])));
break;
}
}
array_length = i;
param->data.d_id_array.size = array_length;
if (array_length > 0)
{
if (full_copy)
param->data.d_id_array.type_name = g_strdup (g_type_name (element_type));
else
param->data.d_id_array.type_name = (gchar *) g_type_name (element_type);
/* must be free'd also for full_copy == FALSE */
param->data.d_id_array.data = g_new (gint32, array_length);
}
for (i = 0; i < array_length; i++)
{
if (GIMP_IS_IMAGE (array[i]))
{
param->data.d_id_array.data[i] =
gimp_image_get_id (GIMP_IMAGE (array[i]));
}
else if (GIMP_IS_ITEM (array[i]))
{
param->data.d_id_array.data[i] =
gimp_item_get_id (GIMP_ITEM (array[i]));
}
else if (GIMP_IS_DISPLAY (array[i]))
{
param->data.d_id_array.data[i] =
gimp_display_get_id (GIMP_DISPLAY (array[i]));
}
else if (GIMP_IS_RESOURCE (array[i]))
{
param->data.d_id_array.data[i] = get_resource_id (array[i]);
}
else
{
param->data.d_id_array.data[i] = -1;
}
}
}
else
{
/* GValue intended to hold an array of objects is NULL.
* For convenience, we allow this, meaning empty.
*/
param->data.d_id_array.size = 0;
param->data.d_id_array.data = NULL;
}
}
app, libgimp: get rid of all ID GTypes and ID param specs 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/.
2019-08-29 17:25:35 +08:00
else if (GIMP_VALUE_HOLDS_IMAGE (value))
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
{
app, libgimp: get rid of all ID GTypes and ID param specs 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/.
2019-08-29 17:25:35 +08:00
GimpImage *image = g_value_get_object (value);
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
param->param_type = GP_PARAM_TYPE_INT;
app, libgimp: get rid of all ID GTypes and ID param specs 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/.
2019-08-29 17:25:35 +08:00
param->data.d_int = image ? gimp_image_get_id (image) : -1;
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
}
app, libgimp: get rid of all ID GTypes and ID param specs 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/.
2019-08-29 17:25:35 +08:00
else if (GIMP_VALUE_HOLDS_ITEM (value))
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
{
app, libgimp: get rid of all ID GTypes and ID param specs 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/.
2019-08-29 17:25:35 +08:00
GimpItem *item = g_value_get_object (value);
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
app, libgimp: get rid of all ID GTypes and ID param specs 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/.
2019-08-29 17:25:35 +08:00
param->param_type = GP_PARAM_TYPE_INT;
param->data.d_int = item ? gimp_item_get_id (item) : -1;
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
}
app, libgimp: get rid of all ID GTypes and ID param specs 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/.
2019-08-29 17:25:35 +08:00
else if (GIMP_VALUE_HOLDS_DISPLAY (value))
libgimp: support all GimpItem subclasses as argument and return values.
2019-08-14 20:56:28 +08:00
{
app: split GimpDisplay in two classes: GimpDisplay and GimpDisplayImpl 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.
2019-09-04 20:27:18 +08:00
GimpDisplay *display = g_value_get_object (value);
libgimp: make gimpgpparams-body.c identical for app/ and libgimp/ again 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.
2019-08-24 05:31:19 +08:00
app, libgimp: get rid of all ID GTypes and ID param specs 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/.
2019-08-29 17:25:35 +08:00
param->param_type = GP_PARAM_TYPE_INT;
libgimp: make gimpgpparams-body.c identical for app/ and libgimp/ again 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.
2019-08-24 05:31:19 +08:00
app: split GimpDisplay in two classes: GimpDisplay and GimpDisplayImpl 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.
2019-09-04 20:27:18 +08:00
param->data.d_int = display ? gimp_display_get_id (display) : -1;
app, libgimp: get rid of all ID GTypes and ID param specs 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/.
2019-08-29 17:25:35 +08:00
}
2.99 libgimp: add GimpResource, GimpBrush, GimpPropWidgetBrush So procedures can declare args and GimpProcedureDialog show chooser widgets Fix so is no error dialog on id_is_valid for resources Palette.pdb changes and testing Memory mgt changes Gradient pdb Font and Pattern tests Test brush, palette Cleanup, remove generator Rebase, edit docs, install test-dialog.py Whitespace, and fix failed distcheck Fix some clang-format, fix fail distcheck Fix distcheck Cleanup from review Jehan
2022-09-06 07:28:35 +08:00
else if (GIMP_VALUE_HOLDS_RESOURCE (value))
{
GObject *resource = g_value_get_object (value);
Introduce a global ID space for GimpData/GimpResource objects Much like for images and items. Change the PDB to transmit IDs instead of names for brush, pattern etc. and refactor a whole lot of libgimp code to deal with it. modified: libgimp/gimpplugin-private.h
2023-05-31 22:12:04 +08:00
param->param_type = GP_PARAM_TYPE_INT;
libgimp: fix getting invalid resource the first call with a NULL arg. When the core sends a NULL resource, which would be the default for object args, hence is also what you get for the first call of a plug-in with a resource parameter, libgimp was creating a GimpResource with NULL id, which is invalid. It is much better to return NULL (since we made it so that NULL is a valid value) and let the plug-in handle the NULL value as it sees fit for a given parameter (they could just set the contextual resource for this type, or keep NULL to mean "no resource selected"). This fixes failing to run plug-ins the first time (before any "last" values are set). E.g. I had the issue when testing palette-sort. Also I'm improving the error message when trying to use a non-installed resource (it will now also print the resource ID and the error message). And the GError was leaking in this case, so I properly free it now.
2023-01-15 02:06:03 +08:00
Introduce a global ID space for GimpData/GimpResource objects Much like for images and items. Change the PDB to transmit IDs instead of names for brush, pattern etc. and refactor a whole lot of libgimp code to deal with it. modified: libgimp/gimpplugin-private.h
2023-05-31 22:12:04 +08:00
param->data.d_int = resource ? get_resource_id (resource) : -1;
2.99 libgimp: add GimpResource, GimpBrush, GimpPropWidgetBrush So procedures can declare args and GimpProcedureDialog show chooser widgets Fix so is no error dialog on id_is_valid for resources Palette.pdb changes and testing Memory mgt changes Gradient pdb Font and Pattern tests Test brush, palette Cleanup, remove generator Rebase, edit docs, install test-dialog.py Whitespace, and fix failed distcheck Fix some clang-format, fix fail distcheck Fix distcheck Cleanup from review Jehan
2022-09-06 07:28:35 +08:00
}
Issue #8900 and #9923: reimplementing GimpUnit as a proper class. This fixes all our GObject Introspection issues with GimpUnit which was both an enum and an int-derived type of user-defined units *completing* the enum values. GIR clearly didn't like this! Now GimpUnit is a proper class and units are unique objects, allowing to compare them with an identity test (i.e. `unit == gimp_unit_pixel ()` tells us if unit is the pixel unit or not), which makes it easy to use, just like with int, yet adding also methods, making for nicer introspected API. As an aside, this also fixes #10738, by having all the built-in units retrievable even if libgimpbase had not been properly initialized with gimp_base_init(). I haven't checked in details how GIR works to introspect, but it looks like it loads the library to inspect and runs functions, hence triggering some CRITICALS because virtual methods (supposed to be initialized with gimp_base_init() run by libgimp) are not set. This new code won't trigger any critical because the vtable method are now not necessary, at least for all built-in units. Note that GimpUnit is still in libgimpbase. It could have been moved to libgimp in order to avoid any virtual method table (since we need to keep core and libgimp side's units in sync, PDB is required), but too many libgimpwidgets widgets were already using GimpUnit. And technically most of GimpUnit logic doesn't require PDB (only the creation/sync part). This is one of the reasons why user-created GimpUnit list is handled and stored differently from other types of objects. Globally this simplifies the code a lot too and we don't need separate implementations of various utils for core and libgimp, which means less prone to errors.
2024-07-26 02:55:21 +08:00
else if (GIMP_VALUE_HOLDS_UNIT (value))
{
GimpUnit *unit = g_value_get_object (value);
param->param_type = GP_PARAM_TYPE_INT;
param->data.d_int = unit ? gimp_unit_get_id (unit) : -1;
}
core, pdb, plug-ins: Create GimpExportOptions class This patch creates a GimpExportOptions class in both libgimpbase and in libgimp. Currently it is a mostly empty object, but it will be added to after 3.0 to allow for additional export options (like resizing on export while leaving the original image intact) libgimp/gimpexport.c was removed, and most of its content was copied into libgimp/gimpexportoptions.c. gimp_export_image () was replaced with gimp_export_options_get_image () in all export plug-ins. GimpExportProcedure has a new function to set the default image capabilities for each plug-in on creation. It also sets up a new callback function, which allows the options to respond to user setting changes (such as toggling 'Save as Animation' in the GIF or WEBP Plug-in).
2024-05-07 02:38:12 +08:00
else if (g_type_is_a (G_VALUE_TYPE (value), GIMP_TYPE_EXPORT_OPTIONS))
{
app, libgimp*, pdb, plug-ins: capabilities should not be part of GimpParamSpecExportOptions. The param option just contains an options object, not a separate capabilities. Also even when passing the options object across the wire, the capabilities within this object are not part of the "options". These are actually handled separated by GimpExportProcedure. Therefore the changes are: * GimpExportCapabilities moved to gimpbaseenums.h with a proper GType. * "capabilities" properties are changed to flags param spec with type GimpExportCapabilities. * GimpParamSpecExportOptions doesn't have a capabilities variable anymore. * Consequently gimp_param_spec_export_options() doesn't have a capabilities arg. * Wire protocol updated as we don't need to pass any capabilities neither for the param definition, nor for the argument values. * GimpExportOptionsEditFunc renamed GimpExportGetCapabilitiesFunc and returning GimpExportCapabilities flags, instead of setting the "capabilities" property. I believe it makes it much more obvious what this callback is for and how to use it. * Annotations improved or completed. * Don't make the GimpParamSpecExportOptions public anymore since it is the same as its parent.
2024-11-02 02:13:02 +08:00
param->param_type = GP_PARAM_TYPE_EXPORT_OPTIONS;
core, pdb, plug-ins: Create GimpExportOptions class This patch creates a GimpExportOptions class in both libgimpbase and in libgimp. Currently it is a mostly empty object, but it will be added to after 3.0 to allow for additional export options (like resizing on export while leaving the original image intact) libgimp/gimpexport.c was removed, and most of its content was copied into libgimp/gimpexportoptions.c. gimp_export_image () was replaced with gimp_export_options_get_image () in all export plug-ins. GimpExportProcedure has a new function to set the default image capabilities for each plug-in on creation. It also sets up a new callback function, which allows the options to respond to user setting changes (such as toggling 'Save as Animation' in the GIF or WEBP Plug-in).
2024-05-07 02:38:12 +08:00
}
app, libgimp: get rid of all ID GTypes and ID param specs 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/.
2019-08-29 17:25:35 +08:00
else if (G_VALUE_HOLDS_PARAM (value))
{
param->param_type = GP_PARAM_TYPE_PARAM_DEF;
libgimp: make gimpgpparams-body.c identical for app/ and libgimp/ again 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.
2019-08-24 05:31:19 +08:00
app, libgimp: get rid of all ID GTypes and ID param specs 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/.
2019-08-29 17:25:35 +08:00
_gimp_param_spec_to_gp_param_def (g_value_get_param (value),
&param->data.d_param_def);
libgimp: support all GimpItem subclasses as argument and return values.
2019-08-14 20:56:28 +08:00
}
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
if (param->param_type == -1)
2.99 libgimp: add GimpResource, GimpBrush, GimpPropWidgetBrush So procedures can declare args and GimpProcedureDialog show chooser widgets Fix so is no error dialog on id_is_valid for resources Palette.pdb changes and testing Memory mgt changes Gradient pdb Font and Pattern tests Test brush, palette Cleanup, remove generator Rebase, edit docs, install test-dialog.py Whitespace, and fix failed distcheck Fix some clang-format, fix fail distcheck Fix distcheck Cleanup from review Jehan
2022-09-06 07:28:35 +08:00
g_warning ("%s: GValue holds unsupported type '%s'", G_STRFUNC, param->type_name);
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
}
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
GPParam *
libgimp: add some const to input parameters, like const GimpValueArray* for procedure arguments. This implies creating a new value array in gimp_procedure_run() if the passed array is too short, instead of just appending to the passed array, which was ugly anyway.
2019-08-07 06:02:29 +08:00
_gimp_value_array_to_gp_params (const GimpValueArray *args,
gboolean full_copy)
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
{
GPParam *params;
gint length;
gint i;
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
g_return_val_if_fail (args != NULL, NULL);
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
length = gimp_value_array_length (args);
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
params = g_new0 (GPParam, length);
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
app, libgimp*: add protocol support for GValues holding a GParamSpec so we can have PDB introspection procedures for the new plug-in API.
2019-08-05 06:58:44 +08:00
for (i = 0; i < length; i++)
{
GValue *value = gimp_value_array_index (args, i);
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
app, libgimp: make two functions of gimpgpparams private and remove a "gimp" parameter that is no longer needed.
2019-09-05 22:07:15 +08:00
gimp_value_to_gp_param (value, &params[i], full_copy);
app, libgimp, libgimpbase: big plug-in API refactoring part three - 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.
2019-07-29 07:56:58 +08:00
}
return params;
}
app, libgimp: add _gimp_gp_params_free() to gimpgpparams 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.
2019-09-06 02:59:57 +08:00
void
_gimp_gp_params_free (GPParam *params,
gint n_params,
gboolean full_copy)
{
gint i;
for (i = 0; i < n_params; i++)
{
if (full_copy)
g_free (params[i].type_name);
switch (params[i].param_type)
{
case GP_PARAM_TYPE_INT:
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/. Several types functions were using the wording "float" historically to mean double-precision, e.g. the float array type (which was in fact a double array). Or the scanner function gimp_scanner_parse_float() was in fact returning a double value. What if we wanted someday to actually add float (usually this naming means in C the single-precision IEEE 754 floating point representation) support? How would we name this? Now technically it's not entirely wrong (a double is still a floating point). So I've been wondering if that is because maybe we never planned to have float and double precision may be good enough for all usage in a plug-in API (which doesn't have to be as generic so the higher precision is enough)? But how can we be sure? Also we already had some functions using the wording double (e.g. gimp_procedure_add_double_argument()), so let's just go the safe route and use the accurate wording. The additional change in PDB is internal, but there too, I was also finding very confusing that we were naming double-precision float as 'float' type. So I took the opportunity to update this. It doesn't change any signature. In fact the whole commit doesn't change any type or code logic, only naming, except for one bug fix in the middle which I encountered while renaming: in gimp_scanner_parse_deprecated_color(), I discovered a hidden bug in scanning (color-hsv*) values, which was mistakenly using a double type for an array of float.
2024-11-02 21:03:37 +08:00
case GP_PARAM_TYPE_DOUBLE:
app, libgimp: add _gimp_gp_params_free() to gimpgpparams 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.
2019-09-06 02:59:57 +08:00
break;
case GP_PARAM_TYPE_STRING:
if (full_copy)
g_free (params[i].data.d_string);
break;
libgimpbase, libgimp, app: add libgimp support for passing GFiles 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.
2019-09-12 03:40:17 +08:00
case GP_PARAM_TYPE_FILE:
/* always free the uri */
g_free (params[i].data.d_string);
break;
app, libgimp*, pdb: new "format" type in the PDB. We have a bunch of special-casing format passing through the PDB, but either we were only passing the encoding, or else we were reconstructing the full format through private intermediate functions. In the space-invasion world, this is not right. Let's have a proper "format" type for PDB which does all the relevant data-passing for us, once and for all! Note that I am creating a wrapper boxed type GimpBablFormat whose only goal is to have recognizable GValue since Babl types don't have GType-s. Moreover I'm not using the GeglParamSpecFormat either, because it just uses pointers which again are a bit annoying in our various PDB code. Having a simple boxed arg is better.
2024-09-21 03:55:21 +08:00
case GP_PARAM_TYPE_BABL_FORMAT:
libgimp*, pdb: support of GeglColor in the PDB. Eventually this is meant to fully replace GimpRGB (as well as GimpHSV, GimpHSL and GimpCMYK), both in libgimp and in core code, as part of both the space invasion and the API rework. For this first commit, I keep this new object side by side to GimpRGB.
2023-11-04 04:26:51 +08:00
case GP_PARAM_TYPE_GEGL_COLOR:
break;
app, libgimp, libgimpbase, pdb: GimpColorArray as a typedef to… … NULL-terminated array of GeglColor is now a boxed type usable in PDB.
2023-12-27 00:07:19 +08:00
case GP_PARAM_TYPE_COLOR_ARRAY:
g_free (params[i].data.d_color_array.colors);
break;
app, libgimp: add _gimp_gp_params_free() to gimpgpparams 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.
2019-09-06 02:59:57 +08:00
case GP_PARAM_TYPE_ARRAY:
if (full_copy)
g_free (params[i].data.d_array.data);
break;
Remove GimpStringArray in favor of GStrv GLib has a specific type of NULL-terminated string arrays: `G_TYPE_STRV`, which is the `GType` of `char**` aka `GStrv`. By using this type, we can avoid having a `GimpStringArray` which is a bit cumbersome to use for both the C API, as well as bindings. By using `GStrv`, we allow other languages to pass on string lists as they are used to, while the bindings will make sure to do the right thing. In the end, it makes the API a little bit simpler for everyone, and reduces confusion for people who are used to working with string arrays in other C/GLib based code (and not having 2 different types to denote the same thing). Related: https://gitlab.gnome.org/GNOME/gimp/-/issues/5919
2020-12-24 04:15:43 +08:00
case GP_PARAM_TYPE_STRV:
if (full_copy)
g_strfreev (params[i].data.d_strv);
app, libgimp: add _gimp_gp_params_free() to gimpgpparams 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.
2019-09-06 02:59:57 +08:00
break;
Remove GimpUint8Array in favor of GBytes GLib has a specific type for byte arrays: `GBytes` (and it's underlying GType `G_TYPE_BYTES`). By using this type, we can avoid having a `GimpUint8Array` which is a bit cumbersome to use for both the C API, as well as bindings. By using `GBytes`, we allow other languages to pass on byte arrays as they are used to, while the bindings will make sure to do the right thing. In the end, it makes the API a little bit simpler for everyone, and reduces confusion for people who are used to working with byte arrays in other C/GLib based code (and not having 2 different types to denote the same thing). Related: https://gitlab.gnome.org/GNOME/gimp/-/issues/5919
2023-05-24 05:37:46 +08:00
case GP_PARAM_TYPE_BYTES:
g_bytes_unref (params[i].data.d_bytes);
break;
app, libgimp: add _gimp_gp_params_free() to gimpgpparams 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.
2019-09-06 02:59:57 +08:00
case GP_PARAM_TYPE_ID_ARRAY:
if (full_copy)
g_free (params[i].data.d_id_array.type_name);
/* always free the array */
g_free (params[i].data.d_id_array.data);
break;
case GP_PARAM_TYPE_PARASITE:
if (full_copy)
libgimp: fix crash introduced in commit bfe4a2f9 Freeing stuff is good, but freeing twice is not so good.
2019-09-06 23:24:33 +08:00
{
g_free (params[i].data.d_parasite.name);
g_free (params[i].data.d_parasite.data);
}
app, libgimp: add _gimp_gp_params_free() to gimpgpparams 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.
2019-09-06 02:59:57 +08:00
break;
core, pdb, plug-ins: Create GimpExportOptions class This patch creates a GimpExportOptions class in both libgimpbase and in libgimp. Currently it is a mostly empty object, but it will be added to after 3.0 to allow for additional export options (like resizing on export while leaving the original image intact) libgimp/gimpexport.c was removed, and most of its content was copied into libgimp/gimpexportoptions.c. gimp_export_image () was replaced with gimp_export_options_get_image () in all export plug-ins. GimpExportProcedure has a new function to set the default image capabilities for each plug-in on creation. It also sets up a new callback function, which allows the options to respond to user setting changes (such as toggling 'Save as Animation' in the GIF or WEBP Plug-in).
2024-05-07 02:38:12 +08:00
case GP_PARAM_TYPE_EXPORT_OPTIONS:
break;
app, libgimp: add _gimp_gp_params_free() to gimpgpparams 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.
2019-09-06 02:59:57 +08:00
case GP_PARAM_TYPE_PARAM_DEF:
break;
}
}
g_free (params);
}