2019-07-26 21:54:33 +08:00
|
|
|
/* LIBGIMP - The GIMP Library
|
|
|
|
* Copyright (C) 1995-2003 Peter Mattis and Spencer Kimball
|
|
|
|
*
|
|
|
|
* gimpparamspecs.c
|
|
|
|
*
|
|
|
|
* 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/>.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "config.h"
|
|
|
|
|
|
|
|
#include <gio/gio.h>
|
|
|
|
|
|
|
|
#include "gimpbase.h"
|
|
|
|
|
|
|
|
|
app, libgimp*, pdb: new GimpParamSpecObject abstract spec type.
This abstract spec type is basically a GParamSpecObject with a default
value. It will be used by various object spec with default values, such
as GimpParamSpecColor, GimpParamSpecUnit and all GimpParamSpecResource
subtypes. Also it has a duplicate() class method so that every spec type
can implement the proper way to duplicate itself.
This fixes the fact that in gimp_config_param_spec_duplicate(), all
unknown object spec types (because they are implemented in libgimp,
which is invisible to libgimpconfig) are just copied as
GParamSpecObject, hence losing default values and other parameters.
As a second enhancement, it also makes it easier to detect the object
spec types for which we have default value support in
gimp_config_reset_properties().
As a side fix, gimp_param_spec_color() now just always duplicates the
passed default color, making it hence much easier to avoid bugs when
reusing a GeglColor.
2024-09-03 05:38:13 +08:00
|
|
|
/*
|
|
|
|
* GIMP_TYPE_PARAM_OBJECT
|
|
|
|
*/
|
|
|
|
|
2024-09-06 19:38:43 +08:00
|
|
|
static void gimp_param_object_class_init (GimpParamSpecObjectClass *klass);
|
|
|
|
static void gimp_param_object_init (GimpParamSpecObject *pspec);
|
|
|
|
static void gimp_param_object_finalize (GParamSpec *pspec);
|
|
|
|
static void gimp_param_object_value_set_default (GParamSpec *pspec,
|
|
|
|
GValue *value);
|
app, libgimp*, pdb: new GimpParamSpecObject abstract spec type.
This abstract spec type is basically a GParamSpecObject with a default
value. It will be used by various object spec with default values, such
as GimpParamSpecColor, GimpParamSpecUnit and all GimpParamSpecResource
subtypes. Also it has a duplicate() class method so that every spec type
can implement the proper way to duplicate itself.
This fixes the fact that in gimp_config_param_spec_duplicate(), all
unknown object spec types (because they are implemented in libgimp,
which is invisible to libgimpconfig) are just copied as
GParamSpecObject, hence losing default values and other parameters.
As a second enhancement, it also makes it easier to detect the object
spec types for which we have default value support in
gimp_config_reset_properties().
As a side fix, gimp_param_spec_color() now just always duplicates the
passed default color, making it hence much easier to avoid bugs when
reusing a GeglColor.
2024-09-03 05:38:13 +08:00
|
|
|
|
2024-09-06 19:38:43 +08:00
|
|
|
static GParamSpec * gimp_param_spec_object_real_duplicate (GParamSpec *pspec);
|
|
|
|
static GObject * gimp_param_spec_object_real_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-03 05:38:13 +08:00
|
|
|
|
|
|
|
|
|
|
|
GType
|
|
|
|
gimp_param_object_get_type (void)
|
|
|
|
{
|
|
|
|
static GType type = 0;
|
|
|
|
|
|
|
|
if (! type)
|
|
|
|
{
|
|
|
|
const GTypeInfo info =
|
|
|
|
{
|
|
|
|
sizeof (GimpParamSpecObjectClass),
|
|
|
|
NULL, NULL,
|
|
|
|
(GClassInitFunc) gimp_param_object_class_init,
|
|
|
|
NULL, NULL,
|
|
|
|
sizeof (GimpParamSpecObject),
|
|
|
|
0,
|
|
|
|
(GInstanceInitFunc) gimp_param_object_init
|
|
|
|
};
|
|
|
|
|
|
|
|
type = g_type_register_static (G_TYPE_PARAM_OBJECT,
|
|
|
|
"GimpParamObject", &info, G_TYPE_FLAG_ABSTRACT);
|
|
|
|
}
|
|
|
|
|
|
|
|
return type;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
gimp_param_object_class_init (GimpParamSpecObjectClass *klass)
|
|
|
|
{
|
|
|
|
GParamSpecClass *pclass = G_PARAM_SPEC_CLASS (klass);
|
|
|
|
|
|
|
|
klass->duplicate = gimp_param_spec_object_real_duplicate;
|
2024-09-06 19:38:43 +08:00
|
|
|
klass->get_default = gimp_param_spec_object_real_get_default;
|
app, libgimp*, pdb: new GimpParamSpecObject abstract spec type.
This abstract spec type is basically a GParamSpecObject with a default
value. It will be used by various object spec with default values, such
as GimpParamSpecColor, GimpParamSpecUnit and all GimpParamSpecResource
subtypes. Also it has a duplicate() class method so that every spec type
can implement the proper way to duplicate itself.
This fixes the fact that in gimp_config_param_spec_duplicate(), all
unknown object spec types (because they are implemented in libgimp,
which is invisible to libgimpconfig) are just copied as
GParamSpecObject, hence losing default values and other parameters.
As a second enhancement, it also makes it easier to detect the object
spec types for which we have default value support in
gimp_config_reset_properties().
As a side fix, gimp_param_spec_color() now just always duplicates the
passed default color, making it hence much easier to avoid bugs when
reusing a GeglColor.
2024-09-03 05:38:13 +08:00
|
|
|
|
|
|
|
pclass->value_type = G_TYPE_OBJECT;
|
|
|
|
pclass->finalize = gimp_param_object_finalize;
|
|
|
|
pclass->value_set_default = gimp_param_object_value_set_default;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
gimp_param_object_init (GimpParamSpecObject *ospec)
|
|
|
|
{
|
|
|
|
ospec->_default_value = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
gimp_param_object_finalize (GParamSpec *pspec)
|
|
|
|
{
|
|
|
|
GimpParamSpecObject *ospec = GIMP_PARAM_SPEC_OBJECT (pspec);
|
|
|
|
GParamSpecClass *parent_class = g_type_class_peek (g_type_parent (GIMP_TYPE_PARAM_OBJECT));
|
|
|
|
|
|
|
|
g_clear_object (&ospec->_default_value);
|
|
|
|
|
|
|
|
parent_class->finalize (pspec);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
gimp_param_object_value_set_default (GParamSpec *pspec,
|
|
|
|
GValue *value)
|
|
|
|
{
|
2024-09-06 19:38:43 +08:00
|
|
|
GObject *default_value;
|
|
|
|
|
app, libgimp*, pdb: new GimpParamSpecObject abstract spec type.
This abstract spec type is basically a GParamSpecObject with a default
value. It will be used by various object spec with default values, such
as GimpParamSpecColor, GimpParamSpecUnit and all GimpParamSpecResource
subtypes. Also it has a duplicate() class method so that every spec type
can implement the proper way to duplicate itself.
This fixes the fact that in gimp_config_param_spec_duplicate(), all
unknown object spec types (because they are implemented in libgimp,
which is invisible to libgimpconfig) are just copied as
GParamSpecObject, hence losing default values and other parameters.
As a second enhancement, it also makes it easier to detect the object
spec types for which we have default value support in
gimp_config_reset_properties().
As a side fix, gimp_param_spec_color() now just always duplicates the
passed default color, making it hence much easier to avoid bugs when
reusing a GeglColor.
2024-09-03 05:38:13 +08:00
|
|
|
g_return_if_fail (GIMP_IS_PARAM_SPEC_OBJECT (pspec));
|
|
|
|
|
2024-09-06 19:38:43 +08:00
|
|
|
default_value = gimp_param_spec_object_get_default (pspec);
|
|
|
|
g_value_set_object (value, default_value);
|
app, libgimp*, pdb: new GimpParamSpecObject abstract spec type.
This abstract spec type is basically a GParamSpecObject with a default
value. It will be used by various object spec with default values, such
as GimpParamSpecColor, GimpParamSpecUnit and all GimpParamSpecResource
subtypes. Also it has a duplicate() class method so that every spec type
can implement the proper way to duplicate itself.
This fixes the fact that in gimp_config_param_spec_duplicate(), all
unknown object spec types (because they are implemented in libgimp,
which is invisible to libgimpconfig) are just copied as
GParamSpecObject, hence losing default values and other parameters.
As a second enhancement, it also makes it easier to detect the object
spec types for which we have default value support in
gimp_config_reset_properties().
As a side fix, gimp_param_spec_color() now just always duplicates the
passed default color, making it hence much easier to avoid bugs when
reusing a GeglColor.
2024-09-03 05:38:13 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static GParamSpec *
|
|
|
|
gimp_param_spec_object_real_duplicate (GParamSpec *pspec)
|
|
|
|
{
|
|
|
|
GimpParamSpecObject *ospec;
|
|
|
|
GimpParamSpecObject *duplicate;
|
|
|
|
|
|
|
|
g_return_val_if_fail (GIMP_IS_PARAM_SPEC_OBJECT (pspec), NULL);
|
|
|
|
|
|
|
|
ospec = GIMP_PARAM_SPEC_OBJECT (pspec);
|
|
|
|
duplicate = g_param_spec_internal (G_TYPE_FROM_INSTANCE (pspec),
|
|
|
|
pspec->name,
|
|
|
|
g_param_spec_get_nick (pspec),
|
|
|
|
g_param_spec_get_blurb (pspec),
|
|
|
|
pspec->flags);
|
|
|
|
|
|
|
|
duplicate->_default_value = ospec->_default_value ? g_object_ref (ospec->_default_value) : NULL;
|
|
|
|
duplicate->_has_default = ospec->_has_default;
|
|
|
|
|
|
|
|
return G_PARAM_SPEC (duplicate);
|
|
|
|
}
|
|
|
|
|
2024-09-06 19:38:43 +08:00
|
|
|
static GObject *
|
|
|
|
gimp_param_spec_object_real_get_default (GParamSpec *pspec)
|
|
|
|
{
|
|
|
|
g_return_val_if_fail (GIMP_IS_PARAM_SPEC_OBJECT (pspec), NULL);
|
|
|
|
g_return_val_if_fail (GIMP_PARAM_SPEC_OBJECT (pspec)->_has_default, NULL);
|
|
|
|
|
|
|
|
return GIMP_PARAM_SPEC_OBJECT (pspec)->_default_value;
|
|
|
|
}
|
|
|
|
|
app, libgimp*, pdb: new GimpParamSpecObject abstract spec type.
This abstract spec type is basically a GParamSpecObject with a default
value. It will be used by various object spec with default values, such
as GimpParamSpecColor, GimpParamSpecUnit and all GimpParamSpecResource
subtypes. Also it has a duplicate() class method so that every spec type
can implement the proper way to duplicate itself.
This fixes the fact that in gimp_config_param_spec_duplicate(), all
unknown object spec types (because they are implemented in libgimp,
which is invisible to libgimpconfig) are just copied as
GParamSpecObject, hence losing default values and other parameters.
As a second enhancement, it also makes it easier to detect the object
spec types for which we have default value support in
gimp_config_reset_properties().
As a side fix, gimp_param_spec_color() now just always duplicates the
passed default color, making it hence much easier to avoid bugs when
reusing a GeglColor.
2024-09-03 05:38:13 +08:00
|
|
|
/**
|
|
|
|
* gimp_param_spec_object_get_default:
|
|
|
|
* @pspec: a #GObject #GParamSpec
|
|
|
|
*
|
|
|
|
* Get the default object value of the param spec.
|
|
|
|
*
|
2024-09-06 19:38:43 +08:00
|
|
|
* If the @pspec has been registered with a specific default (which can
|
|
|
|
* be verified with [func@Gimp.ParamSpecObject.has_default]), it will be
|
|
|
|
* returned, though some specific subtypes may support returning dynamic
|
|
|
|
* default (e.g. based on context).
|
app, libgimp*, pdb: new GimpParamSpecObject abstract spec type.
This abstract spec type is basically a GParamSpecObject with a default
value. It will be used by various object spec with default values, such
as GimpParamSpecColor, GimpParamSpecUnit and all GimpParamSpecResource
subtypes. Also it has a duplicate() class method so that every spec type
can implement the proper way to duplicate itself.
This fixes the fact that in gimp_config_param_spec_duplicate(), all
unknown object spec types (because they are implemented in libgimp,
which is invisible to libgimpconfig) are just copied as
GParamSpecObject, hence losing default values and other parameters.
As a second enhancement, it also makes it easier to detect the object
spec types for which we have default value support in
gimp_config_reset_properties().
As a side fix, gimp_param_spec_color() now just always duplicates the
passed default color, making it hence much easier to avoid bugs when
reusing a GeglColor.
2024-09-03 05:38:13 +08:00
|
|
|
*
|
|
|
|
* Returns: (transfer none): the default value.
|
|
|
|
*/
|
|
|
|
GObject *
|
2024-09-06 19:38:43 +08:00
|
|
|
gimp_param_spec_object_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-03 05:38:13 +08:00
|
|
|
{
|
|
|
|
g_return_val_if_fail (GIMP_IS_PARAM_SPEC_OBJECT (pspec), NULL);
|
|
|
|
|
2024-09-06 19:38:43 +08:00
|
|
|
return GIMP_PARAM_SPEC_OBJECT_GET_CLASS (pspec)->get_default (pspec);
|
app, libgimp*, pdb: new GimpParamSpecObject abstract spec type.
This abstract spec type is basically a GParamSpecObject with a default
value. It will be used by various object spec with default values, such
as GimpParamSpecColor, GimpParamSpecUnit and all GimpParamSpecResource
subtypes. Also it has a duplicate() class method so that every spec type
can implement the proper way to duplicate itself.
This fixes the fact that in gimp_config_param_spec_duplicate(), all
unknown object spec types (because they are implemented in libgimp,
which is invisible to libgimpconfig) are just copied as
GParamSpecObject, hence losing default values and other parameters.
As a second enhancement, it also makes it easier to detect the object
spec types for which we have default value support in
gimp_config_reset_properties().
As a side fix, gimp_param_spec_color() now just always duplicates the
passed default color, making it hence much easier to avoid bugs when
reusing a GeglColor.
2024-09-03 05:38:13 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* gimp_param_spec_object_set_default:
|
|
|
|
* @pspec: a #GObject #GParamSpec
|
|
|
|
* @default_value: (transfer none) (nullable): a default value.
|
|
|
|
*
|
|
|
|
* Set the default object value of the param spec. This will switch the
|
|
|
|
* `has_default` flag so that [func@Gimp.ParamSpecObject.has_default]
|
|
|
|
* will now return %TRUE.
|
|
|
|
*
|
|
|
|
* A %NULL @default_value still counts as a default (unless the specific
|
|
|
|
* @pspec does not allow %NULL as a default).
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
gimp_param_spec_object_set_default (GParamSpec *pspec,
|
|
|
|
GObject *default_value)
|
|
|
|
{
|
|
|
|
g_return_if_fail (GIMP_IS_PARAM_SPEC_OBJECT (pspec));
|
|
|
|
|
|
|
|
GIMP_PARAM_SPEC_OBJECT (pspec)->_has_default = TRUE;
|
|
|
|
g_set_object (&GIMP_PARAM_SPEC_OBJECT (pspec)->_default_value, default_value);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* gimp_param_spec_object_has_default:
|
|
|
|
* @pspec: a #GObject #GParamSpec
|
|
|
|
*
|
|
|
|
* This function tells whether a default was set, typically with
|
|
|
|
* [func@Gimp.ParamSpecObject.set_default] or any other way. It
|
|
|
|
* does not guarantee that the default is an actual object (it may be
|
|
|
|
* %NULL if valid as a default).
|
|
|
|
*
|
|
|
|
* Returns: whether a default value was set.
|
|
|
|
*/
|
|
|
|
gboolean
|
|
|
|
gimp_param_spec_object_has_default (GParamSpec *pspec)
|
|
|
|
{
|
|
|
|
g_return_val_if_fail (GIMP_IS_PARAM_SPEC_OBJECT (pspec), FALSE);
|
|
|
|
|
|
|
|
return GIMP_PARAM_SPEC_OBJECT (pspec)->_has_default;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* gimp_param_spec_object_duplicate:
|
|
|
|
* @pspec: a [struct@Gimp.ParamSpecObject].
|
|
|
|
*
|
|
|
|
* This function duplicates @pspec appropriately, depending on the
|
|
|
|
* accurate spec type.
|
|
|
|
*
|
|
|
|
* Returns: (transfer floating): a newly created param spec.
|
|
|
|
*/
|
|
|
|
GParamSpec *
|
|
|
|
gimp_param_spec_object_duplicate (GParamSpec *pspec)
|
|
|
|
{
|
|
|
|
g_return_val_if_fail (GIMP_IS_PARAM_SPEC_OBJECT (pspec), NULL);
|
|
|
|
|
|
|
|
return GIMP_PARAM_SPEC_OBJECT_GET_CLASS (pspec)->duplicate (pspec);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2025-01-23 00:15:28 +08:00
|
|
|
/*
|
|
|
|
* GIMP_TYPE_PARAM_FILE
|
|
|
|
*/
|
|
|
|
|
2025-01-25 06:42:20 +08:00
|
|
|
#define GIMP_PARAM_SPEC_FILE(pspec) (G_TYPE_CHECK_INSTANCE_CAST ((pspec), GIMP_TYPE_PARAM_FILE, GimpParamSpecFile))
|
|
|
|
|
|
|
|
typedef struct _GimpParamSpecFile GimpParamSpecFile;
|
|
|
|
|
|
|
|
struct _GimpParamSpecFile
|
|
|
|
{
|
|
|
|
GimpParamSpecObject parent_instance;
|
|
|
|
|
|
|
|
/*< private >*/
|
|
|
|
GimpFileChooserAction action;
|
|
|
|
gboolean none_ok;
|
|
|
|
};
|
|
|
|
|
2025-01-23 00:15:28 +08:00
|
|
|
static void gimp_param_file_class_init (GimpParamSpecObjectClass *klass);
|
|
|
|
static void gimp_param_file_init (GimpParamSpecFile *fspec);
|
|
|
|
|
|
|
|
static gboolean gimp_param_spec_file_validate (GParamSpec *pspec,
|
|
|
|
GValue *value);
|
2025-01-24 06:27:48 +08:00
|
|
|
static gint gimp_param_spec_file_cmp (GParamSpec *pspec,
|
|
|
|
const GValue *value1,
|
|
|
|
const GValue *value2);
|
2025-01-23 00:15:28 +08:00
|
|
|
static GParamSpec * gimp_param_spec_file_duplicate (GParamSpec *pspec);
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* gimp_param_file_get_type:
|
|
|
|
*
|
|
|
|
* Reveals the object type
|
|
|
|
*
|
|
|
|
* Returns: the #GType for a file param object.
|
|
|
|
*
|
|
|
|
* Since: 3.0
|
|
|
|
**/
|
|
|
|
GType
|
|
|
|
gimp_param_file_get_type (void)
|
|
|
|
{
|
|
|
|
static GType type = 0;
|
|
|
|
|
|
|
|
if (! type)
|
|
|
|
{
|
|
|
|
const GTypeInfo info =
|
|
|
|
{
|
|
|
|
sizeof (GimpParamSpecObjectClass),
|
|
|
|
NULL, NULL,
|
|
|
|
(GClassInitFunc) gimp_param_file_class_init,
|
|
|
|
NULL, NULL,
|
|
|
|
sizeof (GimpParamSpecFile),
|
|
|
|
0,
|
|
|
|
(GInstanceInitFunc) gimp_param_file_init
|
|
|
|
};
|
|
|
|
|
|
|
|
type = g_type_register_static (GIMP_TYPE_PARAM_OBJECT,
|
|
|
|
"GimpParamFile", &info, 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
return type;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
gimp_param_file_class_init (GimpParamSpecObjectClass *klass)
|
|
|
|
{
|
|
|
|
GParamSpecClass *pclass = G_PARAM_SPEC_CLASS (klass);
|
|
|
|
GimpParamSpecObjectClass *oclass = GIMP_PARAM_SPEC_OBJECT_CLASS (klass);
|
|
|
|
|
|
|
|
pclass->value_type = G_TYPE_FILE;
|
|
|
|
pclass->value_validate = gimp_param_spec_file_validate;
|
2025-01-24 06:27:48 +08:00
|
|
|
pclass->values_cmp = gimp_param_spec_file_cmp;
|
2025-01-23 00:15:28 +08:00
|
|
|
oclass->duplicate = gimp_param_spec_file_duplicate;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
gimp_param_file_init (GimpParamSpecFile *fspec)
|
|
|
|
{
|
|
|
|
fspec->none_ok = TRUE;
|
|
|
|
fspec->action = GIMP_FILE_CHOOSER_ACTION_OPEN;
|
|
|
|
}
|
|
|
|
|
|
|
|
static gboolean
|
|
|
|
gimp_param_spec_file_validate (GParamSpec *pspec,
|
|
|
|
GValue *value)
|
|
|
|
{
|
|
|
|
GimpParamSpecFile *fspec = GIMP_PARAM_SPEC_FILE (pspec);
|
|
|
|
GimpParamSpecObject *ospec = GIMP_PARAM_SPEC_OBJECT (pspec);
|
|
|
|
GFile *file = value->data[0].v_pointer;
|
|
|
|
gboolean modifying = FALSE;
|
|
|
|
|
|
|
|
if (file == NULL && ! fspec->none_ok && ospec->_default_value != NULL)
|
|
|
|
{
|
|
|
|
modifying = TRUE;
|
|
|
|
}
|
app, libgimpbase: do not try to open a non existing file.
Now that GimpParamSpecFile makes file validation depending on the action
set in the param spec, when trying to open a non-existing file (which
can happen through GUI, for instance when opening through the Document
History dockable or Open Recent menu), we had a quite obscure error
about a value "out of range" used "for argument 'file' (#2, type
GFile)", which is because core tried to set the GFile for a non-existing
file into the second parameter of the plug-in PDB. This is not a very
nice error for end-users.
The old error was much nicer as it used to say things like:
> Could not open '/path/not/existing.png' for reading: No such file or directory
But in fact, this string came from the plug-in, which means:
* first that the error can be different depending on the format
(inconsistency of error message);
* depending on bugs in plug-ins, it may just crash or return no error
messages;
* finally we were making a useless call to a load plug-in while we
should already know from core that it won't work.
The new message is something like:
> Error when getting information for file "/path/not/existing.png: No such file or directory
This error is generated by core, so it will always be consistently the
same, is understandable too and the plug-in won't even be called.
As a side related fix, I updated the GimpParamSpecFile validation to
only validate local files, just like we do in core. Remote files can
always be set (and we let plug-ins handle them), at least for the time
being.
2025-01-24 00:50:05 +08:00
|
|
|
else if (file != NULL && g_file_is_native (file))
|
2025-01-23 00:15:28 +08:00
|
|
|
{
|
|
|
|
gboolean exists = g_file_query_exists (file, NULL);
|
|
|
|
GFileType type = g_file_query_file_type (file, G_FILE_QUERY_INFO_NONE, NULL);
|
|
|
|
|
|
|
|
switch (fspec->action)
|
|
|
|
{
|
|
|
|
case GIMP_FILE_CHOOSER_ACTION_OPEN:
|
|
|
|
modifying = (! exists || type != G_FILE_TYPE_REGULAR);
|
|
|
|
break;
|
|
|
|
case GIMP_FILE_CHOOSER_ACTION_SAVE:
|
|
|
|
modifying = (exists && type != G_FILE_TYPE_REGULAR);
|
|
|
|
break;
|
|
|
|
case GIMP_FILE_CHOOSER_ACTION_SELECT_FOLDER:
|
|
|
|
modifying = (! exists || type != G_FILE_TYPE_DIRECTORY);
|
|
|
|
break;
|
|
|
|
case GIMP_FILE_CHOOSER_ACTION_CREATE_FOLDER:
|
|
|
|
modifying = (exists && type != G_FILE_TYPE_DIRECTORY);
|
|
|
|
break;
|
|
|
|
case GIMP_FILE_CHOOSER_ACTION_ANY:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (modifying)
|
|
|
|
{
|
|
|
|
g_clear_object (&file);
|
|
|
|
value->data[0].v_pointer = ospec->_default_value ? g_object_ref (ospec->_default_value) : NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return modifying;
|
|
|
|
}
|
|
|
|
|
2025-01-24 06:27:48 +08:00
|
|
|
static gint
|
|
|
|
gimp_param_spec_file_cmp (GParamSpec *pspec,
|
|
|
|
const GValue *value1,
|
|
|
|
const GValue *value2)
|
|
|
|
{
|
|
|
|
GFile *file1 = g_value_get_object (value1);
|
|
|
|
GFile *file2 = g_value_get_object (value2);
|
|
|
|
gchar *uri1;
|
|
|
|
gchar *uri2;
|
|
|
|
gint retval;
|
|
|
|
|
|
|
|
if (! file1 || ! file2)
|
|
|
|
return file2 ? -1 : (file1 ? 1 : 0);
|
|
|
|
|
|
|
|
uri1 = g_file_get_uri (file1);
|
|
|
|
uri2 = g_file_get_uri (file2);
|
|
|
|
|
|
|
|
retval = g_strcmp0 (uri1, uri2);
|
|
|
|
|
|
|
|
g_free (uri1);
|
|
|
|
g_free (uri2);
|
|
|
|
|
|
|
|
return retval;
|
|
|
|
}
|
|
|
|
|
2025-01-23 00:15:28 +08:00
|
|
|
static GParamSpec *
|
|
|
|
gimp_param_spec_file_duplicate (GParamSpec *pspec)
|
|
|
|
{
|
|
|
|
GimpParamSpecObject *ospec;
|
|
|
|
GimpParamSpecFile *fspec;
|
|
|
|
GParamSpec *duplicate;
|
|
|
|
|
|
|
|
g_return_val_if_fail (GIMP_IS_PARAM_SPEC_FILE (pspec), NULL);
|
|
|
|
|
|
|
|
ospec = GIMP_PARAM_SPEC_OBJECT (pspec);
|
|
|
|
fspec = GIMP_PARAM_SPEC_FILE (pspec);
|
|
|
|
duplicate = gimp_param_spec_file (pspec->name,
|
|
|
|
g_param_spec_get_nick (pspec),
|
|
|
|
g_param_spec_get_blurb (pspec),
|
|
|
|
fspec->action, fspec->none_ok,
|
|
|
|
G_FILE (ospec->_default_value),
|
|
|
|
pspec->flags);
|
|
|
|
return duplicate;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* gimp_param_spec_file:
|
|
|
|
* @name: Canonical name of the param
|
|
|
|
* @nick: Nickname of the param
|
|
|
|
* @blurb: Brief description of param.
|
|
|
|
* @action: The type of file to expect.
|
|
|
|
* @none_ok: Whether %NULL is allowed.
|
|
|
|
* @default_value: (nullable): File to use if none is assigned.
|
|
|
|
* @flags: a combination of #GParamFlags
|
|
|
|
*
|
|
|
|
* Creates a param spec to hold a file param.
|
|
|
|
* See g_param_spec_internal() for more information.
|
|
|
|
*
|
|
|
|
* Returns: (transfer full): a newly allocated #GParamSpec instance
|
|
|
|
*
|
|
|
|
* Since: 3.0
|
|
|
|
**/
|
|
|
|
GParamSpec *
|
|
|
|
gimp_param_spec_file (const gchar *name,
|
|
|
|
const gchar *nick,
|
|
|
|
const gchar *blurb,
|
|
|
|
GimpFileChooserAction action,
|
|
|
|
gboolean none_ok,
|
|
|
|
GFile *default_value,
|
|
|
|
GParamFlags flags)
|
|
|
|
{
|
|
|
|
GimpParamSpecFile *fspec;
|
|
|
|
GimpParamSpecObject *ospec;
|
|
|
|
|
|
|
|
g_return_val_if_fail (default_value == NULL || G_IS_FILE (default_value), NULL);
|
|
|
|
|
|
|
|
fspec = g_param_spec_internal (GIMP_TYPE_PARAM_FILE,
|
|
|
|
name, nick, blurb, flags);
|
|
|
|
|
|
|
|
g_return_val_if_fail (fspec, NULL);
|
|
|
|
|
|
|
|
fspec->action = action;
|
|
|
|
fspec->none_ok = none_ok;
|
|
|
|
|
|
|
|
ospec = GIMP_PARAM_SPEC_OBJECT (fspec);
|
|
|
|
ospec->_has_default = TRUE;
|
|
|
|
/* Note that we don't check none_ok and allows even NULL as default
|
|
|
|
* value. What we won't allow will be trying to set a NULL value
|
|
|
|
* later.
|
|
|
|
*/
|
|
|
|
ospec->_default_value = default_value ? g_object_ref (G_OBJECT (default_value)) : NULL;
|
|
|
|
|
|
|
|
return G_PARAM_SPEC (fspec);
|
|
|
|
}
|
|
|
|
|
2025-01-25 06:42:20 +08:00
|
|
|
/**
|
|
|
|
* gimp_param_spec_file_get_action:
|
|
|
|
* @pspec: a #GParamSpec to hold a #GFile value.
|
|
|
|
*
|
|
|
|
* Returns: the file action tied to @pspec.
|
|
|
|
*
|
|
|
|
* Since: 3.0
|
|
|
|
**/
|
|
|
|
GimpFileChooserAction
|
|
|
|
gimp_param_spec_file_get_action (GParamSpec *pspec)
|
|
|
|
{
|
|
|
|
g_return_val_if_fail (GIMP_IS_PARAM_SPEC_FILE (pspec), GIMP_FILE_CHOOSER_ACTION_ANY);
|
|
|
|
|
|
|
|
return GIMP_PARAM_SPEC_FILE (pspec)->action;
|
|
|
|
}
|
|
|
|
|
2025-01-27 00:32:58 +08:00
|
|
|
/**
|
|
|
|
* gimp_param_spec_file_set_action:
|
|
|
|
* @pspec: a #GParamSpec to hold a #GFile value.
|
|
|
|
* @action: new action for @pspec.
|
|
|
|
*
|
|
|
|
* Change the file action tied to @pspec.
|
|
|
|
*
|
|
|
|
* Since: 3.0
|
|
|
|
**/
|
|
|
|
void
|
|
|
|
gimp_param_spec_file_set_action (GParamSpec *pspec,
|
|
|
|
GimpFileChooserAction action)
|
|
|
|
{
|
|
|
|
g_return_if_fail (GIMP_IS_PARAM_SPEC_FILE (pspec));
|
|
|
|
|
|
|
|
GIMP_PARAM_SPEC_FILE (pspec)->action = action;
|
|
|
|
}
|
|
|
|
|
2025-01-25 06:42:20 +08:00
|
|
|
/**
|
|
|
|
* gimp_param_spec_file_none_allowed:
|
|
|
|
* @pspec: a #GParamSpec to hold a #GFile value.
|
|
|
|
*
|
|
|
|
* Returns: %TRUE if a %NULL value is allowed.
|
|
|
|
*
|
|
|
|
* Since: 3.0
|
|
|
|
**/
|
|
|
|
gboolean
|
|
|
|
gimp_param_spec_file_none_allowed (GParamSpec *pspec)
|
|
|
|
{
|
|
|
|
g_return_val_if_fail (GIMP_IS_PARAM_SPEC_FILE (pspec), FALSE);
|
|
|
|
|
|
|
|
return GIMP_PARAM_SPEC_FILE (pspec)->none_ok;
|
|
|
|
}
|
2025-01-23 00:15:28 +08:00
|
|
|
|
2019-07-26 21:54:33 +08:00
|
|
|
/*
|
|
|
|
* GIMP_TYPE_ARRAY
|
|
|
|
*/
|
|
|
|
|
2020-05-05 03:29:42 +08:00
|
|
|
/**
|
|
|
|
* gimp_array_new:
|
|
|
|
* @data: (array length=length):
|
|
|
|
* @length:
|
|
|
|
* @static_data:
|
|
|
|
*/
|
2019-07-26 21:54:33 +08:00
|
|
|
GimpArray *
|
|
|
|
gimp_array_new (const guint8 *data,
|
|
|
|
gsize length,
|
|
|
|
gboolean static_data)
|
|
|
|
{
|
|
|
|
GimpArray *array;
|
|
|
|
|
|
|
|
g_return_val_if_fail ((data == NULL && length == 0) ||
|
|
|
|
(data != NULL && length > 0), NULL);
|
|
|
|
|
|
|
|
array = g_slice_new0 (GimpArray);
|
|
|
|
|
2021-08-26 23:18:32 +08:00
|
|
|
array->data = static_data ? (guint8 *) data : g_memdup2 (data, length);
|
2019-07-26 21:54:33 +08:00
|
|
|
array->length = length;
|
|
|
|
array->static_data = static_data;
|
|
|
|
|
|
|
|
return array;
|
|
|
|
}
|
|
|
|
|
|
|
|
GimpArray *
|
|
|
|
gimp_array_copy (const GimpArray *array)
|
|
|
|
{
|
|
|
|
if (array)
|
|
|
|
return gimp_array_new (array->data, array->length, FALSE);
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
gimp_array_free (GimpArray *array)
|
|
|
|
{
|
|
|
|
if (array)
|
|
|
|
{
|
|
|
|
if (! array->static_data)
|
|
|
|
g_free (array->data);
|
|
|
|
|
|
|
|
g_slice_free (GimpArray, array);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-07-17 13:02:04 +08:00
|
|
|
G_DEFINE_BOXED_TYPE (GimpArray, gimp_array, gimp_array_copy, gimp_array_free)
|
2019-07-26 21:54:33 +08:00
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* GIMP_TYPE_PARAM_ARRAY
|
|
|
|
*/
|
|
|
|
|
|
|
|
static void gimp_param_array_class_init (GParamSpecClass *klass);
|
|
|
|
static void gimp_param_array_init (GParamSpec *pspec);
|
|
|
|
static gboolean gimp_param_array_validate (GParamSpec *pspec,
|
|
|
|
GValue *value);
|
|
|
|
static gint gimp_param_array_values_cmp (GParamSpec *pspec,
|
|
|
|
const GValue *value1,
|
|
|
|
const GValue *value2);
|
|
|
|
|
|
|
|
GType
|
|
|
|
gimp_param_array_get_type (void)
|
|
|
|
{
|
|
|
|
static GType type = 0;
|
|
|
|
|
|
|
|
if (! type)
|
|
|
|
{
|
|
|
|
const GTypeInfo info =
|
|
|
|
{
|
|
|
|
sizeof (GParamSpecClass),
|
|
|
|
NULL, NULL,
|
|
|
|
(GClassInitFunc) gimp_param_array_class_init,
|
|
|
|
NULL, NULL,
|
2024-11-02 06:26:34 +08:00
|
|
|
sizeof (GParamSpecBoxed),
|
2019-07-26 21:54:33 +08:00
|
|
|
0,
|
|
|
|
(GInstanceInitFunc) gimp_param_array_init
|
|
|
|
};
|
|
|
|
|
|
|
|
type = g_type_register_static (G_TYPE_PARAM_BOXED,
|
|
|
|
"GimpParamArray", &info, 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
return type;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
gimp_param_array_class_init (GParamSpecClass *klass)
|
|
|
|
{
|
|
|
|
klass->value_type = GIMP_TYPE_ARRAY;
|
|
|
|
klass->value_validate = gimp_param_array_validate;
|
|
|
|
klass->values_cmp = gimp_param_array_values_cmp;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
gimp_param_array_init (GParamSpec *pspec)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
static gboolean
|
|
|
|
gimp_param_array_validate (GParamSpec *pspec,
|
|
|
|
GValue *value)
|
|
|
|
{
|
|
|
|
GimpArray *array = value->data[0].v_pointer;
|
|
|
|
|
|
|
|
if (array)
|
|
|
|
{
|
|
|
|
if ((array->data == NULL && array->length != 0) ||
|
|
|
|
(array->data != NULL && array->length == 0))
|
|
|
|
{
|
|
|
|
g_value_set_boxed (value, NULL);
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
static gint
|
|
|
|
gimp_param_array_values_cmp (GParamSpec *pspec,
|
|
|
|
const GValue *value1,
|
|
|
|
const GValue *value2)
|
|
|
|
{
|
|
|
|
GimpArray *array1 = value1->data[0].v_pointer;
|
|
|
|
GimpArray *array2 = value2->data[0].v_pointer;
|
|
|
|
|
|
|
|
/* try to return at least *something*, it's useless anyway... */
|
|
|
|
|
|
|
|
if (! array1)
|
|
|
|
return array2 != NULL ? -1 : 0;
|
|
|
|
else if (! array2)
|
|
|
|
return array1 != NULL ? 1 : 0;
|
|
|
|
else if (array1->length < array2->length)
|
|
|
|
return -1;
|
|
|
|
else if (array1->length > array2->length)
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-08-05 21:22:08 +08:00
|
|
|
/**
|
|
|
|
* gimp_param_spec_array:
|
2019-08-05 21:44:40 +08:00
|
|
|
* @name: Canonical name of the property specified.
|
|
|
|
* @nick: Nick name of the property specified.
|
|
|
|
* @blurb: Description of the property specified.
|
|
|
|
* @flags: Flags for the property specified.
|
2019-08-05 21:22:08 +08:00
|
|
|
*
|
2019-08-05 21:44:40 +08:00
|
|
|
* Creates a new #GimpParamSpecArray specifying a
|
2023-07-29 18:36:21 +08:00
|
|
|
* [type@Array] property.
|
2019-08-05 21:22:08 +08:00
|
|
|
*
|
2019-08-05 21:44:40 +08:00
|
|
|
* See g_param_spec_internal() for details on property names.
|
|
|
|
*
|
2024-09-06 22:40:40 +08:00
|
|
|
* Returns: (transfer floating): The newly created #GimpParamSpecArray.
|
2019-08-05 21:44:40 +08:00
|
|
|
*
|
|
|
|
* Since: 3.0
|
|
|
|
**/
|
2019-07-26 21:54:33 +08:00
|
|
|
GParamSpec *
|
|
|
|
gimp_param_spec_array (const gchar *name,
|
|
|
|
const gchar *nick,
|
|
|
|
const gchar *blurb,
|
|
|
|
GParamFlags flags)
|
|
|
|
{
|
2024-11-02 06:26:34 +08:00
|
|
|
GParamSpec *array_spec;
|
2019-07-26 21:54:33 +08:00
|
|
|
|
|
|
|
array_spec = g_param_spec_internal (GIMP_TYPE_PARAM_ARRAY,
|
|
|
|
name, nick, blurb, flags);
|
|
|
|
|
2024-11-02 06:26:34 +08:00
|
|
|
return array_spec;
|
2019-07-26 21:54:33 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static const guint8 *
|
|
|
|
gimp_value_get_array (const GValue *value)
|
|
|
|
{
|
|
|
|
GimpArray *array = value->data[0].v_pointer;
|
|
|
|
|
|
|
|
if (array)
|
|
|
|
return array->data;
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static guint8 *
|
|
|
|
gimp_value_dup_array (const GValue *value)
|
|
|
|
{
|
|
|
|
GimpArray *array = value->data[0].v_pointer;
|
|
|
|
|
|
|
|
if (array)
|
2021-08-26 23:18:32 +08:00
|
|
|
return g_memdup2 (array->data, array->length);
|
2019-07-26 21:54:33 +08:00
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
gimp_value_set_array (GValue *value,
|
|
|
|
const guint8 *data,
|
|
|
|
gsize length)
|
|
|
|
{
|
|
|
|
GimpArray *array = gimp_array_new (data, length, FALSE);
|
|
|
|
|
|
|
|
g_value_take_boxed (value, array);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
gimp_value_set_static_array (GValue *value,
|
|
|
|
const guint8 *data,
|
|
|
|
gsize length)
|
|
|
|
{
|
|
|
|
GimpArray *array = gimp_array_new (data, length, TRUE);
|
|
|
|
|
|
|
|
g_value_take_boxed (value, array);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
gimp_value_take_array (GValue *value,
|
|
|
|
guint8 *data,
|
|
|
|
gsize length)
|
|
|
|
{
|
|
|
|
GimpArray *array = gimp_array_new (data, length, TRUE);
|
|
|
|
|
|
|
|
array->static_data = FALSE;
|
|
|
|
|
|
|
|
g_value_take_boxed (value, array);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* GIMP_TYPE_INT32_ARRAY
|
|
|
|
*/
|
|
|
|
|
2019-07-17 13:02:04 +08:00
|
|
|
typedef GimpArray GimpInt32Array;
|
|
|
|
G_DEFINE_BOXED_TYPE (GimpInt32Array, gimp_int32_array, gimp_array_copy, gimp_array_free)
|
2019-07-26 21:54:33 +08:00
|
|
|
|
2024-10-24 23:43:09 +08:00
|
|
|
/**
|
|
|
|
* gimp_int32_array_get_values:
|
|
|
|
* @array: the #GimpArray representing #int32 values.
|
|
|
|
* @length: the number of #int32 values in the returned array.
|
|
|
|
*
|
|
|
|
* Returns: (array length=length) (transfer none): a C-array of #gint32.
|
|
|
|
*/
|
|
|
|
const gint32 *
|
|
|
|
gimp_int32_array_get_values (GimpArray *array,
|
|
|
|
gsize *length)
|
|
|
|
{
|
|
|
|
g_return_val_if_fail (array->length % sizeof (gint32) == 0, NULL);
|
|
|
|
|
|
|
|
if (length)
|
|
|
|
*length = array->length / sizeof (gint32);
|
|
|
|
|
|
|
|
return (const gint32 *) array->data;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* gimp_int32_array_set_values:
|
|
|
|
* @array: the array to modify.
|
|
|
|
* @values: (array length=length): the C-array.
|
|
|
|
* @length: the number of #int32 values in @data.
|
|
|
|
* @static_data: whether @data is a static rather than allocated array.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
gimp_int32_array_set_values (GimpArray *array,
|
|
|
|
const gint32 *values,
|
|
|
|
gsize length,
|
|
|
|
gboolean static_data)
|
|
|
|
{
|
|
|
|
g_return_if_fail ((values == NULL && length == 0) || (values != NULL && length > 0));
|
|
|
|
|
|
|
|
if (! array->static_data)
|
|
|
|
g_free (array->data);
|
|
|
|
|
|
|
|
array->length = length * sizeof (gint32);
|
|
|
|
array->data = static_data ? (guint8 *) values : g_memdup2 (values, array->length);
|
|
|
|
array->static_data = static_data;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2019-07-26 21:54:33 +08:00
|
|
|
/*
|
|
|
|
* GIMP_TYPE_PARAM_INT32_ARRAY
|
|
|
|
*/
|
|
|
|
|
|
|
|
static void gimp_param_int32_array_class_init (GParamSpecClass *klass);
|
|
|
|
static void gimp_param_int32_array_init (GParamSpec *pspec);
|
|
|
|
|
|
|
|
GType
|
|
|
|
gimp_param_int32_array_get_type (void)
|
|
|
|
{
|
|
|
|
static GType type = 0;
|
|
|
|
|
|
|
|
if (! type)
|
|
|
|
{
|
|
|
|
const GTypeInfo info =
|
|
|
|
{
|
|
|
|
sizeof (GParamSpecClass),
|
|
|
|
NULL, NULL,
|
|
|
|
(GClassInitFunc) gimp_param_int32_array_class_init,
|
|
|
|
NULL, NULL,
|
2024-11-02 06:26:34 +08:00
|
|
|
sizeof (GParamSpecBoxed),
|
2019-07-26 21:54:33 +08:00
|
|
|
0,
|
|
|
|
(GInstanceInitFunc) gimp_param_int32_array_init
|
|
|
|
};
|
|
|
|
|
|
|
|
type = g_type_register_static (GIMP_TYPE_PARAM_ARRAY,
|
|
|
|
"GimpParamInt32Array", &info, 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
return type;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
gimp_param_int32_array_class_init (GParamSpecClass *klass)
|
|
|
|
{
|
|
|
|
klass->value_type = GIMP_TYPE_INT32_ARRAY;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
gimp_param_int32_array_init (GParamSpec *pspec)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2019-08-05 21:22:08 +08:00
|
|
|
/**
|
|
|
|
* gimp_param_spec_int32_array:
|
2019-08-05 21:44:40 +08:00
|
|
|
* @name: Canonical name of the property specified.
|
|
|
|
* @nick: Nick name of the property specified.
|
|
|
|
* @blurb: Description of the property specified.
|
|
|
|
* @flags: Flags for the property specified.
|
2019-08-05 21:22:08 +08:00
|
|
|
*
|
2019-08-05 21:44:40 +08:00
|
|
|
* Creates a new #GimpParamSpecInt32Array specifying a
|
2023-07-29 18:36:21 +08:00
|
|
|
* %GIMP_TYPE_INT32_ARRAY property.
|
2019-08-05 21:22:08 +08:00
|
|
|
*
|
2019-08-05 21:44:40 +08:00
|
|
|
* See g_param_spec_internal() for details on property names.
|
|
|
|
*
|
2024-09-06 22:40:40 +08:00
|
|
|
* Returns: (transfer floating): The newly created #GimpParamSpecInt32Array.
|
2019-08-05 21:44:40 +08:00
|
|
|
*
|
|
|
|
* Since: 3.0
|
|
|
|
**/
|
2019-07-26 21:54:33 +08:00
|
|
|
GParamSpec *
|
|
|
|
gimp_param_spec_int32_array (const gchar *name,
|
|
|
|
const gchar *nick,
|
|
|
|
const gchar *blurb,
|
|
|
|
GParamFlags flags)
|
|
|
|
{
|
2024-11-02 06:26:34 +08:00
|
|
|
GParamSpec *array_spec;
|
2019-07-26 21:54:33 +08:00
|
|
|
|
|
|
|
array_spec = g_param_spec_internal (GIMP_TYPE_PARAM_INT32_ARRAY,
|
|
|
|
name, nick, blurb, flags);
|
|
|
|
|
2024-11-02 06:26:34 +08:00
|
|
|
return array_spec;
|
2019-07-26 21:54:33 +08:00
|
|
|
}
|
|
|
|
|
2020-06-06 19:22:57 +08:00
|
|
|
/**
|
|
|
|
* gimp_value_get_int32_array:
|
|
|
|
* @value: A valid value of type %GIMP_TYPE_INT32_ARRAY
|
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 15:48:14 +08:00
|
|
|
* @length: the number of returned #int32 elements.
|
2020-06-06 19:22:57 +08:00
|
|
|
*
|
|
|
|
* Gets the contents of a %GIMP_TYPE_INT32_ARRAY #GValue
|
|
|
|
*
|
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 15:48:14 +08:00
|
|
|
* Returns: (transfer none) (array length=length): The contents of @value
|
2020-06-06 19:22:57 +08:00
|
|
|
*/
|
2019-07-26 21:54:33 +08:00
|
|
|
const gint32 *
|
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 15:48:14 +08:00
|
|
|
gimp_value_get_int32_array (const GValue *value,
|
|
|
|
gsize *length)
|
2019-07-26 21:54:33 +08:00
|
|
|
{
|
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 15:48:14 +08:00
|
|
|
GimpArray *array;
|
|
|
|
|
2019-07-26 21:54:33 +08:00
|
|
|
g_return_val_if_fail (GIMP_VALUE_HOLDS_INT32_ARRAY (value), NULL);
|
|
|
|
|
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 15:48:14 +08:00
|
|
|
array = value->data[0].v_pointer;
|
|
|
|
|
|
|
|
g_return_val_if_fail (array->length % sizeof (gint32) == 0, NULL);
|
|
|
|
|
|
|
|
if (length)
|
|
|
|
*length = array->length / sizeof (gint32);
|
|
|
|
|
2019-07-26 21:54:33 +08:00
|
|
|
return (const gint32 *) gimp_value_get_array (value);
|
|
|
|
}
|
|
|
|
|
2020-06-06 19:22:57 +08:00
|
|
|
/**
|
|
|
|
* gimp_value_dup_int32_array:
|
|
|
|
* @value: A valid value of type %GIMP_TYPE_INT32_ARRAY
|
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 15:48:14 +08:00
|
|
|
* @length: the number of returned #int32 elements.
|
2020-06-06 19:22:57 +08:00
|
|
|
*
|
|
|
|
* Gets the contents of a %GIMP_TYPE_INT32_ARRAY #GValue
|
|
|
|
*
|
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 15:48:14 +08:00
|
|
|
* Returns: (transfer full) (array length=length): The contents of @value
|
2020-06-06 19:22:57 +08:00
|
|
|
*/
|
2019-07-26 21:54:33 +08:00
|
|
|
gint32 *
|
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 15:48:14 +08:00
|
|
|
gimp_value_dup_int32_array (const GValue *value,
|
|
|
|
gsize *length)
|
2019-07-26 21:54:33 +08:00
|
|
|
{
|
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 15:48:14 +08:00
|
|
|
GimpArray *array;
|
|
|
|
|
2019-07-26 21:54:33 +08:00
|
|
|
g_return_val_if_fail (GIMP_VALUE_HOLDS_INT32_ARRAY (value), NULL);
|
|
|
|
|
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 15:48:14 +08:00
|
|
|
array = value->data[0].v_pointer;
|
|
|
|
|
|
|
|
g_return_val_if_fail (array->length % sizeof (gint32) == 0, NULL);
|
|
|
|
|
|
|
|
if (length)
|
|
|
|
*length = array->length / sizeof (gint32);
|
|
|
|
|
2019-07-26 21:54:33 +08:00
|
|
|
return (gint32 *) gimp_value_dup_array (value);
|
|
|
|
}
|
|
|
|
|
2020-06-06 19:22:57 +08:00
|
|
|
/**
|
|
|
|
* gimp_value_set_int32_array:
|
|
|
|
* @value: A valid value of type %GIMP_TYPE_INT32_ARRAY
|
|
|
|
* @data: (array length=length): A #gint32 array
|
|
|
|
* @length: The number of elements in @data
|
|
|
|
*
|
|
|
|
* Sets the contents of @value to @data.
|
|
|
|
*/
|
2019-07-26 21:54:33 +08:00
|
|
|
void
|
|
|
|
gimp_value_set_int32_array (GValue *value,
|
|
|
|
const gint32 *data,
|
|
|
|
gsize length)
|
|
|
|
{
|
|
|
|
g_return_if_fail (GIMP_VALUE_HOLDS_INT32_ARRAY (value));
|
|
|
|
|
|
|
|
gimp_value_set_array (value, (const guint8 *) data,
|
|
|
|
length * sizeof (gint32));
|
|
|
|
}
|
|
|
|
|
2020-06-06 19:22:57 +08:00
|
|
|
/**
|
|
|
|
* gimp_value_set_static_int32_array:
|
|
|
|
* @value: A valid value of type %GIMP_TYPE_INT32_ARRAY
|
|
|
|
* @data: (array length=length): A #gint32 array
|
|
|
|
* @length: The number of elements in @data
|
|
|
|
*
|
|
|
|
* Sets the contents of @value to @data, without copying the data.
|
|
|
|
*/
|
2019-07-26 21:54:33 +08:00
|
|
|
void
|
|
|
|
gimp_value_set_static_int32_array (GValue *value,
|
|
|
|
const gint32 *data,
|
|
|
|
gsize length)
|
|
|
|
{
|
|
|
|
g_return_if_fail (GIMP_VALUE_HOLDS_INT32_ARRAY (value));
|
|
|
|
|
|
|
|
gimp_value_set_static_array (value, (const guint8 *) data,
|
|
|
|
length * sizeof (gint32));
|
|
|
|
}
|
|
|
|
|
2020-06-06 19:22:57 +08:00
|
|
|
/**
|
|
|
|
* gimp_value_take_int32_array:
|
|
|
|
* @value: A valid value of type %GIMP_TYPE_int32_ARRAY
|
|
|
|
* @data: (transfer full) (array length=length): A #gint32 array
|
|
|
|
* @length: The number of elements in @data
|
|
|
|
*
|
|
|
|
* Sets the contents of @value to @data, and takes ownership of @data.
|
|
|
|
*/
|
2019-07-26 21:54:33 +08:00
|
|
|
void
|
|
|
|
gimp_value_take_int32_array (GValue *value,
|
|
|
|
gint32 *data,
|
|
|
|
gsize length)
|
|
|
|
{
|
|
|
|
g_return_if_fail (GIMP_VALUE_HOLDS_INT32_ARRAY (value));
|
|
|
|
|
|
|
|
gimp_value_take_array (value, (guint8 *) data,
|
|
|
|
length * sizeof (gint32));
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
2024-11-02 21:03:37 +08:00
|
|
|
* GIMP_TYPE_DOUBLE_ARRAY
|
2019-07-26 21:54:33 +08:00
|
|
|
*/
|
|
|
|
|
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
2024-11-02 21:03:37 +08:00
|
|
|
typedef GimpArray GimpDoubleArray;
|
|
|
|
G_DEFINE_BOXED_TYPE (GimpDoubleArray, gimp_double_array, gimp_array_copy, gimp_array_free)
|
2019-07-26 21:54:33 +08:00
|
|
|
|
2024-10-25 04:18:20 +08:00
|
|
|
/**
|
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
2024-11-02 21:03:37 +08:00
|
|
|
* gimp_double_array_get_values:
|
|
|
|
* @array: the #GimpArray representing #double values.
|
|
|
|
* @length: the number of #double values in the returned array.
|
2024-10-25 04:18:20 +08:00
|
|
|
*
|
|
|
|
* Returns: (array length=length) (transfer none): a C-array of #gdouble.
|
|
|
|
*/
|
|
|
|
const gdouble *
|
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
2024-11-02 21:03:37 +08:00
|
|
|
gimp_double_array_get_values (GimpArray *array,
|
|
|
|
gsize *length)
|
2024-10-25 04:18:20 +08:00
|
|
|
{
|
|
|
|
g_return_val_if_fail (array->length % sizeof (gdouble) == 0, NULL);
|
|
|
|
|
|
|
|
if (length)
|
|
|
|
*length = array->length / sizeof (gdouble);
|
|
|
|
|
|
|
|
return (const gdouble *) array->data;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
2024-11-02 21:03:37 +08:00
|
|
|
* gimp_double_array_set_values:
|
2024-10-25 04:18:20 +08:00
|
|
|
* @array: the array to modify.
|
|
|
|
* @values: (array length=length): the C-array.
|
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
2024-11-02 21:03:37 +08:00
|
|
|
* @length: the number of #double values in @data.
|
2024-10-25 04:18:20 +08:00
|
|
|
* @static_data: whether @data is a static rather than allocated array.
|
|
|
|
*/
|
|
|
|
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 21:03:37 +08:00
|
|
|
gimp_double_array_set_values (GimpArray *array,
|
|
|
|
const gdouble *values,
|
|
|
|
gsize length,
|
|
|
|
gboolean static_data)
|
2024-10-25 04:18:20 +08:00
|
|
|
{
|
|
|
|
g_return_if_fail ((values == NULL && length == 0) || (values != NULL && length > 0));
|
|
|
|
|
|
|
|
if (! array->static_data)
|
|
|
|
g_free (array->data);
|
|
|
|
|
|
|
|
array->length = length * sizeof (gdouble);
|
|
|
|
array->data = static_data ? (guint8 *) values : g_memdup2 (values, array->length);
|
|
|
|
array->static_data = static_data;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2019-07-26 21:54:33 +08:00
|
|
|
/*
|
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
2024-11-02 21:03:37 +08:00
|
|
|
* GIMP_TYPE_PARAM_DOUBLE_ARRAY
|
2019-07-26 21:54:33 +08:00
|
|
|
*/
|
|
|
|
|
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
2024-11-02 21:03:37 +08:00
|
|
|
static void gimp_param_double_array_class_init (GParamSpecClass *klass);
|
|
|
|
static void gimp_param_double_array_init (GParamSpec *pspec);
|
2019-07-26 21:54:33 +08:00
|
|
|
|
|
|
|
GType
|
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
2024-11-02 21:03:37 +08:00
|
|
|
gimp_param_double_array_get_type (void)
|
2019-07-26 21:54:33 +08:00
|
|
|
{
|
|
|
|
static GType type = 0;
|
|
|
|
|
|
|
|
if (! type)
|
|
|
|
{
|
|
|
|
const GTypeInfo info =
|
|
|
|
{
|
|
|
|
sizeof (GParamSpecClass),
|
|
|
|
NULL, NULL,
|
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
2024-11-02 21:03:37 +08:00
|
|
|
(GClassInitFunc) gimp_param_double_array_class_init,
|
2019-07-26 21:54:33 +08:00
|
|
|
NULL, NULL,
|
2024-11-02 06:26:34 +08:00
|
|
|
sizeof (GParamSpecBoxed),
|
2019-07-26 21:54:33 +08:00
|
|
|
0,
|
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
2024-11-02 21:03:37 +08:00
|
|
|
(GInstanceInitFunc) gimp_param_double_array_init
|
2019-07-26 21:54:33 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
type = g_type_register_static (GIMP_TYPE_PARAM_ARRAY,
|
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
2024-11-02 21:03:37 +08:00
|
|
|
"GimpParamDoubleArray", &info, 0);
|
2019-07-26 21:54:33 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return type;
|
|
|
|
}
|
|
|
|
|
|
|
|
static 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 21:03:37 +08:00
|
|
|
gimp_param_double_array_class_init (GParamSpecClass *klass)
|
2019-07-26 21:54:33 +08:00
|
|
|
{
|
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
2024-11-02 21:03:37 +08:00
|
|
|
klass->value_type = GIMP_TYPE_DOUBLE_ARRAY;
|
2019-07-26 21:54:33 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static 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 21:03:37 +08:00
|
|
|
gimp_param_double_array_init (GParamSpec *pspec)
|
2019-07-26 21:54:33 +08:00
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2019-08-05 21:22:08 +08:00
|
|
|
/**
|
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
2024-11-02 21:03:37 +08:00
|
|
|
* gimp_param_spec_double_array:
|
2019-08-05 21:44:40 +08:00
|
|
|
* @name: Canonical name of the property specified.
|
|
|
|
* @nick: Nick name of the property specified.
|
|
|
|
* @blurb: Description of the property specified.
|
|
|
|
* @flags: Flags for the property specified.
|
2019-08-05 21:22:08 +08:00
|
|
|
*
|
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
2024-11-02 21:03:37 +08:00
|
|
|
* Creates a new #GimpParamSpecDoubleArray specifying a
|
|
|
|
* %GIMP_TYPE_DOUBLE_ARRAY property.
|
2019-08-05 21:22:08 +08:00
|
|
|
*
|
2019-08-05 21:44:40 +08:00
|
|
|
* See g_param_spec_internal() for details on property names.
|
|
|
|
*
|
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
2024-11-02 21:03:37 +08:00
|
|
|
* Returns: (transfer floating): The newly created #GimpParamSpecDoubleArray.
|
2019-08-05 21:44:40 +08:00
|
|
|
*
|
|
|
|
* Since: 3.0
|
|
|
|
**/
|
2019-07-26 21:54:33 +08:00
|
|
|
GParamSpec *
|
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
2024-11-02 21:03:37 +08:00
|
|
|
gimp_param_spec_double_array (const gchar *name,
|
|
|
|
const gchar *nick,
|
|
|
|
const gchar *blurb,
|
|
|
|
GParamFlags flags)
|
2019-07-26 21:54:33 +08:00
|
|
|
{
|
2024-11-02 06:26:34 +08:00
|
|
|
GParamSpec *array_spec;
|
2019-07-26 21:54:33 +08:00
|
|
|
|
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
2024-11-02 21:03:37 +08:00
|
|
|
array_spec = g_param_spec_internal (GIMP_TYPE_PARAM_DOUBLE_ARRAY,
|
2019-07-26 21:54:33 +08:00
|
|
|
name, nick, blurb, flags);
|
|
|
|
|
2024-11-02 06:26:34 +08:00
|
|
|
return array_spec;
|
2019-07-26 21:54:33 +08:00
|
|
|
}
|
|
|
|
|
2020-06-06 19:22:57 +08:00
|
|
|
/**
|
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
2024-11-02 21:03:37 +08:00
|
|
|
* gimp_value_get_double_array:
|
|
|
|
* @value: A valid value of type %GIMP_TYPE_DOUBLE_ARRAY
|
2024-10-25 04:18:20 +08:00
|
|
|
* @length: the number of returned #double elements.
|
2020-06-06 19:22:57 +08:00
|
|
|
*
|
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
2024-11-02 21:03:37 +08:00
|
|
|
* Gets the contents of a %GIMP_TYPE_DOUBLE_ARRAY #GValue
|
2020-06-06 19:22:57 +08:00
|
|
|
*
|
2024-10-25 04:18:20 +08:00
|
|
|
* Returns: (transfer none) (array length=length): The contents of @value
|
2020-06-06 19:22:57 +08:00
|
|
|
*/
|
2019-07-26 21:54:33 +08:00
|
|
|
const gdouble *
|
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
2024-11-02 21:03:37 +08:00
|
|
|
gimp_value_get_double_array (const GValue *value,
|
|
|
|
gsize *length)
|
2019-07-26 21:54:33 +08:00
|
|
|
{
|
2024-10-25 04:18:20 +08:00
|
|
|
GimpArray *array;
|
|
|
|
|
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
2024-11-02 21:03:37 +08:00
|
|
|
g_return_val_if_fail (GIMP_VALUE_HOLDS_DOUBLE_ARRAY (value), NULL);
|
2019-07-26 21:54:33 +08:00
|
|
|
|
2024-10-25 04:18:20 +08:00
|
|
|
array = value->data[0].v_pointer;
|
|
|
|
|
|
|
|
g_return_val_if_fail (array->length % sizeof (gdouble) == 0, NULL);
|
|
|
|
|
|
|
|
if (length)
|
|
|
|
*length = array->length / sizeof (gdouble);
|
|
|
|
|
2019-07-26 21:54:33 +08:00
|
|
|
return (const gdouble *) gimp_value_get_array (value);
|
|
|
|
}
|
|
|
|
|
2020-06-06 19:22:57 +08:00
|
|
|
/**
|
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
2024-11-02 21:03:37 +08:00
|
|
|
* gimp_value_dup_double_array:
|
|
|
|
* @value: A valid value of type %GIMP_TYPE_DOUBLE_ARRAY
|
2024-10-25 04:18:20 +08:00
|
|
|
* @length: the number of returned #double elements.
|
2020-06-06 19:22:57 +08:00
|
|
|
*
|
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
2024-11-02 21:03:37 +08:00
|
|
|
* Gets the contents of a %GIMP_TYPE_DOUBLE_ARRAY #GValue
|
2020-06-06 19:22:57 +08:00
|
|
|
*
|
2024-10-25 04:18:20 +08:00
|
|
|
* Returns: (transfer full) (array length=length): The contents of @value
|
2020-06-06 19:22:57 +08:00
|
|
|
*/
|
2019-07-26 21:54:33 +08:00
|
|
|
gdouble *
|
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
2024-11-02 21:03:37 +08:00
|
|
|
gimp_value_dup_double_array (const GValue *value,
|
|
|
|
gsize *length)
|
2019-07-26 21:54:33 +08:00
|
|
|
{
|
2024-10-25 04:18:20 +08:00
|
|
|
GimpArray *array;
|
|
|
|
|
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
2024-11-02 21:03:37 +08:00
|
|
|
g_return_val_if_fail (GIMP_VALUE_HOLDS_DOUBLE_ARRAY (value), NULL);
|
2019-07-26 21:54:33 +08:00
|
|
|
|
2024-10-25 04:18:20 +08:00
|
|
|
array = value->data[0].v_pointer;
|
|
|
|
|
|
|
|
g_return_val_if_fail (array->length % sizeof (gdouble) == 0, NULL);
|
|
|
|
|
|
|
|
if (length)
|
|
|
|
*length = array->length / sizeof (gdouble);
|
|
|
|
|
2019-07-26 21:54:33 +08:00
|
|
|
return (gdouble *) gimp_value_dup_array (value);
|
|
|
|
}
|
|
|
|
|
2020-06-06 19:22:57 +08:00
|
|
|
/**
|
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
2024-11-02 21:03:37 +08:00
|
|
|
* gimp_value_set_double_array:
|
|
|
|
* @value: A valid value of type %GIMP_TYPE_DOUBLE_ARRAY
|
|
|
|
* @data: (array length=length): A #gdouble array
|
2020-06-06 19:22:57 +08:00
|
|
|
* @length: The number of elements in @data
|
|
|
|
*
|
|
|
|
* Sets the contents of @value to @data.
|
|
|
|
*/
|
2019-07-26 21:54:33 +08:00
|
|
|
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 21:03:37 +08:00
|
|
|
gimp_value_set_double_array (GValue *value,
|
|
|
|
const gdouble *data,
|
|
|
|
gsize length)
|
2019-07-26 21:54:33 +08:00
|
|
|
{
|
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
2024-11-02 21:03:37 +08:00
|
|
|
g_return_if_fail (GIMP_VALUE_HOLDS_DOUBLE_ARRAY (value));
|
2019-07-26 21:54:33 +08:00
|
|
|
|
|
|
|
gimp_value_set_array (value, (const guint8 *) data,
|
|
|
|
length * sizeof (gdouble));
|
|
|
|
}
|
|
|
|
|
2020-06-06 19:22:57 +08:00
|
|
|
/**
|
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
2024-11-02 21:03:37 +08:00
|
|
|
* gimp_value_set_static_double_array:
|
|
|
|
* @value: A valid value of type %GIMP_TYPE_DOUBLE_ARRAY
|
|
|
|
* @data: (array length=length): A #gdouble array
|
2020-06-06 19:22:57 +08:00
|
|
|
* @length: The number of elements in @data
|
|
|
|
*
|
|
|
|
* Sets the contents of @value to @data, without copying the data.
|
|
|
|
*/
|
2019-07-26 21:54:33 +08:00
|
|
|
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 21:03:37 +08:00
|
|
|
gimp_value_set_static_double_array (GValue *value,
|
|
|
|
const gdouble *data,
|
|
|
|
gsize length)
|
2019-07-26 21:54:33 +08:00
|
|
|
{
|
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
2024-11-02 21:03:37 +08:00
|
|
|
g_return_if_fail (GIMP_VALUE_HOLDS_DOUBLE_ARRAY (value));
|
2019-07-26 21:54:33 +08:00
|
|
|
|
|
|
|
gimp_value_set_static_array (value, (const guint8 *) data,
|
|
|
|
length * sizeof (gdouble));
|
|
|
|
}
|
|
|
|
|
2020-06-06 19:22:57 +08:00
|
|
|
/**
|
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
2024-11-02 21:03:37 +08:00
|
|
|
* gimp_value_take_double_array:
|
|
|
|
* @value: A valid value of type %GIMP_TYPE_DOUBLE_ARRAY
|
|
|
|
* @data: (transfer full) (array length=length): A #gdouble array
|
2020-06-06 19:22:57 +08:00
|
|
|
* @length: The number of elements in @data
|
|
|
|
*
|
|
|
|
* Sets the contents of @value to @data, and takes ownership of @data.
|
|
|
|
*/
|
2019-07-26 21:54:33 +08:00
|
|
|
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 21:03:37 +08:00
|
|
|
gimp_value_take_double_array (GValue *value,
|
|
|
|
gdouble *data,
|
|
|
|
gsize length)
|
2019-07-26 21:54:33 +08:00
|
|
|
{
|
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
2024-11-02 21:03:37 +08:00
|
|
|
g_return_if_fail (GIMP_VALUE_HOLDS_DOUBLE_ARRAY (value));
|
2019-07-26 21:54:33 +08:00
|
|
|
|
|
|
|
gimp_value_take_array (value, (guint8 *) data,
|
|
|
|
length * sizeof (gdouble));
|
|
|
|
}
|
|
|
|
|
2023-12-27 00:07:19 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* GIMP_TYPE_COLOR_ARRAY
|
|
|
|
*/
|
|
|
|
|
|
|
|
GType
|
|
|
|
gimp_color_array_get_type (void)
|
|
|
|
{
|
|
|
|
static gsize static_g_define_type_id = 0;
|
|
|
|
|
|
|
|
if (g_once_init_enter (&static_g_define_type_id))
|
|
|
|
{
|
|
|
|
GType g_define_type_id =
|
|
|
|
g_boxed_type_register_static (g_intern_static_string ("GimpColorArray"),
|
|
|
|
(GBoxedCopyFunc) gimp_color_array_copy,
|
|
|
|
(GBoxedFreeFunc) gimp_color_array_free);
|
|
|
|
|
|
|
|
g_once_init_leave (&static_g_define_type_id, g_define_type_id);
|
|
|
|
}
|
|
|
|
|
|
|
|
return static_g_define_type_id;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* gimp_color_array_copy:
|
|
|
|
* @array: an array of colors.
|
|
|
|
*
|
|
|
|
* Creates a new #GimpColorArray containing a deep copy of a %NULL-terminated
|
|
|
|
* array of [class@Gegl.Color].
|
|
|
|
*
|
|
|
|
* Returns: (transfer full): a new #GimpColorArray.
|
|
|
|
**/
|
|
|
|
GimpColorArray
|
|
|
|
gimp_color_array_copy (GimpColorArray array)
|
|
|
|
{
|
|
|
|
GeglColor **copy;
|
|
|
|
gint length = gimp_color_array_get_length (array);
|
|
|
|
|
|
|
|
copy = g_malloc0 (sizeof (GeglColor *) * (length + 1));
|
|
|
|
|
|
|
|
for (gint i = 0; i < length; i++)
|
|
|
|
copy[i] = gegl_color_duplicate (array[i]);
|
|
|
|
|
|
|
|
return copy;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* gimp_color_array_free:
|
|
|
|
* @array: an array of colors.
|
|
|
|
*
|
|
|
|
* Frees a %NULL-terminated array of [class@Gegl.Color].
|
|
|
|
**/
|
|
|
|
void
|
|
|
|
gimp_color_array_free (GimpColorArray array)
|
|
|
|
{
|
|
|
|
gint i = 0;
|
|
|
|
|
|
|
|
while (array[i] != NULL)
|
|
|
|
g_object_unref (array[i++]);
|
|
|
|
|
|
|
|
g_free (array);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* gimp_color_array_get_length:
|
|
|
|
* @array: an array of colors.
|
|
|
|
*
|
|
|
|
* Returns: the number of [class@Gegl.Color] in @array.
|
|
|
|
**/
|
|
|
|
gint
|
|
|
|
gimp_color_array_get_length (GimpColorArray array)
|
|
|
|
{
|
|
|
|
gint length = 0;
|
|
|
|
|
|
|
|
while (array[length] != NULL)
|
|
|
|
length++;
|
|
|
|
|
|
|
|
return length;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2024-10-22 03:59:26 +08:00
|
|
|
/*
|
|
|
|
* GIMP_TYPE_CORE_OBJECT_ARRAY
|
|
|
|
*/
|
|
|
|
|
2024-10-22 05:57:10 +08:00
|
|
|
static GimpCoreObjectArray gimp_core_object_array_copy (GimpCoreObjectArray array);
|
2024-10-22 03:59:26 +08:00
|
|
|
|
|
|
|
GType
|
|
|
|
gimp_core_object_array_get_type (void)
|
|
|
|
{
|
|
|
|
static gsize static_g_define_type_id = 0;
|
|
|
|
|
|
|
|
if (g_once_init_enter (&static_g_define_type_id))
|
|
|
|
{
|
|
|
|
GType g_define_type_id =
|
|
|
|
g_boxed_type_register_static (g_intern_static_string ("GimpCoreObjectArray"),
|
|
|
|
(GBoxedCopyFunc) gimp_core_object_array_copy,
|
|
|
|
(GBoxedFreeFunc) g_free);
|
|
|
|
|
|
|
|
g_once_init_leave (&static_g_define_type_id, g_define_type_id);
|
|
|
|
}
|
|
|
|
|
|
|
|
return static_g_define_type_id;
|
|
|
|
}
|
|
|
|
|
2024-10-22 05:57:10 +08:00
|
|
|
/**
|
|
|
|
* gimp_core_object_array_get_length:
|
|
|
|
* @array: a %NULL-terminated array of objects.
|
|
|
|
*
|
|
|
|
* Returns: the number of [class@GObject.Object] in @array.
|
|
|
|
**/
|
|
|
|
gsize
|
|
|
|
gimp_core_object_array_get_length (GObject **array)
|
|
|
|
{
|
|
|
|
gsize length = 0;
|
|
|
|
|
|
|
|
while (array && array[length] != NULL)
|
|
|
|
length++;
|
|
|
|
|
|
|
|
return length;
|
|
|
|
}
|
|
|
|
|
2024-10-22 03:59:26 +08:00
|
|
|
/**
|
|
|
|
* gimp_core_object_array_copy:
|
|
|
|
* @array: an array of core_objects.
|
|
|
|
*
|
|
|
|
* Duplicate a new #GimpCoreObjectArray, which is basically simply a
|
|
|
|
* %NULL-terminated array of [class@GObject.Object]. Note that you
|
|
|
|
* should only use this alias type for arrays of core type objects
|
|
|
|
* internally hold by `libgimp`, such as layers, channels, paths, images
|
|
|
|
* and so on, because no reference is hold to the element objects.
|
|
|
|
*
|
|
|
|
* As a consequence, the copy also makes a shallow copy of the elements.
|
|
|
|
*
|
|
|
|
* Returns: (transfer container) (array zero-terminated=1): a new #GimpCoreObjectArray.
|
|
|
|
**/
|
|
|
|
static GimpCoreObjectArray
|
|
|
|
gimp_core_object_array_copy (GimpCoreObjectArray array)
|
|
|
|
{
|
|
|
|
GObject **copy;
|
|
|
|
gsize length = gimp_core_object_array_get_length (array);
|
|
|
|
|
|
|
|
copy = g_malloc0 (sizeof (GObject *) * (length + 1));
|
|
|
|
|
|
|
|
for (gint i = 0; i < length; i++)
|
|
|
|
copy[i] = array[i];
|
|
|
|
|
|
|
|
return copy;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* GIMP_TYPE_PARAM_CORE_OBJECT_ARRAY
|
|
|
|
*/
|
|
|
|
|
2025-01-25 07:02:29 +08:00
|
|
|
#define GIMP_PARAM_SPEC_CORE_OBJECT_ARRAY(pspec) (G_TYPE_CHECK_INSTANCE_CAST ((pspec), GIMP_TYPE_PARAM_CORE_OBJECT_ARRAY, GimpParamSpecCoreObjectArray))
|
|
|
|
|
|
|
|
typedef struct _GimpParamSpecCoreObjectArray GimpParamSpecCoreObjectArray;
|
|
|
|
|
|
|
|
struct _GimpParamSpecCoreObjectArray
|
|
|
|
{
|
|
|
|
GParamSpecBoxed parent_instance;
|
|
|
|
|
|
|
|
GType object_type;
|
|
|
|
};
|
|
|
|
|
2024-10-22 03:59:26 +08:00
|
|
|
static void gimp_param_core_object_array_class_init (GParamSpecClass *klass);
|
|
|
|
static void gimp_param_core_object_array_init (GParamSpec *pspec);
|
|
|
|
static gboolean gimp_param_core_object_array_validate (GParamSpec *pspec,
|
|
|
|
GValue *value);
|
|
|
|
static gint gimp_param_core_object_array_values_cmp (GParamSpec *pspec,
|
|
|
|
const GValue *value1,
|
|
|
|
const GValue *value2);
|
|
|
|
|
|
|
|
GType
|
|
|
|
gimp_param_core_object_array_get_type (void)
|
|
|
|
{
|
|
|
|
static GType type = 0;
|
|
|
|
|
|
|
|
if (! type)
|
|
|
|
{
|
|
|
|
const GTypeInfo info =
|
|
|
|
{
|
|
|
|
sizeof (GParamSpecClass),
|
|
|
|
NULL, NULL,
|
|
|
|
(GClassInitFunc) gimp_param_core_object_array_class_init,
|
|
|
|
NULL, NULL,
|
|
|
|
sizeof (GimpParamSpecCoreObjectArray),
|
|
|
|
0,
|
|
|
|
(GInstanceInitFunc) gimp_param_core_object_array_init
|
|
|
|
};
|
|
|
|
|
|
|
|
type = g_type_register_static (G_TYPE_PARAM_BOXED,
|
|
|
|
"GimpParamCoreObjectArray", &info, 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
return type;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
gimp_param_core_object_array_class_init (GParamSpecClass *klass)
|
|
|
|
{
|
|
|
|
klass->value_type = GIMP_TYPE_CORE_OBJECT_ARRAY;
|
|
|
|
klass->value_validate = gimp_param_core_object_array_validate;
|
|
|
|
klass->values_cmp = gimp_param_core_object_array_values_cmp;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
gimp_param_core_object_array_init (GParamSpec *pspec)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
static gboolean
|
|
|
|
gimp_param_core_object_array_validate (GParamSpec *pspec,
|
|
|
|
GValue *value)
|
|
|
|
{
|
|
|
|
GimpParamSpecCoreObjectArray *array_spec = GIMP_PARAM_SPEC_CORE_OBJECT_ARRAY (pspec);
|
|
|
|
GObject **array = value->data[0].v_pointer;
|
|
|
|
|
|
|
|
if (array)
|
|
|
|
{
|
|
|
|
gsize length = gimp_core_object_array_get_length (array);
|
|
|
|
gsize i;
|
|
|
|
|
|
|
|
if (length == 0)
|
|
|
|
{
|
|
|
|
g_value_set_boxed (value, NULL);
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; i < length; i++)
|
|
|
|
{
|
|
|
|
if (array[i] && ! g_type_is_a (G_OBJECT_TYPE (array[i]), array_spec->object_type))
|
|
|
|
{
|
|
|
|
g_value_set_boxed (value, NULL);
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
static gint
|
|
|
|
gimp_param_core_object_array_values_cmp (GParamSpec *pspec,
|
|
|
|
const GValue *value1,
|
|
|
|
const GValue *value2)
|
|
|
|
{
|
|
|
|
GObject **array1 = value1->data[0].v_pointer;
|
|
|
|
GObject **array2 = value2->data[0].v_pointer;
|
|
|
|
|
|
|
|
/* try to return at least *something*, it's useless anyway... */
|
|
|
|
|
|
|
|
if (! array1)
|
|
|
|
return array2 != NULL ? -1 : 0;
|
|
|
|
else if (! array2)
|
|
|
|
return array1 != NULL ? 1 : 0;
|
|
|
|
else if (gimp_core_object_array_get_length (array1) < gimp_core_object_array_get_length (array2))
|
|
|
|
return -1;
|
|
|
|
else if (gimp_core_object_array_get_length (array1) > gimp_core_object_array_get_length (array2))
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
for (gsize i = 0; i < gimp_core_object_array_get_length (array1); i++)
|
|
|
|
if (array1[0] != array2[0])
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* gimp_param_spec_core_object_array:
|
|
|
|
* @name: Canonical name of the property specified.
|
|
|
|
* @nick: Nick name of the property specified.
|
|
|
|
* @blurb: Description of the property specified.
|
|
|
|
* @object_type: GType of the array's elements.
|
|
|
|
* @flags: Flags for the property specified.
|
|
|
|
*
|
|
|
|
* Creates a new #GimpParamSpecCoreObjectArray specifying a
|
|
|
|
* [type@CoreObjectArray] property.
|
|
|
|
*
|
|
|
|
* See g_param_spec_internal() for details on property names.
|
|
|
|
*
|
|
|
|
* Returns: (transfer floating): The newly created #GimpParamSpecCoreObjectArray.
|
|
|
|
*
|
|
|
|
* Since: 3.0
|
|
|
|
**/
|
|
|
|
GParamSpec *
|
|
|
|
gimp_param_spec_core_object_array (const gchar *name,
|
|
|
|
const gchar *nick,
|
|
|
|
const gchar *blurb,
|
|
|
|
GType object_type,
|
|
|
|
GParamFlags flags)
|
|
|
|
{
|
|
|
|
GimpParamSpecCoreObjectArray *array_spec;
|
|
|
|
|
|
|
|
g_return_val_if_fail (g_type_is_a (object_type, G_TYPE_OBJECT), NULL);
|
|
|
|
|
|
|
|
array_spec = g_param_spec_internal (GIMP_TYPE_PARAM_CORE_OBJECT_ARRAY,
|
|
|
|
name, nick, blurb, flags);
|
|
|
|
|
|
|
|
g_return_val_if_fail (array_spec, NULL);
|
|
|
|
|
|
|
|
array_spec->object_type = object_type;
|
|
|
|
|
|
|
|
return G_PARAM_SPEC (array_spec);
|
|
|
|
}
|
2025-01-25 07:02:29 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* gimp_param_spec_core_object_array_get_object_type:
|
|
|
|
* @pspec: a #GParamSpec to hold a #GimpParamSpecCoreObjectArray value.
|
|
|
|
*
|
|
|
|
* Returns: the type for objects in the object array.
|
|
|
|
*
|
|
|
|
* Since: 3.0
|
|
|
|
**/
|
|
|
|
GType
|
|
|
|
gimp_param_spec_core_object_array_get_object_type (GParamSpec *pspec)
|
|
|
|
{
|
|
|
|
g_return_val_if_fail (GIMP_IS_PARAM_SPEC_CORE_OBJECT_ARRAY (pspec), G_TYPE_NONE);
|
|
|
|
|
|
|
|
return GIMP_PARAM_SPEC_CORE_OBJECT_ARRAY (pspec)->object_type;
|
|
|
|
}
|