2019-07-26 15:54:33 +02:00
|
|
|
/* LIBGIMP - The GIMP Library
|
|
|
|
* Copyright (C) 1995-2003 Peter Mattis and Spencer Kimball
|
|
|
|
*
|
|
|
|
* gimpparamspecs.h
|
|
|
|
*
|
|
|
|
* This library is free software: you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
* License as published by the Free Software Foundation; either
|
|
|
|
* version 3 of the License, or (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This library is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
* Lesser General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
|
|
|
* License along with this library. If not, see
|
|
|
|
* <https://www.gnu.org/licenses/>.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#if !defined (__GIMP_BASE_H_INSIDE__) && !defined (GIMP_BASE_COMPILATION)
|
|
|
|
#error "Only <libgimpbase/gimpbase.h> can be included directly."
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifndef __GIMP_PARAM_SPECS_H__
|
|
|
|
#define __GIMP_PARAM_SPECS_H__
|
|
|
|
|
|
|
|
G_BEGIN_DECLS
|
|
|
|
|
|
|
|
/* For information look into the C source or the html documentation */
|
|
|
|
|
2019-07-31 10:16:21 +02:00
|
|
|
|
|
|
|
/**
|
|
|
|
* GIMP_PARAM_NO_VALIDATE:
|
|
|
|
*
|
|
|
|
* Since 3.0
|
|
|
|
*/
|
app, libgimpbase, libgimpconfig: make our custom GParamFlags definitions…
… more robust.
GIMP_PARAM_NO_VALIDATE and GIMP_CONFIG_PARAM_DONT_COMPARE were the same
value, most likely because when GIMP_CONFIG_PARAM_DONT_COMPARE got added
(commit c5c807d1913), the comment to keep in sync
libgimpbase/gimpparamspecs.h and libgimpconfig/gimpconfig-params.h was
missed.
Instead, since libgimpconfig can include libgimpbase, do the other way
around: first non-GLib param flags are in libgimpbase, then we add a
GIMP_PARAM_FLAG_SHIFT, then we increment from it in libgimpconfig, and
finally we increment from GIMP_CONFIG_PARAM_FLAG_SHIFT if ever we add
more flags in app/ (right now GIMP_SYMMETRY_PARAM_GUI is apparently the
only one, but this may change).
2024-08-31 00:45:15 +02:00
|
|
|
#define GIMP_PARAM_NO_VALIDATE (1 << (0 + G_PARAM_USER_SHIFT))
|
|
|
|
|
2024-08-31 01:37:14 +02:00
|
|
|
/**
|
|
|
|
* GIMP_PARAM_DONT_SERIALIZE:
|
|
|
|
*
|
|
|
|
* This property will be ignored when serializing and deserializing.
|
|
|
|
* This is useful for GimpProcedure arguments for which you never want
|
|
|
|
* the last run values to be restored.
|
|
|
|
*
|
|
|
|
* Since 3.0
|
|
|
|
*/
|
|
|
|
#define GIMP_PARAM_DONT_SERIALIZE (1 << (1 + G_PARAM_USER_SHIFT))
|
|
|
|
|
app, libgimpbase, libgimpconfig: make our custom GParamFlags definitions…
… more robust.
GIMP_PARAM_NO_VALIDATE and GIMP_CONFIG_PARAM_DONT_COMPARE were the same
value, most likely because when GIMP_CONFIG_PARAM_DONT_COMPARE got added
(commit c5c807d1913), the comment to keep in sync
libgimpbase/gimpparamspecs.h and libgimpconfig/gimpconfig-params.h was
missed.
Instead, since libgimpconfig can include libgimpbase, do the other way
around: first non-GLib param flags are in libgimpbase, then we add a
GIMP_PARAM_FLAG_SHIFT, then we increment from it in libgimpconfig, and
finally we increment from GIMP_CONFIG_PARAM_FLAG_SHIFT if ever we add
more flags in app/ (right now GIMP_SYMMETRY_PARAM_GUI is apparently the
only one, but this may change).
2024-08-31 00:45:15 +02:00
|
|
|
/**
|
|
|
|
* GIMP_PARAM_FLAG_SHIFT:
|
|
|
|
*
|
|
|
|
* Minimum shift count to be used for libgimpconfig defined
|
|
|
|
* [flags@GObject.ParamFlags] (see libgimpconfig/gimpconfig-params.h).
|
2019-07-26 15:54:33 +02:00
|
|
|
*/
|
2024-08-31 01:37:14 +02:00
|
|
|
#define GIMP_PARAM_FLAG_SHIFT (2 + G_PARAM_USER_SHIFT)
|
2019-07-26 15:54:33 +02:00
|
|
|
|
2019-07-31 10:16:21 +02:00
|
|
|
/**
|
|
|
|
* GIMP_PARAM_STATIC_STRINGS:
|
|
|
|
*
|
|
|
|
* Since: 2.4
|
|
|
|
**/
|
|
|
|
#define GIMP_PARAM_STATIC_STRINGS (G_PARAM_STATIC_NAME | \
|
|
|
|
G_PARAM_STATIC_NICK | \
|
|
|
|
G_PARAM_STATIC_BLURB)
|
|
|
|
|
|
|
|
/**
|
|
|
|
* GIMP_PARAM_READABLE:
|
|
|
|
*
|
|
|
|
* Since: 2.4
|
|
|
|
**/
|
|
|
|
#define GIMP_PARAM_READABLE (G_PARAM_READABLE | \
|
|
|
|
GIMP_PARAM_STATIC_STRINGS)
|
|
|
|
|
|
|
|
/**
|
|
|
|
* GIMP_PARAM_WRITABLE:
|
|
|
|
*
|
|
|
|
* Since: 2.4
|
|
|
|
**/
|
|
|
|
#define GIMP_PARAM_WRITABLE (G_PARAM_WRITABLE | \
|
|
|
|
GIMP_PARAM_STATIC_STRINGS)
|
|
|
|
|
|
|
|
/**
|
|
|
|
* GIMP_PARAM_READWRITE:
|
|
|
|
*
|
|
|
|
* Since: 2.4
|
|
|
|
**/
|
|
|
|
#define GIMP_PARAM_READWRITE (G_PARAM_READWRITE | \
|
|
|
|
GIMP_PARAM_STATIC_STRINGS)
|
|
|
|
|
2019-07-26 15:54:33 +02:00
|
|
|
|
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_PARAM_OBJECT
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define GIMP_TYPE_PARAM_OBJECT (gimp_param_object_get_type ())
|
|
|
|
#define GIMP_PARAM_SPEC_OBJECT(pspec) (G_TYPE_CHECK_INSTANCE_CAST ((pspec), GIMP_TYPE_PARAM_OBJECT, GimpParamSpecObject))
|
|
|
|
#define GIMP_PARAM_SPEC_OBJECT_CLASS(klass) (G_TYPE_CHECK_CLASS_CAST ((klass), GIMP_TYPE_PARAM_OBJECT, GimpParamSpecObjectClass))
|
|
|
|
#define GIMP_IS_PARAM_SPEC_OBJECT(pspec) (G_TYPE_CHECK_INSTANCE_TYPE ((pspec), GIMP_TYPE_PARAM_OBJECT))
|
|
|
|
#define GIMP_IS_PARAM_SPEC_OBJECT_CLASS(klass) (G_TYPE_CHECK_CLASS_TYPE ((klass), GIMP_TYPE_PARAM_OBJECT))
|
|
|
|
#define GIMP_PARAM_SPEC_OBJECT_GET_CLASS(pspec) (G_TYPE_INSTANCE_GET_CLASS ((pspec), G_TYPE_PARAM_OBJECT, GimpParamSpecObjectClass))
|
|
|
|
|
|
|
|
|
|
|
|
typedef struct _GimpParamSpecObject GimpParamSpecObject;
|
|
|
|
typedef struct _GimpParamSpecObjectClass GimpParamSpecObjectClass;
|
|
|
|
|
|
|
|
struct _GimpParamSpecObject
|
|
|
|
{
|
|
|
|
GParamSpecObject parent_instance;
|
|
|
|
|
|
|
|
/*< private >*/
|
|
|
|
GObject *_default_value;
|
|
|
|
gboolean _has_default;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct _GimpParamSpecObjectClass
|
|
|
|
{
|
|
|
|
/* XXX: vapigen fails with the following error without the private
|
|
|
|
* comment:
|
|
|
|
* > error: The type name `GLib.ParamSpecClass' could not be found
|
|
|
|
* Not sure why it doesn't search for GObject.ParamSpecClass instead.
|
|
|
|
* Anyway putting it private is good enough and hides the parent_class
|
|
|
|
* to bindings.
|
|
|
|
*/
|
|
|
|
/*< private >*/
|
|
|
|
GParamSpecClass parent_class;
|
|
|
|
|
2024-09-06 13:38:43 +02:00
|
|
|
GParamSpec * (* duplicate) (GParamSpec *pspec);
|
|
|
|
GObject * (* get_default) (GParamSpec *pspec);
|
app, libgimp*, pdb: new GimpParamSpecObject abstract spec type.
This abstract spec type is basically a GParamSpecObject with a default
value. It will be used by various object spec with default values, such
as GimpParamSpecColor, GimpParamSpecUnit and all GimpParamSpecResource
subtypes. Also it has a duplicate() class method so that every spec type
can implement the proper way to duplicate itself.
This fixes the fact that in gimp_config_param_spec_duplicate(), all
unknown object spec types (because they are implemented in libgimp,
which is invisible to libgimpconfig) are just copied as
GParamSpecObject, hence losing default values and other parameters.
As a second enhancement, it also makes it easier to detect the object
spec types for which we have default value support in
gimp_config_reset_properties().
As a side fix, gimp_param_spec_color() now just always duplicates the
passed default color, making it hence much easier to avoid bugs when
reusing a GeglColor.
2024-09-02 23:38:13 +02:00
|
|
|
|
|
|
|
/* Padding for future expansion */
|
|
|
|
void (*_gimp_reserved0) (void);
|
|
|
|
void (*_gimp_reserved1) (void);
|
|
|
|
void (*_gimp_reserved2) (void);
|
|
|
|
void (*_gimp_reserved3) (void);
|
|
|
|
void (*_gimp_reserved4) (void);
|
|
|
|
void (*_gimp_reserved5) (void);
|
|
|
|
void (*_gimp_reserved6) (void);
|
|
|
|
void (*_gimp_reserved7) (void);
|
|
|
|
void (*_gimp_reserved8) (void);
|
|
|
|
void (*_gimp_reserved9) (void);
|
|
|
|
};
|
|
|
|
|
|
|
|
GType gimp_param_object_get_type (void) G_GNUC_CONST;
|
|
|
|
|
|
|
|
GObject * gimp_param_spec_object_get_default (GParamSpec *pspec);
|
|
|
|
void gimp_param_spec_object_set_default (GParamSpec *pspec,
|
|
|
|
GObject *default_value);
|
|
|
|
gboolean gimp_param_spec_object_has_default (GParamSpec *pspec);
|
|
|
|
|
|
|
|
GParamSpec * gimp_param_spec_object_duplicate (GParamSpec *pspec);
|
|
|
|
|
|
|
|
|
2025-01-22 17:15:28 +01:00
|
|
|
/*
|
|
|
|
* GIMP_TYPE_PARAM_FILE
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define GIMP_VALUE_HOLDS_FILE(value) (G_TYPE_CHECK_VALUE_TYPE ((value), G_TYPE_FILE))
|
|
|
|
|
|
|
|
#define GIMP_TYPE_PARAM_FILE (gimp_param_file_get_type ())
|
|
|
|
#define GIMP_IS_PARAM_SPEC_FILE(pspec) (G_TYPE_CHECK_INSTANCE_TYPE ((pspec), GIMP_TYPE_PARAM_FILE))
|
|
|
|
|
|
|
|
|
2025-01-24 23:42:20 +01:00
|
|
|
GType gimp_param_file_get_type (void) G_GNUC_CONST;
|
2025-01-22 17:15:28 +01:00
|
|
|
|
2025-01-24 23:42:20 +01:00
|
|
|
GParamSpec * gimp_param_spec_file (const gchar *name,
|
|
|
|
const gchar *nick,
|
|
|
|
const gchar *blurb,
|
|
|
|
GimpFileChooserAction action,
|
|
|
|
gboolean none_ok,
|
|
|
|
GFile *default_value,
|
|
|
|
GParamFlags flags);
|
2025-01-22 17:15:28 +01:00
|
|
|
|
2025-01-24 23:42:20 +01:00
|
|
|
GimpFileChooserAction gimp_param_spec_file_get_action (GParamSpec *pspec);
|
|
|
|
gboolean gimp_param_spec_file_none_allowed (GParamSpec *pspec);
|
2025-01-22 17:15:28 +01:00
|
|
|
|
|
|
|
|
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
|
|
|
|
2019-07-26 15:54:33 +02:00
|
|
|
/*
|
|
|
|
* GIMP_TYPE_ARRAY
|
|
|
|
*/
|
|
|
|
|
2019-12-27 19:55:28 +01:00
|
|
|
/**
|
|
|
|
* GimpArray:
|
2020-10-28 20:51:48 +01:00
|
|
|
* @data: (array length=length): pointer to the array's data.
|
2019-12-27 19:55:28 +01:00
|
|
|
* @length: length of @data, in bytes.
|
|
|
|
* @static_data: whether @data points to statically allocated memory.
|
|
|
|
**/
|
2019-07-26 15:54:33 +02:00
|
|
|
typedef struct _GimpArray GimpArray;
|
|
|
|
|
|
|
|
struct _GimpArray
|
|
|
|
{
|
|
|
|
guint8 *data;
|
|
|
|
gsize length;
|
|
|
|
gboolean static_data;
|
|
|
|
};
|
|
|
|
|
|
|
|
GimpArray * gimp_array_new (const guint8 *data,
|
|
|
|
gsize length,
|
|
|
|
gboolean static_data);
|
|
|
|
GimpArray * gimp_array_copy (const GimpArray *array);
|
|
|
|
void gimp_array_free (GimpArray *array);
|
|
|
|
|
|
|
|
#define GIMP_TYPE_ARRAY (gimp_array_get_type ())
|
|
|
|
#define GIMP_VALUE_HOLDS_ARRAY(value) (G_TYPE_CHECK_VALUE_TYPE ((value), GIMP_TYPE_ARRAY))
|
|
|
|
|
|
|
|
GType gimp_array_get_type (void) G_GNUC_CONST;
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* GIMP_TYPE_PARAM_ARRAY
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define GIMP_TYPE_PARAM_ARRAY (gimp_param_array_get_type ())
|
|
|
|
#define GIMP_IS_PARAM_SPEC_ARRAY(pspec) (G_TYPE_CHECK_INSTANCE_TYPE ((pspec), GIMP_TYPE_PARAM_ARRAY))
|
|
|
|
|
|
|
|
GType gimp_param_array_get_type (void) G_GNUC_CONST;
|
|
|
|
|
|
|
|
GParamSpec * gimp_param_spec_array (const gchar *name,
|
|
|
|
const gchar *nick,
|
|
|
|
const gchar *blurb,
|
|
|
|
GParamFlags flags);
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* GIMP_TYPE_INT32_ARRAY
|
|
|
|
*/
|
|
|
|
|
2024-10-24 17:43:09 +02:00
|
|
|
#define GIMP_TYPE_INT32_ARRAY (gimp_int32_array_get_type ())
|
|
|
|
#define GIMP_VALUE_HOLDS_INT32_ARRAY(value) (G_TYPE_CHECK_VALUE_TYPE ((value), GIMP_TYPE_INT32_ARRAY))
|
2019-07-26 15:54:33 +02:00
|
|
|
|
2024-10-24 17:43:09 +02:00
|
|
|
GType gimp_int32_array_get_type (void) G_GNUC_CONST;
|
|
|
|
|
|
|
|
const gint32 * gimp_int32_array_get_values (GimpArray *array,
|
|
|
|
gsize *length);
|
|
|
|
void gimp_int32_array_set_values (GimpArray *array,
|
|
|
|
const gint32 *values,
|
|
|
|
gsize length,
|
|
|
|
gboolean static_data);
|
2019-07-26 15:54:33 +02:00
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* GIMP_TYPE_PARAM_INT32_ARRAY
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define GIMP_TYPE_PARAM_INT32_ARRAY (gimp_param_int32_array_get_type ())
|
|
|
|
#define GIMP_IS_PARAM_SPEC_INT32_ARRAY(pspec) (G_TYPE_CHECK_INSTANCE_TYPE ((pspec), GIMP_TYPE_PARAM_INT32_ARRAY))
|
|
|
|
|
|
|
|
GType gimp_param_int32_array_get_type (void) G_GNUC_CONST;
|
|
|
|
|
|
|
|
GParamSpec * gimp_param_spec_int32_array (const gchar *name,
|
|
|
|
const gchar *nick,
|
|
|
|
const gchar *blurb,
|
|
|
|
GParamFlags flags);
|
|
|
|
|
app, libgimp*, pdb, plug-ins: first step to make int32array PDB type aware of its length.
PDB code is now looking directly into the GimpArray length for
determining the data length.
Also adding a 'size' argument (number of elements, not bytes) to
gimp_value_(get|dup)_int32_array() to make it actually introspectable.
Until now, it was somehow introspected but was segfaulting on run.
I.e. that, e.g. in Python, calling Gimp.value_set_int32_array(v, [1, 2, 3])
followed by Gimp.value_get_int32_array(v) would actually make a
segmentation fault. Now the binding works flawlessly.
This will also make these functions much more usable in general.
2024-10-24 09:48:14 +02:00
|
|
|
const gint32 * gimp_value_get_int32_array (const GValue *value,
|
|
|
|
gsize *length);
|
|
|
|
gint32 * gimp_value_dup_int32_array (const GValue *value,
|
|
|
|
gsize *length);
|
2019-07-26 15:54:33 +02:00
|
|
|
void gimp_value_set_int32_array (GValue *value,
|
2020-06-06 13:22:57 +02:00
|
|
|
const gint32 *data,
|
2019-07-26 15:54:33 +02:00
|
|
|
gsize length);
|
|
|
|
void gimp_value_set_static_int32_array (GValue *value,
|
2020-06-06 13:22:57 +02:00
|
|
|
const gint32 *data,
|
2019-07-26 15:54:33 +02:00
|
|
|
gsize length);
|
|
|
|
void gimp_value_take_int32_array (GValue *value,
|
2020-06-06 13:22:57 +02:00
|
|
|
gint32 *data,
|
2019-07-26 15:54:33 +02:00
|
|
|
gsize length);
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
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_TYPE_DOUBLE_ARRAY
|
2019-07-26 15:54:33 +02: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
|
|
|
#define GIMP_TYPE_DOUBLE_ARRAY (gimp_double_array_get_type ())
|
|
|
|
#define GIMP_VALUE_HOLDS_DOUBLE_ARRAY(value) (G_TYPE_CHECK_VALUE_TYPE ((value), GIMP_TYPE_DOUBLE_ARRAY))
|
2019-07-26 15:54:33 +02: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
|
|
|
GType gimp_double_array_get_type (void) G_GNUC_CONST;
|
2024-10-24 22:18:20 +02: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
|
|
|
const gdouble * gimp_double_array_get_values (GimpArray *array,
|
|
|
|
gsize *length);
|
|
|
|
void gimp_double_array_set_values (GimpArray *array,
|
|
|
|
const gdouble *values,
|
|
|
|
gsize length,
|
|
|
|
gboolean static_data);
|
2019-07-26 15:54:33 +02: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_TYPE_PARAM_DOUBLE_ARRAY
|
2019-07-26 15:54:33 +02: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
|
|
|
#define GIMP_TYPE_PARAM_DOUBLE_ARRAY (gimp_param_double_array_get_type ())
|
|
|
|
#define GIMP_IS_PARAM_SPEC_DOUBLE_ARRAY(pspec) (G_TYPE_CHECK_INSTANCE_TYPE ((pspec), GIMP_TYPE_PARAM_DOUBLE_ARRAY))
|
|
|
|
|
|
|
|
GType gimp_param_double_array_get_type (void) G_GNUC_CONST;
|
|
|
|
|
|
|
|
GParamSpec * gimp_param_spec_double_array (const gchar *name,
|
|
|
|
const gchar *nick,
|
|
|
|
const gchar *blurb,
|
|
|
|
GParamFlags flags);
|
|
|
|
|
|
|
|
const gdouble * gimp_value_get_double_array (const GValue *value,
|
|
|
|
gsize *length);
|
|
|
|
gdouble * gimp_value_dup_double_array (const GValue *value,
|
|
|
|
gsize *length);
|
|
|
|
void gimp_value_set_double_array (GValue *value,
|
|
|
|
const gdouble *data,
|
|
|
|
gsize length);
|
|
|
|
void gimp_value_set_static_double_array (GValue *value,
|
|
|
|
const gdouble *data,
|
|
|
|
gsize length);
|
|
|
|
void gimp_value_take_double_array (GValue *value,
|
|
|
|
gdouble *data,
|
|
|
|
gsize length);
|
2019-07-26 15:54:33 +02:00
|
|
|
|
|
|
|
|
2024-02-28 22:13:57 +01:00
|
|
|
/*
|
|
|
|
* GIMP_TYPE_COLOR_ARRAY
|
|
|
|
*/
|
|
|
|
|
2023-12-27 01:07:19 +09:00
|
|
|
/**
|
2024-08-02 14:18:44 +02:00
|
|
|
* GimpColorArray:
|
2023-12-27 01:07:19 +09:00
|
|
|
*
|
2024-02-28 22:13:57 +01:00
|
|
|
* A boxed type which is nothing more than an alias to a %NULL-terminated array
|
|
|
|
* of [class@Gegl.Color].
|
2023-12-27 01:07:19 +09:00
|
|
|
*
|
|
|
|
* The code fragments in the following example show the use of a property of
|
2024-02-28 22:13:57 +01:00
|
|
|
* type %GIMP_TYPE_COLOR_ARRAY with g_object_class_install_property(),
|
|
|
|
* g_object_set() and g_object_get().
|
2023-12-27 01:07:19 +09:00
|
|
|
*
|
|
|
|
* ```C
|
|
|
|
* g_object_class_install_property (object_class,
|
|
|
|
* PROP_COLORS,
|
|
|
|
* g_param_spec_boxed ("colors",
|
|
|
|
* _("Colors"),
|
|
|
|
* _("List of colors"),
|
|
|
|
* GIMP_TYPE_COLOR_ARRAY,
|
|
|
|
* G_PARAM_READWRITE | G_PARAM_STATIC_STRINGS));
|
|
|
|
*
|
|
|
|
* GeglColor *colors[] = { gegl_color_new ("red"), gegl_color_new ("blue"), NULL };
|
|
|
|
*
|
|
|
|
* g_object_set (obj, "colors", colors, NULL);
|
|
|
|
*
|
|
|
|
* GeglColors **colors;
|
|
|
|
*
|
|
|
|
* g_object_get (obj, "colors", &colors, NULL);
|
|
|
|
* gimp_color_array_free (colors);
|
|
|
|
* ```
|
|
|
|
*
|
|
|
|
* Since: 3.0
|
|
|
|
*/
|
|
|
|
typedef GeglColor** GimpColorArray;
|
|
|
|
|
|
|
|
#define GIMP_TYPE_COLOR_ARRAY (gimp_color_array_get_type ())
|
|
|
|
#define GIMP_VALUE_HOLDS_COLOR_ARRAY(value) (G_TYPE_CHECK_VALUE_TYPE ((value), GIMP_TYPE_COLOR_ARRAY))
|
|
|
|
|
|
|
|
|
|
|
|
GType gimp_color_array_get_type (void) G_GNUC_CONST;
|
|
|
|
|
|
|
|
GimpColorArray gimp_color_array_copy (GimpColorArray array);
|
|
|
|
void gimp_color_array_free (GimpColorArray array);
|
|
|
|
gint gimp_color_array_get_length (GimpColorArray array);
|
|
|
|
|
|
|
|
|
2024-10-21 21:59:26 +02:00
|
|
|
/*
|
|
|
|
* GIMP_TYPE_CORE_OBJECT_ARRAY
|
|
|
|
*/
|
|
|
|
|
|
|
|
/**
|
|
|
|
* GimpCoreObjectArray:
|
|
|
|
*
|
|
|
|
* A boxed type which is nothing more than an alias to a %NULL-terminated array
|
|
|
|
* of [class@GObject.Object]. No reference is being hold on contents
|
|
|
|
* because core objects are owned by `libgimp`.
|
|
|
|
*
|
|
|
|
* The reason of existence for this alias is to have common arrays of
|
|
|
|
* objects as a boxed type easy to use as plug-in's procedure argument.
|
|
|
|
*
|
2024-10-21 23:57:10 +02:00
|
|
|
* You should never have to interact with this type directly, though
|
|
|
|
* [func@Gimp.core_object_array_get_length] might be convenient.
|
2024-10-21 21:59:26 +02:00
|
|
|
*
|
|
|
|
* Since: 3.0
|
|
|
|
*/
|
|
|
|
typedef GObject** GimpCoreObjectArray;
|
|
|
|
|
|
|
|
#define GIMP_TYPE_CORE_OBJECT_ARRAY (gimp_core_object_array_get_type ())
|
|
|
|
#define GIMP_VALUE_HOLDS_CORE_OBJECT_ARRAY(value) (G_TYPE_CHECK_VALUE_TYPE ((value), GIMP_TYPE_CORE_OBJECT_ARRAY))
|
|
|
|
|
2024-10-21 23:57:10 +02:00
|
|
|
GType gimp_core_object_array_get_type (void) G_GNUC_CONST;
|
|
|
|
gsize gimp_core_object_array_get_length (GObject **array);
|
2024-10-21 21:59:26 +02:00
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* GIMP_TYPE_PARAM_CORE_OBJECT_ARRAY
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define GIMP_TYPE_PARAM_CORE_OBJECT_ARRAY (gimp_param_core_object_array_get_type ())
|
|
|
|
#define GIMP_PARAM_SPEC_CORE_OBJECT_ARRAY(pspec) (G_TYPE_CHECK_INSTANCE_CAST ((pspec), GIMP_TYPE_PARAM_CORE_OBJECT_ARRAY, GimpParamSpecCoreObjectArray))
|
|
|
|
#define GIMP_IS_PARAM_SPEC_CORE_OBJECT_ARRAY(pspec) (G_TYPE_CHECK_INSTANCE_TYPE ((pspec), GIMP_TYPE_PARAM_CORE_OBJECT_ARRAY))
|
|
|
|
|
|
|
|
typedef struct _GimpParamSpecCoreObjectArray GimpParamSpecCoreObjectArray;
|
|
|
|
|
|
|
|
struct _GimpParamSpecCoreObjectArray
|
|
|
|
{
|
|
|
|
GParamSpecBoxed parent_instance;
|
|
|
|
|
|
|
|
GType object_type;
|
|
|
|
};
|
|
|
|
|
|
|
|
GType gimp_param_core_object_array_get_type (void) G_GNUC_CONST;
|
|
|
|
|
|
|
|
GParamSpec * gimp_param_spec_core_object_array (const gchar *name,
|
|
|
|
const gchar *nick,
|
|
|
|
const gchar *blurb,
|
|
|
|
GType object_type,
|
|
|
|
GParamFlags flags);
|
|
|
|
|
|
|
|
|
2019-07-26 15:54:33 +02:00
|
|
|
G_END_DECLS
|
|
|
|
|
|
|
|
#endif /* __GIMP_PARAM_SPECS_H__ */
|