procyberian/gimp
2
0
Fork 0
mirror of https://gitlab.gnome.org/GNOME/gimp.git synced 2025-07-04 09:53:25 +00:00
Code Issues 1 Projects 1 Releases Packages Wiki Activity Actions
gimp/libgimp/gimpprocedure-params.c

2890 lines
111 KiB
C
Raw Normal View History

libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
/* LIBGIMP - The GIMP Library
* Copyright (C) 1995 Spencer Kimball and Peter Mattis
*
* gimpprocedure-params.c
* Copyright (C) 2019 Michael Natterer <mitch@gimp.org>
*
* 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
* Library 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/>.
*/
#include "config.h"
#include <gegl.h>
#include "gimp.h"
#include "gimpprocedure-params.h"
#include "libgimp-intl.h"
/**
* gimp_procedure_add_boolean_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @value: the default value.
* @flags: argument flags.
*
* Add a new boolean argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_boolean_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean value,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_argument (procedure,
g_param_spec_boolean (name, nick, blurb,
value, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_boolean_aux_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @value: the default value.
* @flags: argument flags.
*
* Add a new boolean auxiliary argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_boolean_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean value,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_aux_argument (procedure,
g_param_spec_boolean (name, nick, blurb,
value, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_boolean_return_value:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @value: the default value.
* @flags: argument flags.
*
* Add a new boolean return value to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_boolean_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean value,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_return_value (procedure,
g_param_spec_boolean (name, nick, blurb,
value, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_int_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @min: the minimum value for this argument
* @max: the maximum value for this argument
* @value: the default value.
* @flags: argument flags.
*
* Add a new integer argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_int_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gint min,
gint max,
gint value,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_argument (procedure,
g_param_spec_int (name, nick, blurb,
min, max, value,
flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_int_aux_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @min: the minimum value for this argument
* @max: the maximum value for this argument
* @value: the default value.
* @flags: argument flags.
*
* Add a new integer auxiliary argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_int_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gint min,
gint max,
gint value,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_aux_argument (procedure,
g_param_spec_int (name, nick, blurb,
min, max, value,
flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_int_return_value:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @min: the minimum value for this argument
* @max: the maximum value for this argument
* @value: the default value.
* @flags: argument flags.
*
* Add a new integer return value to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_int_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gint min,
gint max,
gint value,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_return_value (procedure,
g_param_spec_int (name, nick, blurb,
min, max, value,
flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_uint_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @min: the minimum value for this argument
* @max: the maximum value for this argument
* @value: the default value.
* @flags: argument flags.
*
* Add a new unsigned integer argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_uint_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
guint min,
guint max,
guint value,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_argument (procedure,
g_param_spec_uint (name, nick, blurb,
min, max, value,
flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_uint_aux_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @min: the minimum value for this argument
* @max: the maximum value for this argument
* @value: the default value.
* @flags: argument flags.
*
* Add a new unsigned integer auxiliary argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_uint_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
guint min,
guint max,
guint value,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_aux_argument (procedure,
g_param_spec_uint (name, nick, blurb,
min, max, value,
flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_uint_return_value:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @min: the minimum value for this argument
* @max: the maximum value for this argument
* @value: the default value.
* @flags: argument flags.
*
* Add a new unsigned integer return value to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_uint_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
guint min,
guint max,
guint value,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_return_value (procedure,
g_param_spec_uint (name, nick, blurb,
min, max, value,
flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_unit_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @show_pixels: whether to allow pixels as a valid option
* @show_percent: whether to allow percent as a valid option
* @value: the default value.
* @flags: argument flags.
*
* Add a new #GimpUnit argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_unit_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean show_pixels,
gboolean show_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-25 20:55:21 +02:00
GimpUnit *value,
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_argument (procedure,
gimp_param_spec_unit (name, nick, blurb,
show_pixels, show_percent,
value, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_unit_aux_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @show_pixels: whether to allow pixels as a valid option
* @show_percent: whether to allow percent as a valid option
* @value: the default value.
* @flags: argument flags.
*
* Add a new #GimpUnit auxiliary argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_unit_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean show_pixels,
gboolean show_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-25 20:55:21 +02:00
GimpUnit *value,
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_aux_argument (procedure,
gimp_param_spec_unit (name, nick, blurb,
show_pixels, show_percent,
value, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_unit_return_value:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @show_pixels: whether to allow pixels as a valid option
* @show_percent: whether to allow percent as a valid option
* @value: the default value.
* @flags: argument flags.
*
* Add a new #GimpUnit return value to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_unit_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean show_pixels,
gboolean show_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-25 20:55:21 +02:00
GimpUnit *value,
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_return_value (procedure,
gimp_param_spec_unit (name, nick, blurb,
show_pixels, show_percent,
value, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_double_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @min: the minimum value for this argument
* @max: the maximum value for this argument
* @value: the default value.
* @flags: argument 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 14:03:37 +01:00
* Add a new floating-point in double precision argument to @procedure.
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
*
* Since: 3.0
**/
void
gimp_procedure_add_double_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gdouble min,
gdouble max,
gdouble value,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_argument (procedure,
g_param_spec_double (name, nick, blurb,
min, max, value,
flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_double_aux_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @min: the minimum value for this argument
* @max: the maximum value for this argument
* @value: the default value.
* @flags: argument 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 14:03:37 +01:00
* Add a new floating-point in double precision auxiliary argument to @procedure.
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
*
* Since: 3.0
**/
void
gimp_procedure_add_double_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gdouble min,
gdouble max,
gdouble value,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_aux_argument (procedure,
g_param_spec_double (name, nick, blurb,
min, max, value,
flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_double_return_value:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @min: the minimum value for this argument
* @max: the maximum value for this argument
* @value: the default value.
* @flags: argument 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 14:03:37 +01:00
* Add a new floating-point in double precision return value to @procedure.
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
*
* Since: 3.0
**/
void
gimp_procedure_add_double_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gdouble min,
gdouble max,
gdouble value,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_return_value (procedure,
g_param_spec_double (name, nick, blurb,
min, max, value,
flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_enum_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @enum_type: the #GType for this argument
* @value: the default value.
* @flags: argument flags.
*
* Add a new enum argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_enum_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GType enum_type,
gint value,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_argument (procedure,
g_param_spec_enum (name, nick, blurb,
enum_type, value,
flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_enum_aux_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @enum_type: the #GType for this argument
* @value: the default value.
* @flags: argument flags.
*
* Add a new enum auxiliary argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_enum_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GType enum_type,
gint value,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_aux_argument (procedure,
g_param_spec_enum (name, nick, blurb,
enum_type, value,
flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_enum_return_value:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @enum_type: the #GType for this argument
* @value: the default value.
* @flags: argument flags.
*
* Add a new enum return value to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_enum_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GType enum_type,
gint value,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_return_value (procedure,
g_param_spec_enum (name, nick, blurb,
enum_type, value,
flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_choice_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @choice: (transfer full): the #GimpChoice
* @value: the default value for #GimpChoice.
* @flags: argument flags.
*
* Add a new #GimpChoice argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_choice_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GimpChoice *choice,
const gchar *value,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_argument (procedure,
gimp_param_spec_choice (name, nick, blurb,
choice, value, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_choice_aux_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @choice: the #GimpChoice
* @value: the default value for #GimpChoice.
* @flags: argument flags.
*
* Add a new #GimpChoice auxiliary argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_choice_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GimpChoice *choice,
const gchar *value,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_aux_argument (procedure,
gimp_param_spec_choice (name, nick, blurb,
choice, value, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_choice_return_value:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @choice: the #GimpChoice
* @value: the default value for #GimpChoice.
* @flags: argument flags.
*
* Add a new #GimpChoice return value to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_choice_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GimpChoice *choice,
const gchar *value,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_return_value (procedure,
gimp_param_spec_choice (name, nick, blurb,
choice, value, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_string_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @value: the default value.
* @flags: argument flags.
*
* Add a new string argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_string_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
const gchar *value,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_argument (procedure,
g_param_spec_string (name, nick, blurb,
value, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_string_aux_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @value: the default value.
* @flags: argument flags.
*
* Add a new string auxiliary argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_string_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
const gchar *value,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_aux_argument (procedure,
g_param_spec_string (name, nick, blurb,
value, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_string_return_value:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @value: the default value.
* @flags: argument flags.
*
* Add a new string return value to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_string_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
const gchar *value,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_return_value (procedure,
g_param_spec_string (name, nick, blurb,
value, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_color_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @has_alpha: whether the argument has transparency.
* @value: the default #GeglColor value.
* @flags: argument flags.
*
* Add a new #GeglColor argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_color_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean has_alpha,
GeglColor *value,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_argument (procedure,
gimp_param_spec_color (name, nick, blurb,
has_alpha, value, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_color_aux_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @has_alpha: whether the argument has transparency.
* @value: the default #GeglColor value.
* @flags: argument flags.
*
* Add a new #GeglColor auxiliary argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_color_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean has_alpha,
GeglColor *value,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_aux_argument (procedure,
gimp_param_spec_color (name, nick, blurb,
has_alpha, value, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_color_return_value:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @has_alpha: whether the argument has transparency.
* @value: the default #GeglColor value.
* @flags: argument flags.
*
* Add a new #GeglColor return value to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_color_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean has_alpha,
GeglColor *value,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_return_value (procedure,
gimp_param_spec_color (name, nick, blurb,
has_alpha, value, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_color_from_string_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @has_alpha: whether the argument has transparency.
* @value: the default #GeglColor value.
* @flags: argument flags.
*
* Add a new #GeglColor argument to @procedure from a string representation.
*
* Since: 3.0
**/
void
gimp_procedure_add_color_from_string_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean has_alpha,
const gchar *value,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_argument (procedure,
gimp_param_spec_color_from_string (name, nick, blurb,
has_alpha, value,
flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_color_from_string_aux_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @has_alpha: whether the argument has transparency.
* @value: the default #GeglColor value.
* @flags: argument flags.
*
* Add a new #GeglColor auxiliary argument to @procedure from a string representation.
*
* Since: 3.0
**/
void
gimp_procedure_add_color_from_string_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean has_alpha,
const gchar *value,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_aux_argument (procedure,
gimp_param_spec_color_from_string (name, nick, blurb,
has_alpha, value,
flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_color_from_string_return_value:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @has_alpha: whether the argument has transparency.
* @value: the default #GeglColor value.
* @flags: argument flags.
*
* Add a new #GeglColor return value to @procedure from a string representation.
*
* Since: 3.0
**/
void
gimp_procedure_add_color_from_string_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean has_alpha,
const gchar *value,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_return_value (procedure,
gimp_param_spec_color_from_string (name, nick, blurb,
has_alpha, value,
flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_parasite_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @flags: argument flags.
*
* Add a new #GimpParasite argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_parasite_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_argument (procedure,
gimp_param_spec_parasite (name, nick, blurb,
flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_parasite_aux_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @flags: argument flags.
*
* Add a new #GimpParasite auxiliary argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_parasite_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_aux_argument (procedure,
gimp_param_spec_parasite (name, nick, blurb,
flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_parasite_return_value:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @flags: argument flags.
*
* Add a new #GimpParasite return value to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_parasite_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_return_value (procedure,
gimp_param_spec_parasite (name, nick, blurb,
flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_param_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @param_type: the #GPParamType for this argument
* @flags: argument flags.
*
* Add a new param argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_param_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GType param_type,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_argument (procedure,
g_param_spec_param (name, nick, blurb,
param_type, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_param_aux_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @param_type: the #GPParamType for this argument
* @flags: argument flags.
*
* Add a new param auxiliary argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_param_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GType param_type,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_aux_argument (procedure,
g_param_spec_param (name, nick, blurb,
param_type, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_param_return_value:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @param_type: the #GPParamType for this argument
* @flags: argument flags.
*
* Add a new param return value to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_param_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GType param_type,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_return_value (procedure,
g_param_spec_param (name, nick, blurb,
param_type, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_bytes_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @flags: argument flags.
*
* Add a new #GBytes argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_bytes_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_argument (procedure,
g_param_spec_boxed (name, nick, blurb,
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
G_TYPE_BYTES, flags));
}
/**
* gimp_procedure_add_bytes_aux_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @flags: argument flags.
*
* Add a new #GBytes auxiliary argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_bytes_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_aux_argument (procedure,
g_param_spec_boxed (name, nick, blurb,
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
G_TYPE_BYTES, flags));
}
/**
* gimp_procedure_add_bytes_return_value:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @flags: argument flags.
*
* Add a new #GBytes return value to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_bytes_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_return_value (procedure,
g_param_spec_boxed (name, nick, blurb,
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
G_TYPE_BYTES, flags));
}
/**
* gimp_procedure_add_int32_array_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @flags: argument flags.
*
* Add a new integer array argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_int32_array_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_argument (procedure,
gimp_param_spec_int32_array (name, nick, blurb,
flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_int32_array_aux_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @flags: argument flags.
*
* Add a new integer array auxiliary argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_int32_array_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_aux_argument (procedure,
gimp_param_spec_int32_array (name, nick, blurb,
flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_int32_array_return_value:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @flags: argument flags.
*
* Add a new integer array return value to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_int32_array_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_return_value (procedure,
gimp_param_spec_int32_array (name, nick, blurb,
flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00: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 14:03:37 +01:00
* gimp_procedure_add_double_array_argument:
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @flags: argument 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 14:03:37 +01:00
* Add a new double array argument to @procedure.
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
*
* Since: 3.0
**/
void
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 14:03:37 +01:00
gimp_procedure_add_double_array_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GParamFlags flags)
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_argument (procedure,
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 14:03:37 +01:00
gimp_param_spec_double_array (name, nick, blurb,
flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00: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 14:03:37 +01:00
* gimp_procedure_add_double_array_aux_argument:
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @flags: argument 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 14:03:37 +01:00
* Add a new double array auxiliary argument to @procedure.
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
*
* Since: 3.0
**/
void
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 14:03:37 +01:00
gimp_procedure_add_double_array_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GParamFlags flags)
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_aux_argument (procedure,
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 14:03:37 +01:00
gimp_param_spec_double_array (name, nick, blurb,
flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00: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 14:03:37 +01:00
* gimp_procedure_add_double_array_return_value:
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @flags: argument 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 14:03:37 +01:00
* Add a new double array return value to @procedure.
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
*
* Since: 3.0
**/
void
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 14:03:37 +01:00
gimp_procedure_add_double_array_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GParamFlags flags)
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_return_value (procedure,
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 14:03:37 +01:00
gimp_param_spec_double_array (name, nick, blurb,
flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_string_array_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @flags: argument flags.
*
* Add a new string array argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_string_array_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_argument (procedure,
g_param_spec_boxed (name, nick, blurb,
G_TYPE_STRV, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_string_array_aux_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @flags: argument flags.
*
* Add a new string array auxiliary argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_string_array_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_aux_argument (procedure,
g_param_spec_boxed (name, nick, blurb,
G_TYPE_STRV, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_string_array_return_value:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @flags: argument flags.
*
* Add a new string array return value to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_string_array_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_return_value (procedure,
g_param_spec_boxed (name, nick, blurb,
G_TYPE_STRV, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
app, libgimp*, plug-ins: move all GimpObjectArray procedure args to GimpCoreObjectArray.
2024-10-22 22:46:21 +02:00
/**
* gimp_procedure_add_core_object_array_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @object_type the type of object stored in the array
* @flags: argument flags.
*
* Add a new object array argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_core_object_array_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GType object_type,
GParamFlags flags)
{
_gimp_procedure_add_argument (procedure,
gimp_param_spec_core_object_array (name, nick, blurb,
object_type, flags));
}
/**
* gimp_procedure_add_core_object_array_aux_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @object_type the type of object stored in the array
* @flags: argument flags.
*
* Add a new object array auxiliary argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_core_object_array_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GType object_type,
GParamFlags flags)
{
_gimp_procedure_add_aux_argument (procedure,
gimp_param_spec_core_object_array (name, nick, blurb,
object_type, flags));
}
/**
* gimp_procedure_add_core_object_array_return_value:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @object_type the type of object stored in the array
* @flags: argument flags.
*
* Add a new object array return value to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_core_object_array_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GType object_type,
GParamFlags flags)
{
_gimp_procedure_add_return_value (procedure,
gimp_param_spec_core_object_array (name, nick, blurb,
object_type, flags));
}
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
/**
* gimp_procedure_add_display_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @none_ok: Whether no is a valid value.
* @flags: argument flags.
*
* Add a new #GimpDisplay argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_display_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_argument (procedure,
gimp_param_spec_display (name, nick, blurb,
none_ok, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_display_aux_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @none_ok: Whether no is a valid value.
* @flags: argument flags.
*
* Add a new #GimpDisplay auxiliary argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_display_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_aux_argument (procedure,
gimp_param_spec_display (name, nick, blurb,
none_ok, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_display_return_value:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @none_ok: Whether no is a valid value.
* @flags: argument flags.
*
* Add a new #GimpDisplay return value to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_display_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_return_value (procedure,
gimp_param_spec_display (name, nick, blurb,
none_ok, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_image_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @none_ok: Whether no is a valid value.
* @flags: argument flags.
*
* Add a new #GimpImage argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_image_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_argument (procedure,
gimp_param_spec_image (name, nick, blurb,
none_ok, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_image_aux_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @none_ok: Whether no is a valid value.
* @flags: argument flags.
*
* Add a new #GimpImage auxiliary argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_image_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_aux_argument (procedure,
gimp_param_spec_image (name, nick, blurb,
none_ok, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_image_return_value:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @none_ok: Whether no is a valid value.
* @flags: argument flags.
*
* Add a new #GimpImage return value to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_image_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_return_value (procedure,
gimp_param_spec_image (name, nick, blurb,
none_ok, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_item_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @none_ok: Whether no is a valid value.
* @flags: argument flags.
*
* Add a new #GimpItem argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_item_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_argument (procedure,
gimp_param_spec_item (name, nick, blurb,
none_ok, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_item_aux_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @none_ok: Whether no is a valid value.
* @flags: argument flags.
*
* Add a new #GimpItem auxiliary argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_item_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_aux_argument (procedure,
gimp_param_spec_item (name, nick, blurb,
none_ok, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_item_return_value:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @none_ok: Whether no is a valid value.
* @flags: argument flags.
*
* Add a new #GimpItem return value to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_item_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_return_value (procedure,
gimp_param_spec_item (name, nick, blurb,
none_ok, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_drawable_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @none_ok: Whether no is a valid value.
* @flags: argument flags.
*
* Add a new #GimpDrawable argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_drawable_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_argument (procedure,
gimp_param_spec_drawable (name, nick, blurb,
none_ok, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_drawable_aux_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @none_ok: Whether no is a valid value.
* @flags: argument flags.
*
* Add a new #GimpDrawable auxiliary argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_drawable_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_aux_argument (procedure,
gimp_param_spec_drawable (name, nick, blurb,
none_ok, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_drawable_return_value:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @none_ok: Whether no is a valid value.
* @flags: argument flags.
*
* Add a new #GimpDrawable return value to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_drawable_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_return_value (procedure,
gimp_param_spec_drawable (name, nick, blurb,
none_ok, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_layer_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @none_ok: Whether no is a valid value.
* @flags: argument flags.
*
* Add a new #GimpLayer argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_layer_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_argument (procedure,
gimp_param_spec_layer (name, nick, blurb,
none_ok, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_layer_aux_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @none_ok: Whether no is a valid value.
* @flags: argument flags.
*
* Add a new #GimpLayer auxiliary argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_layer_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_aux_argument (procedure,
gimp_param_spec_layer (name, nick, blurb,
none_ok, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_layer_return_value:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @none_ok: Whether no is a valid value.
* @flags: argument flags.
*
* Add a new #GimpLayer return value to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_layer_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_return_value (procedure,
gimp_param_spec_layer (name, nick, blurb,
none_ok, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_text_layer_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @none_ok: Whether no is a valid value.
* @flags: argument flags.
*
* Add a new #GimpTextLayer argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_text_layer_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_argument (procedure,
gimp_param_spec_text_layer (name, nick, blurb,
none_ok, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_text_layer_aux_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @none_ok: Whether no is a valid value.
* @flags: argument flags.
*
* Add a new #GimpTextLayer auxiliary argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_text_layer_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_aux_argument (procedure,
gimp_param_spec_text_layer (name, nick, blurb,
none_ok, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_text_layer_return_value:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @none_ok: Whether no is a valid value.
* @flags: argument flags.
*
* Add a new #GimpTextLayer return value to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_text_layer_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_return_value (procedure,
gimp_param_spec_text_layer (name, nick, blurb,
none_ok, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
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 17:24:11 +02:00
/**
* gimp_procedure_add_group_layer_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @none_ok: Whether no is a valid value.
* @flags: argument flags.
*
* Add a new [class@GroupLayer] argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_group_layer_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags)
{
_gimp_procedure_add_argument (procedure,
gimp_param_spec_group_layer (name, nick, blurb,
none_ok, flags));
}
/**
* gimp_procedure_add_group_layer_aux_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @none_ok: Whether no is a valid value.
* @flags: argument flags.
*
* Add a new [class@GroupLayer] auxiliary argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_group_layer_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags)
{
_gimp_procedure_add_aux_argument (procedure,
gimp_param_spec_group_layer (name, nick, blurb,
none_ok, flags));
}
/**
* gimp_procedure_add_group_layer_return_value:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @none_ok: Whether no is a valid value.
* @flags: argument flags.
*
* Add a new [class@GroupLayer] return value to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_group_layer_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags)
{
_gimp_procedure_add_return_value (procedure,
gimp_param_spec_group_layer (name, nick, blurb,
none_ok, flags));
}
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
/**
* gimp_procedure_add_channel_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @none_ok: Whether no is a valid value.
* @flags: argument flags.
*
* Add a new #GimpChannel argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_channel_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_argument (procedure,
gimp_param_spec_channel (name, nick, blurb,
none_ok, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_channel_aux_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @none_ok: Whether no is a valid value.
* @flags: argument flags.
*
* Add a new #GimpChannel auxiliary argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_channel_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_aux_argument (procedure,
gimp_param_spec_channel (name, nick, blurb,
none_ok, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_channel_return_value:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @none_ok: Whether no is a valid value.
* @flags: argument flags.
*
* Add a new #GimpChannel return value to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_channel_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_return_value (procedure,
gimp_param_spec_channel (name, nick, blurb,
none_ok, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_layer_mask_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @none_ok: Whether no is a valid value.
* @flags: argument flags.
*
* Add a new #GimpLayerMask argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_layer_mask_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_argument (procedure,
gimp_param_spec_layer_mask (name, nick, blurb,
none_ok, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_layer_mask_aux_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @none_ok: Whether no is a valid value.
* @flags: argument flags.
*
* Add a new #GimpLayerMask auxiliary argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_layer_mask_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_aux_argument (procedure,
gimp_param_spec_layer_mask (name, nick, blurb,
none_ok, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_layer_mask_return_value:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @none_ok: Whether no is a valid value.
* @flags: argument flags.
*
* Add a new #GimpLayerMask return value to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_layer_mask_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_return_value (procedure,
gimp_param_spec_layer_mask (name, nick, blurb,
none_ok, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_selection_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @none_ok: Whether no is a valid value.
* @flags: argument flags.
*
* Add a new #GimpSelection argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_selection_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_argument (procedure,
gimp_param_spec_selection (name, nick, blurb,
none_ok, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_selection_aux_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @none_ok: Whether no is a valid value.
* @flags: argument flags.
*
* Add a new #GimpSelection auxiliary argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_selection_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_aux_argument (procedure,
gimp_param_spec_selection (name, nick, blurb,
none_ok, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_selection_return_value:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @none_ok: Whether no is a valid value.
* @flags: argument flags.
*
* Add a new #GimpSelection return value to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_selection_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_return_value (procedure,
gimp_param_spec_selection (name, nick, blurb,
none_ok, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
app: Rename app/core GimpVectors vectors API... ...to path. Changes the names of gimp_vectors_* () API to gimp_path[s]_* (). Renames related files to [path] instead of [vectors], along with relevant enums and functions.
2024-07-13 05:07:57 +00:00
* gimp_procedure_add_path_argument:
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @none_ok: Whether no is a valid value.
* @flags: argument flags.
*
app: Rename app/core GimpVectors vectors API... ...to path. Changes the names of gimp_vectors_* () API to gimp_path[s]_* (). Renames related files to [path] instead of [vectors], along with relevant enums and functions.
2024-07-13 05:07:57 +00:00
* Add a new #GimpPath argument to @procedure.
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
*
* Since: 3.0
**/
void
app: Rename app/core GimpVectors vectors API... ...to path. Changes the names of gimp_vectors_* () API to gimp_path[s]_* (). Renames related files to [path] instead of [vectors], along with relevant enums and functions.
2024-07-13 05:07:57 +00:00
gimp_procedure_add_path_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags)
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_argument (procedure,
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 06:16:25 +00:00
gimp_param_spec_path (name, nick, blurb,
none_ok, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
app: Rename app/core GimpVectors vectors API... ...to path. Changes the names of gimp_vectors_* () API to gimp_path[s]_* (). Renames related files to [path] instead of [vectors], along with relevant enums and functions.
2024-07-13 05:07:57 +00:00
* gimp_procedure_add_path_aux_argument:
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @none_ok: Whether no is a valid value.
* @flags: argument flags.
*
app: Rename app/core GimpVectors vectors API... ...to path. Changes the names of gimp_vectors_* () API to gimp_path[s]_* (). Renames related files to [path] instead of [vectors], along with relevant enums and functions.
2024-07-13 05:07:57 +00:00
* Add a new #GimpPath auxiliary argument to @procedure.
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
*
* Since: 3.0
**/
void
app: Rename app/core GimpVectors vectors API... ...to path. Changes the names of gimp_vectors_* () API to gimp_path[s]_* (). Renames related files to [path] instead of [vectors], along with relevant enums and functions.
2024-07-13 05:07:57 +00:00
gimp_procedure_add_path_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags)
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_aux_argument (procedure,
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 06:16:25 +00:00
gimp_param_spec_path (name, nick, blurb,
none_ok, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
app: Rename app/core GimpVectors vectors API... ...to path. Changes the names of gimp_vectors_* () API to gimp_path[s]_* (). Renames related files to [path] instead of [vectors], along with relevant enums and functions.
2024-07-13 05:07:57 +00:00
* gimp_procedure_add_path_return_value:
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @none_ok: Whether no is a valid value.
* @flags: argument flags.
*
app: Rename app/core GimpVectors vectors API... ...to path. Changes the names of gimp_vectors_* () API to gimp_path[s]_* (). Renames related files to [path] instead of [vectors], along with relevant enums and functions.
2024-07-13 05:07:57 +00:00
* Add a new #GimpPath return value to @procedure.
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
*
* Since: 3.0
**/
void
app: Rename app/core GimpVectors vectors API... ...to path. Changes the names of gimp_vectors_* () API to gimp_path[s]_* (). Renames related files to [path] instead of [vectors], along with relevant enums and functions.
2024-07-13 05:07:57 +00:00
gimp_procedure_add_path_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags)
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_return_value (procedure,
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 06:16:25 +00:00
gimp_param_spec_path (name, nick, blurb,
none_ok, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_file_argument:
Issue #12045: no defaults for plugin args of type File. libgimpbase: - Mew GimpFileChooserAction enum type: basically a near-mapping of GtkFileChooserAction (GTK is not accessible from libgimpbase) with an added GIMP_FILE_CHOOSER_ACTION_ANY. - New GimpParamSpecFile param spec type: based off GimpParamSpecObject, it has a default value, but also a none_ok and action argument. This way, we can also know from the argument type if this is a file argument meant for selecting a normal file or a folder, or for saving into a file, or for creating a directory. libgimp, plug-ins: - All existing file arguments (until now using a standard GParamSpecObject param with GFile value type) were moved to the new GimpParamSpecFile. - Script-Fu in particular will now generate the appropriate param type depending on whether it is an SF-FILENAME or SF-DIRNAME. - File arguments are now stored between runs as a URI rather than as a path. As far as I can tell, a GFile always has a URI, but not always a path (in particular remote file won't have a path).
2025-01-22 17:15:28 +01:00
* @procedure: The #GimpProcedure.
* @name: The name of the argument to be created.
* @nick: The label used in #GimpProcedureDialog.
* @blurb: A more detailed help description.
* @action: The type of file to expect.
* @none_ok: Whether %NULL is allowed.
* @default_file: (nullable): File to use if none is assigned.
* @flags: Argument flags.
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
*
* Add a new #GFile argument to @procedure.
*
* Since: 3.0
**/
void
Issue #12045: no defaults for plugin args of type File. libgimpbase: - Mew GimpFileChooserAction enum type: basically a near-mapping of GtkFileChooserAction (GTK is not accessible from libgimpbase) with an added GIMP_FILE_CHOOSER_ACTION_ANY. - New GimpParamSpecFile param spec type: based off GimpParamSpecObject, it has a default value, but also a none_ok and action argument. This way, we can also know from the argument type if this is a file argument meant for selecting a normal file or a folder, or for saving into a file, or for creating a directory. libgimp, plug-ins: - All existing file arguments (until now using a standard GParamSpecObject param with GFile value type) were moved to the new GimpParamSpecFile. - Script-Fu in particular will now generate the appropriate param type depending on whether it is an SF-FILENAME or SF-DIRNAME. - File arguments are now stored between runs as a URI rather than as a path. As far as I can tell, a GFile always has a URI, but not always a path (in particular remote file won't have a path).
2025-01-22 17:15:28 +01:00
gimp_procedure_add_file_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GimpFileChooserAction action,
gboolean none_ok,
GFile *default_file,
GParamFlags flags)
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_argument (procedure,
Issue #12045: no defaults for plugin args of type File. libgimpbase: - Mew GimpFileChooserAction enum type: basically a near-mapping of GtkFileChooserAction (GTK is not accessible from libgimpbase) with an added GIMP_FILE_CHOOSER_ACTION_ANY. - New GimpParamSpecFile param spec type: based off GimpParamSpecObject, it has a default value, but also a none_ok and action argument. This way, we can also know from the argument type if this is a file argument meant for selecting a normal file or a folder, or for saving into a file, or for creating a directory. libgimp, plug-ins: - All existing file arguments (until now using a standard GParamSpecObject param with GFile value type) were moved to the new GimpParamSpecFile. - Script-Fu in particular will now generate the appropriate param type depending on whether it is an SF-FILENAME or SF-DIRNAME. - File arguments are now stored between runs as a URI rather than as a path. As far as I can tell, a GFile always has a URI, but not always a path (in particular remote file won't have a path).
2025-01-22 17:15:28 +01:00
gimp_param_spec_file (name, nick, blurb,
action, none_ok,
default_file, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_file_aux_argument:
Issue #12045: no defaults for plugin args of type File. libgimpbase: - Mew GimpFileChooserAction enum type: basically a near-mapping of GtkFileChooserAction (GTK is not accessible from libgimpbase) with an added GIMP_FILE_CHOOSER_ACTION_ANY. - New GimpParamSpecFile param spec type: based off GimpParamSpecObject, it has a default value, but also a none_ok and action argument. This way, we can also know from the argument type if this is a file argument meant for selecting a normal file or a folder, or for saving into a file, or for creating a directory. libgimp, plug-ins: - All existing file arguments (until now using a standard GParamSpecObject param with GFile value type) were moved to the new GimpParamSpecFile. - Script-Fu in particular will now generate the appropriate param type depending on whether it is an SF-FILENAME or SF-DIRNAME. - File arguments are now stored between runs as a URI rather than as a path. As far as I can tell, a GFile always has a URI, but not always a path (in particular remote file won't have a path).
2025-01-22 17:15:28 +01:00
* @procedure: The #GimpProcedure.
* @name: The name of the argument to be created.
* @nick: The label used in #GimpProcedureDialog.
* @blurb: A more detailed help description.
* @action: The type of file to expect.
* @none_ok: Whether %NULL is allowed.
* @default_file: (nullable): File to use if none is assigned.
* @flags: Argument flags.
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
*
* Add a new #GFile auxiliary argument to @procedure.
*
* Since: 3.0
**/
void
Issue #12045: no defaults for plugin args of type File. libgimpbase: - Mew GimpFileChooserAction enum type: basically a near-mapping of GtkFileChooserAction (GTK is not accessible from libgimpbase) with an added GIMP_FILE_CHOOSER_ACTION_ANY. - New GimpParamSpecFile param spec type: based off GimpParamSpecObject, it has a default value, but also a none_ok and action argument. This way, we can also know from the argument type if this is a file argument meant for selecting a normal file or a folder, or for saving into a file, or for creating a directory. libgimp, plug-ins: - All existing file arguments (until now using a standard GParamSpecObject param with GFile value type) were moved to the new GimpParamSpecFile. - Script-Fu in particular will now generate the appropriate param type depending on whether it is an SF-FILENAME or SF-DIRNAME. - File arguments are now stored between runs as a URI rather than as a path. As far as I can tell, a GFile always has a URI, but not always a path (in particular remote file won't have a path).
2025-01-22 17:15:28 +01:00
gimp_procedure_add_file_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GimpFileChooserAction action,
gboolean none_ok,
GFile *default_file,
GParamFlags flags)
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_aux_argument (procedure,
Issue #12045: no defaults for plugin args of type File. libgimpbase: - Mew GimpFileChooserAction enum type: basically a near-mapping of GtkFileChooserAction (GTK is not accessible from libgimpbase) with an added GIMP_FILE_CHOOSER_ACTION_ANY. - New GimpParamSpecFile param spec type: based off GimpParamSpecObject, it has a default value, but also a none_ok and action argument. This way, we can also know from the argument type if this is a file argument meant for selecting a normal file or a folder, or for saving into a file, or for creating a directory. libgimp, plug-ins: - All existing file arguments (until now using a standard GParamSpecObject param with GFile value type) were moved to the new GimpParamSpecFile. - Script-Fu in particular will now generate the appropriate param type depending on whether it is an SF-FILENAME or SF-DIRNAME. - File arguments are now stored between runs as a URI rather than as a path. As far as I can tell, a GFile always has a URI, but not always a path (in particular remote file won't have a path).
2025-01-22 17:15:28 +01:00
gimp_param_spec_file (name, nick, blurb,
action, none_ok,
default_file, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_file_return_value:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @flags: argument flags.
*
* Add a new #GFile return value to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_file_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_return_value (procedure,
Issue #12045: no defaults for plugin args of type File. libgimpbase: - Mew GimpFileChooserAction enum type: basically a near-mapping of GtkFileChooserAction (GTK is not accessible from libgimpbase) with an added GIMP_FILE_CHOOSER_ACTION_ANY. - New GimpParamSpecFile param spec type: based off GimpParamSpecObject, it has a default value, but also a none_ok and action argument. This way, we can also know from the argument type if this is a file argument meant for selecting a normal file or a folder, or for saving into a file, or for creating a directory. libgimp, plug-ins: - All existing file arguments (until now using a standard GParamSpecObject param with GFile value type) were moved to the new GimpParamSpecFile. - Script-Fu in particular will now generate the appropriate param type depending on whether it is an SF-FILENAME or SF-DIRNAME. - File arguments are now stored between runs as a URI rather than as a path. As far as I can tell, a GFile always has a URI, but not always a path (in particular remote file won't have a path).
2025-01-22 17:15:28 +01:00
gimp_param_spec_file (name, nick, blurb,
GIMP_FILE_CHOOSER_ACTION_ANY,
TRUE, NULL, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_resource_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
libgimp, plug-ins: fix gimp_procedure_add_*_argument() where `*` is a resource type. The correspondant param specs' fourth arg was a `none_ok` boolean, not a type. Carry over this argument to the gimp_procedure_add_*() function.
2024-07-05 22:19:34 +02:00
* @none_ok: whether %NULL is a valid value.
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 13:38:43 +02:00
* @default_value: (nullable): default value.
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
* @flags: argument flags.
*
* Add a new #GimpResource argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_resource_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
libgimp, plug-ins: fix gimp_procedure_add_*_argument() where `*` is a resource type. The correspondant param specs' fourth arg was a `none_ok` boolean, not a type. Carry over this argument to the gimp_procedure_add_*() function.
2024-07-05 22:19:34 +02:00
gboolean none_ok,
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
GimpResource *default_value,
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_argument (procedure,
gimp_param_spec_resource (name, nick, blurb,
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-02 23:38:13 +02:00
GIMP_TYPE_RESOURCE,
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
none_ok,
default_value,
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 13:38:43 +02:00
FALSE,
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_resource_aux_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
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 13:38:43 +02:00
* @default_value: (nullable): default value.
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
* @flags: argument flags.
*
* Add a new #GimpResource auxiliary argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_resource_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
GimpResource *default_value,
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_aux_argument (procedure,
gimp_param_spec_resource (name, nick, blurb,
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-02 23:38:13 +02:00
GIMP_TYPE_RESOURCE,
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
TRUE,
default_value,
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 13:38:43 +02:00
FALSE,
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_resource_return_value:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @flags: argument flags.
*
* Add a new #GimpResource return value to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_resource_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_return_value (procedure,
gimp_param_spec_resource (name, nick, blurb,
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-02 23:38:13 +02:00
GIMP_TYPE_RESOURCE,
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 13:38:43 +02:00
TRUE, NULL, FALSE, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_brush_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
libgimp, plug-ins: fix gimp_procedure_add_*_argument() where `*` is a resource type. The correspondant param specs' fourth arg was a `none_ok` boolean, not a type. Carry over this argument to the gimp_procedure_add_*() function.
2024-07-05 22:19:34 +02:00
* @none_ok: whether %NULL is a valid value.
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
* @default_value: (nullable): default value
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 13:38:43 +02:00
* @default_to_context: Use the context's brush as default value.
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
* @flags: argument flags.
*
* Add a new #GimpBrush argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_brush_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
libgimp, plug-ins: fix gimp_procedure_add_*_argument() where `*` is a resource type. The correspondant param specs' fourth arg was a `none_ok` boolean, not a type. Carry over this argument to the gimp_procedure_add_*() function.
2024-07-05 22:19:34 +02:00
gboolean none_ok,
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
GimpBrush *default_value,
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 13:38:43 +02:00
gboolean default_to_context,
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_argument (procedure,
gimp_param_spec_brush (name, nick, blurb,
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
none_ok,
default_value,
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 13:38:43 +02:00
default_to_context,
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_brush_aux_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
* @default_value: (nullable): default value
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 13:38:43 +02:00
* @default_to_context: Use the context's brush as default value.
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
* @flags: argument flags.
*
* Add a new #GimpBrush auxiliary argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_brush_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
GimpBrush *default_value,
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 13:38:43 +02:00
gboolean default_to_context,
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_aux_argument (procedure,
gimp_param_spec_brush (name, nick, blurb,
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
TRUE,
default_value,
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 13:38:43 +02:00
default_to_context,
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_brush_return_value:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @flags: argument flags.
*
* Add a new #GimpBrush return value to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_brush_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_return_value (procedure,
gimp_param_spec_brush (name, nick, blurb,
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 13:38:43 +02:00
TRUE, NULL, FALSE, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_font_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
libgimp, plug-ins: fix gimp_procedure_add_*_argument() where `*` is a resource type. The correspondant param specs' fourth arg was a `none_ok` boolean, not a type. Carry over this argument to the gimp_procedure_add_*() function.
2024-07-05 22:19:34 +02:00
* @none_ok: whether %NULL is a valid value.
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
* @default_value: (nullable): default value
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 13:38:43 +02:00
* @default_to_context: Use the context's font as default value.
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
* @flags: argument flags.
*
* Add a new #GimpFont argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_font_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
libgimp, plug-ins: fix gimp_procedure_add_*_argument() where `*` is a resource type. The correspondant param specs' fourth arg was a `none_ok` boolean, not a type. Carry over this argument to the gimp_procedure_add_*() function.
2024-07-05 22:19:34 +02:00
gboolean none_ok,
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
GimpFont *default_value,
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 13:38:43 +02:00
gboolean default_to_context,
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_argument (procedure,
gimp_param_spec_font (name, nick, blurb,
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
none_ok,
default_value,
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 13:38:43 +02:00
default_to_context,
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_font_aux_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
* @default_value: (nullable): default value
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 13:38:43 +02:00
* @default_to_context: Use the context's font as default value.
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
* @flags: argument flags.
*
* Add a new #GimpFont auxiliary argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_font_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
GimpFont *default_value,
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 13:38:43 +02:00
gboolean default_to_context,
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_aux_argument (procedure,
gimp_param_spec_font (name, nick, blurb,
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
TRUE,
default_value,
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 13:38:43 +02:00
default_to_context,
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_font_return_value:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @flags: argument flags.
*
* Add a new #GimpFont return value to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_font_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_return_value (procedure,
gimp_param_spec_font (name, nick, blurb,
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 13:38:43 +02:00
TRUE, NULL, FALSE, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_gradient_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
libgimp, plug-ins: fix gimp_procedure_add_*_argument() where `*` is a resource type. The correspondant param specs' fourth arg was a `none_ok` boolean, not a type. Carry over this argument to the gimp_procedure_add_*() function.
2024-07-05 22:19:34 +02:00
* @none_ok: whether %NULL is a valid value.
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
* @default_value: (nullable): default value
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 13:38:43 +02:00
* @default_to_context: Use the context's gradient as default value.
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
* @flags: argument flags.
*
* Add a new #GimpGradient argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_gradient_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
libgimp, plug-ins: fix gimp_procedure_add_*_argument() where `*` is a resource type. The correspondant param specs' fourth arg was a `none_ok` boolean, not a type. Carry over this argument to the gimp_procedure_add_*() function.
2024-07-05 22:19:34 +02:00
gboolean none_ok,
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
GimpGradient *default_value,
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 13:38:43 +02:00
gboolean default_to_context,
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_argument (procedure,
gimp_param_spec_gradient (name, nick, blurb,
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
none_ok,
default_value,
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 13:38:43 +02:00
default_to_context,
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_gradient_aux_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
* @default_value: (nullable): default value
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 13:38:43 +02:00
* @default_to_context: Use the context's gradient as default value.
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
* @flags: argument flags.
*
* Add a new #GimpGradient auxiliary argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_gradient_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
GimpGradient *default_value,
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 13:38:43 +02:00
gboolean default_to_context,
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_aux_argument (procedure,
gimp_param_spec_gradient (name, nick, blurb,
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
TRUE,
default_value,
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 13:38:43 +02:00
default_to_context,
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_gradient_return_value:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @flags: argument flags.
*
* Add a new #GimpGradient return value to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_gradient_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_return_value (procedure,
gimp_param_spec_gradient (name, nick, blurb,
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 13:38:43 +02:00
TRUE, NULL, FALSE, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_palette_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
libgimp, plug-ins: fix gimp_procedure_add_*_argument() where `*` is a resource type. The correspondant param specs' fourth arg was a `none_ok` boolean, not a type. Carry over this argument to the gimp_procedure_add_*() function.
2024-07-05 22:19:34 +02:00
* @none_ok: whether %NULL is a valid value.
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
* @default_value: (nullable): default value
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 13:38:43 +02:00
* @default_to_context: Use the context's palette as default value.
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
* @flags: argument flags.
*
* Add a new #GimpPalette argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_palette_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
libgimp, plug-ins: fix gimp_procedure_add_*_argument() where `*` is a resource type. The correspondant param specs' fourth arg was a `none_ok` boolean, not a type. Carry over this argument to the gimp_procedure_add_*() function.
2024-07-05 22:19:34 +02:00
gboolean none_ok,
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
GimpPalette *default_value,
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 13:38:43 +02:00
gboolean default_to_context,
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_argument (procedure,
gimp_param_spec_palette (name, nick, blurb,
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
none_ok,
default_value,
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 13:38:43 +02:00
default_to_context,
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_palette_aux_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
* @default_value: (nullable): default value
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 13:38:43 +02:00
* @default_to_context: Use the context's palette as default value.
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
* @flags: argument flags.
*
* Add a new #GimpPalette auxiliary argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_palette_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
GimpPalette *default_value,
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 13:38:43 +02:00
gboolean default_to_context,
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_aux_argument (procedure,
gimp_param_spec_palette (name, nick, blurb,
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
TRUE,
default_value,
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 13:38:43 +02:00
default_to_context,
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_palette_return_value:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @flags: argument flags.
*
* Add a new #GimpPalette return value to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_palette_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_return_value (procedure,
gimp_param_spec_palette (name, nick, blurb,
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 13:38:43 +02:00
TRUE, NULL, FALSE, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_pattern_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
libgimp, plug-ins: fix gimp_procedure_add_*_argument() where `*` is a resource type. The correspondant param specs' fourth arg was a `none_ok` boolean, not a type. Carry over this argument to the gimp_procedure_add_*() function.
2024-07-05 22:19:34 +02:00
* @none_ok: whether %NULL is a valid value.
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
* @default_value: (nullable): default value
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 13:38:43 +02:00
* @default_to_context: Use the context's pattern as default value.
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
* @flags: argument flags.
*
* Add a new #GimpPattern argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_pattern_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
libgimp, plug-ins: fix gimp_procedure_add_*_argument() where `*` is a resource type. The correspondant param specs' fourth arg was a `none_ok` boolean, not a type. Carry over this argument to the gimp_procedure_add_*() function.
2024-07-05 22:19:34 +02:00
gboolean none_ok,
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
GimpPattern *default_value,
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 13:38:43 +02:00
gboolean default_to_context,
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_argument (procedure,
gimp_param_spec_pattern (name, nick, blurb,
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
none_ok,
default_value,
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 13:38:43 +02:00
default_to_context,
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_pattern_aux_argument:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
* @default_value: (nullable): default value
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 13:38:43 +02:00
* @default_to_context: Use the context's pattern as default value.
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
* @flags: argument flags.
*
* Add a new #GimpPattern auxiliary argument to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_pattern_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
GimpPattern *default_value,
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 13:38:43 +02:00
gboolean default_to_context,
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_aux_argument (procedure,
gimp_param_spec_pattern (name, nick, blurb,
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
TRUE,
default_value,
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 13:38:43 +02:00
default_to_context,
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
/**
* gimp_procedure_add_pattern_return_value:
* @procedure: the #GimpProcedure.
* @name: the name of the argument to be created.
* @nick: the label used in #GimpProcedureDialog.
* @blurb: a more detailed help description.
* @flags: argument flags.
*
* Add a new #GimpPattern return value to @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_add_pattern_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GParamFlags flags)
{
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-05 22:29:35 +02:00
_gimp_procedure_add_return_value (procedure,
gimp_param_spec_pattern (name, nick, blurb,
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 13:38:43 +02:00
TRUE, NULL, FALSE, flags));
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
}
Reference in a new issue Copy permalink