2001-01-25 01:20:05 +00:00
|
|
|
/* LIBGIMP - The GIMP Library
|
2003-11-07 17:29:02 +00:00
|
|
|
* Copyright (C) 1995-1997 Peter Mattis and Spencer Kimball
|
1998-01-25 10:26:47 +00:00
|
|
|
*
|
2009-01-17 22:28:01 +00:00
|
|
|
* This library is free software: you can redistribute it and/or
|
1999-11-17 21:13:50 +00:00
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
1998-01-25 10:26:47 +00:00
|
|
|
* License as published by the Free Software Foundation; either
|
2009-01-17 22:28:01 +00:00
|
|
|
* version 3 of the License, or (at your option) any later version.
|
2001-01-25 01:20:05 +00:00
|
|
|
*
|
|
|
|
|
* 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
|
1999-12-26 07:54:39 +00:00
|
|
|
* Lesser General Public License for more details.
|
1998-01-25 10:26:47 +00:00
|
|
|
*
|
1999-11-17 21:13:50 +00:00
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
2009-01-17 22:28:01 +00:00
|
|
|
* License along with this library. If not, see
|
2018-07-11 23:27:07 +02:00
|
|
|
* <https://www.gnu.org/licenses/>.
|
2001-01-25 01:20:05 +00:00
|
|
|
*/
|
2000-05-30 23:38:46 +00:00
|
|
|
|
1997-11-24 22:05:25 +00:00
|
|
|
#ifndef __GIMP_PROTOCOL_H__
|
|
|
|
|
#define __GIMP_PROTOCOL_H__
|
|
|
|
|
|
2001-11-22 23:46:13 +00:00
|
|
|
G_BEGIN_DECLS
|
2000-05-30 23:38:46 +00:00
|
|
|
|
|
|
|
|
/* For information look into the C source or the html documentation */
|
|
|
|
|
|
1997-11-24 22:05:25 +00:00
|
|
|
|
|
|
|
|
/* Increment every time the protocol changes
|
|
|
|
|
*/
|
2025-01-22 17:15:28 +01:00
|
|
|
#define GIMP_PROTOCOL_VERSION 0x0115
|
1997-11-24 22:05:25 +00:00
|
|
|
|
|
|
|
|
|
2000-03-04 00:24:39 +00:00
|
|
|
enum
|
|
|
|
|
{
|
1997-11-24 22:05:25 +00:00
|
|
|
GP_QUIT,
|
|
|
|
|
GP_CONFIG,
|
|
|
|
|
GP_TILE_REQ,
|
|
|
|
|
GP_TILE_ACK,
|
|
|
|
|
GP_TILE_DATA,
|
|
|
|
|
GP_PROC_RUN,
|
|
|
|
|
GP_PROC_RETURN,
|
|
|
|
|
GP_TEMP_PROC_RUN,
|
|
|
|
|
GP_TEMP_PROC_RETURN,
|
|
|
|
|
GP_PROC_INSTALL,
|
|
|
|
|
GP_PROC_UNINSTALL,
|
2002-02-12 07:59:16 +00:00
|
|
|
GP_EXTENSION_ACK,
|
|
|
|
|
GP_HAS_INIT
|
1997-11-24 22:05:25 +00:00
|
|
|
};
|
|
|
|
|
|
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two
- Change the wire protocol's GPProcInstall to transmit the entire
information needed for constructing all GParamSpecs we use, don't
use GimpPDBArgType in GPProcInstall but an enum private to the wire
protocol plus the GParamSpec's GType name. Bump the wire protocol
version.
- Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which
take care of converting between GPParamDef and GParamSpec. They
share code as far as possible.
- Change pluginrc writing and parsing to re-use GPParamDef and the
utility functions from gimpgpparamspecs.
- Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch],
the entire core uses proper GParamSpecs from the wire protocol now,
the whole file will follow down the drain once we use a GValue
representation on the wire too.
- In gimp_plug_in_handle_proc_install(), change the "run-mode"
parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not
already an enum). and change all places in app/ to treat it as an
enum value.
- plug-ins: fix cml-explorer to register correctly, a typo in
"run-mode" was never noticed until now.
- Add gimpgpcompat.[ch] in libgimp to deal with all the transforms
between old-style wire communication and using GParamSpec and
GValue, it contains some functions that are subject to change or
even removal in the next steps.
- Change the libgimp GimpProcedure and GimpPlugIn in many ways to be
able to actually install procedures the new way.
- plug-ins: change goat-exercise to completely use the new GimpPlugIn
and GimpProcedure API, look here to see how plug-ins will look in
the future, of course subject to change until this is finished.
- Next: changing GPParam to transmit all information about a GValue.
2019-07-27 16:37:55 +02:00
|
|
|
typedef enum
|
|
|
|
|
{
|
|
|
|
|
GP_PARAM_DEF_TYPE_DEFAULT,
|
|
|
|
|
GP_PARAM_DEF_TYPE_INT,
|
2019-07-30 15:04:06 +02:00
|
|
|
GP_PARAM_DEF_TYPE_UNIT,
|
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two
- Change the wire protocol's GPProcInstall to transmit the entire
information needed for constructing all GParamSpecs we use, don't
use GimpPDBArgType in GPProcInstall but an enum private to the wire
protocol plus the GParamSpec's GType name. Bump the wire protocol
version.
- Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which
take care of converting between GPParamDef and GParamSpec. They
share code as far as possible.
- Change pluginrc writing and parsing to re-use GPParamDef and the
utility functions from gimpgpparamspecs.
- Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch],
the entire core uses proper GParamSpecs from the wire protocol now,
the whole file will follow down the drain once we use a GValue
representation on the wire too.
- In gimp_plug_in_handle_proc_install(), change the "run-mode"
parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not
already an enum). and change all places in app/ to treat it as an
enum value.
- plug-ins: fix cml-explorer to register correctly, a typo in
"run-mode" was never noticed until now.
- Add gimpgpcompat.[ch] in libgimp to deal with all the transforms
between old-style wire communication and using GParamSpec and
GValue, it contains some functions that are subject to change or
even removal in the next steps.
- Change the libgimp GimpProcedure and GimpPlugIn in many ways to be
able to actually install procedures the new way.
- plug-ins: change goat-exercise to completely use the new GimpPlugIn
and GimpProcedure API, look here to see how plug-ins will look in
the future, of course subject to change until this is finished.
- Next: changing GPParam to transmit all information about a GValue.
2019-07-27 16:37:55 +02:00
|
|
|
GP_PARAM_DEF_TYPE_ENUM,
|
2023-08-02 23:55:33 +02:00
|
|
|
GP_PARAM_DEF_TYPE_CHOICE,
|
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two
- Change the wire protocol's GPProcInstall to transmit the entire
information needed for constructing all GParamSpecs we use, don't
use GimpPDBArgType in GPProcInstall but an enum private to the wire
protocol plus the GParamSpec's GType name. Bump the wire protocol
version.
- Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which
take care of converting between GPParamDef and GParamSpec. They
share code as far as possible.
- Change pluginrc writing and parsing to re-use GPParamDef and the
utility functions from gimpgpparamspecs.
- Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch],
the entire core uses proper GParamSpecs from the wire protocol now,
the whole file will follow down the drain once we use a GValue
representation on the wire too.
- In gimp_plug_in_handle_proc_install(), change the "run-mode"
parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not
already an enum). and change all places in app/ to treat it as an
enum value.
- plug-ins: fix cml-explorer to register correctly, a typo in
"run-mode" was never noticed until now.
- Add gimpgpcompat.[ch] in libgimp to deal with all the transforms
between old-style wire communication and using GParamSpec and
GValue, it contains some functions that are subject to change or
even removal in the next steps.
- Change the libgimp GimpProcedure and GimpPlugIn in many ways to be
able to actually install procedures the new way.
- plug-ins: change goat-exercise to completely use the new GimpPlugIn
and GimpProcedure API, look here to see how plug-ins will look in
the future, of course subject to change until this is finished.
- Next: changing GPParam to transmit all information about a GValue.
2019-07-27 16:37:55 +02:00
|
|
|
GP_PARAM_DEF_TYPE_BOOLEAN,
|
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
2024-11-02 14:03:37 +01:00
|
|
|
GP_PARAM_DEF_TYPE_DOUBLE,
|
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two
- Change the wire protocol's GPProcInstall to transmit the entire
information needed for constructing all GParamSpecs we use, don't
use GimpPDBArgType in GPProcInstall but an enum private to the wire
protocol plus the GParamSpec's GType name. Bump the wire protocol
version.
- Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which
take care of converting between GPParamDef and GParamSpec. They
share code as far as possible.
- Change pluginrc writing and parsing to re-use GPParamDef and the
utility functions from gimpgpparamspecs.
- Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch],
the entire core uses proper GParamSpecs from the wire protocol now,
the whole file will follow down the drain once we use a GValue
representation on the wire too.
- In gimp_plug_in_handle_proc_install(), change the "run-mode"
parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not
already an enum). and change all places in app/ to treat it as an
enum value.
- plug-ins: fix cml-explorer to register correctly, a typo in
"run-mode" was never noticed until now.
- Add gimpgpcompat.[ch] in libgimp to deal with all the transforms
between old-style wire communication and using GParamSpec and
GValue, it contains some functions that are subject to change or
even removal in the next steps.
- Change the libgimp GimpProcedure and GimpPlugIn in many ways to be
able to actually install procedures the new way.
- plug-ins: change goat-exercise to completely use the new GimpPlugIn
and GimpProcedure API, look here to see how plug-ins will look in
the future, of course subject to change until this is finished.
- Next: changing GPParam to transmit all information about a GValue.
2019-07-27 16:37:55 +02:00
|
|
|
GP_PARAM_DEF_TYPE_STRING,
|
2024-02-13 16:07:24 +01:00
|
|
|
GP_PARAM_DEF_TYPE_GEGL_COLOR,
|
2019-08-05 14:12:19 +02:00
|
|
|
GP_PARAM_DEF_TYPE_ID,
|
2024-05-06 18:38:12 +00:00
|
|
|
GP_PARAM_DEF_TYPE_ID_ARRAY,
|
2024-09-06 13:38:43 +02:00
|
|
|
GP_PARAM_DEF_TYPE_EXPORT_OPTIONS,
|
2025-01-22 17:15:28 +01:00
|
|
|
GP_PARAM_DEF_TYPE_RESOURCE,
|
|
|
|
|
GP_PARAM_DEF_TYPE_FILE
|
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two
- Change the wire protocol's GPProcInstall to transmit the entire
information needed for constructing all GParamSpecs we use, don't
use GimpPDBArgType in GPProcInstall but an enum private to the wire
protocol plus the GParamSpec's GType name. Bump the wire protocol
version.
- Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which
take care of converting between GPParamDef and GParamSpec. They
share code as far as possible.
- Change pluginrc writing and parsing to re-use GPParamDef and the
utility functions from gimpgpparamspecs.
- Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch],
the entire core uses proper GParamSpecs from the wire protocol now,
the whole file will follow down the drain once we use a GValue
representation on the wire too.
- In gimp_plug_in_handle_proc_install(), change the "run-mode"
parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not
already an enum). and change all places in app/ to treat it as an
enum value.
- plug-ins: fix cml-explorer to register correctly, a typo in
"run-mode" was never noticed until now.
- Add gimpgpcompat.[ch] in libgimp to deal with all the transforms
between old-style wire communication and using GParamSpec and
GValue, it contains some functions that are subject to change or
even removal in the next steps.
- Change the libgimp GimpProcedure and GimpPlugIn in many ways to be
able to actually install procedures the new way.
- plug-ins: change goat-exercise to completely use the new GimpPlugIn
and GimpProcedure API, look here to see how plug-ins will look in
the future, of course subject to change until this is finished.
- Next: changing GPParam to transmit all information about a GValue.
2019-07-27 16:37:55 +02:00
|
|
|
} GPParamDefType;
|
|
|
|
|
|
2019-08-04 23:59:25 +02:00
|
|
|
typedef enum
|
|
|
|
|
{
|
|
|
|
|
GP_PARAM_TYPE_INT,
|
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
2024-11-02 14:03:37 +01:00
|
|
|
GP_PARAM_TYPE_DOUBLE,
|
2019-08-04 23:59:25 +02:00
|
|
|
GP_PARAM_TYPE_STRING,
|
2020-12-23 21:15:43 +01:00
|
|
|
GP_PARAM_TYPE_STRV,
|
2023-05-23 23:37:46 +02:00
|
|
|
GP_PARAM_TYPE_BYTES,
|
2019-09-11 21:40:17 +02:00
|
|
|
GP_PARAM_TYPE_FILE,
|
2024-09-20 21:55:21 +02:00
|
|
|
GP_PARAM_TYPE_BABL_FORMAT,
|
2023-11-03 21:26:51 +01:00
|
|
|
GP_PARAM_TYPE_GEGL_COLOR,
|
2023-12-27 01:07:19 +09:00
|
|
|
GP_PARAM_TYPE_COLOR_ARRAY,
|
2019-08-04 23:59:25 +02:00
|
|
|
GP_PARAM_TYPE_PARASITE,
|
|
|
|
|
GP_PARAM_TYPE_ARRAY,
|
2019-09-05 11:34:54 +02:00
|
|
|
GP_PARAM_TYPE_ID_ARRAY,
|
2024-05-06 18:38:12 +00:00
|
|
|
GP_PARAM_TYPE_EXPORT_OPTIONS,
|
2024-11-29 17:37:23 +09:00
|
|
|
GP_PARAM_TYPE_PARAM_DEF,
|
|
|
|
|
GP_PARAM_TYPE_VALUE_ARRAY,
|
2019-08-04 23:59:25 +02:00
|
|
|
} GPParamType;
|
|
|
|
|
|
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two
- Change the wire protocol's GPProcInstall to transmit the entire
information needed for constructing all GParamSpecs we use, don't
use GimpPDBArgType in GPProcInstall but an enum private to the wire
protocol plus the GParamSpec's GType name. Bump the wire protocol
version.
- Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which
take care of converting between GPParamDef and GParamSpec. They
share code as far as possible.
- Change pluginrc writing and parsing to re-use GPParamDef and the
utility functions from gimpgpparamspecs.
- Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch],
the entire core uses proper GParamSpecs from the wire protocol now,
the whole file will follow down the drain once we use a GValue
representation on the wire too.
- In gimp_plug_in_handle_proc_install(), change the "run-mode"
parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not
already an enum). and change all places in app/ to treat it as an
enum value.
- plug-ins: fix cml-explorer to register correctly, a typo in
"run-mode" was never noticed until now.
- Add gimpgpcompat.[ch] in libgimp to deal with all the transforms
between old-style wire communication and using GParamSpec and
GValue, it contains some functions that are subject to change or
even removal in the next steps.
- Change the libgimp GimpProcedure and GimpPlugIn in many ways to be
able to actually install procedures the new way.
- plug-ins: change goat-exercise to completely use the new GimpPlugIn
and GimpProcedure API, look here to see how plug-ins will look in
the future, of course subject to change until this is finished.
- Next: changing GPParam to transmit all information about a GValue.
2019-07-27 16:37:55 +02:00
|
|
|
|
2024-05-06 18:38:12 +00:00
|
|
|
typedef struct _GPConfig GPConfig;
|
|
|
|
|
typedef struct _GPTileReq GPTileReq;
|
|
|
|
|
typedef struct _GPTileAck GPTileAck;
|
|
|
|
|
typedef struct _GPTileData GPTileData;
|
|
|
|
|
typedef struct _GPParamDef GPParamDef;
|
|
|
|
|
typedef struct _GPParamDefInt GPParamDefInt;
|
|
|
|
|
typedef struct _GPParamDefUnit GPParamDefUnit;
|
|
|
|
|
typedef struct _GPParamDefEnum GPParamDefEnum;
|
|
|
|
|
typedef struct _GPParamDefBoolean GPParamDefBoolean;
|
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
2024-11-02 14:03:37 +01:00
|
|
|
typedef struct _GPParamDefDouble GPParamDefDouble;
|
2024-05-06 18:38:12 +00:00
|
|
|
typedef struct _GPParamDefString GPParamDefString;
|
|
|
|
|
typedef struct _GPParamDefChoice GPParamDefChoice;
|
|
|
|
|
typedef struct _GPParamStrv GPParamStrv;
|
|
|
|
|
typedef struct _GPParamDefGeglColor GPParamDefGeglColor;
|
|
|
|
|
typedef struct _GPParamDefID GPParamDefID;
|
|
|
|
|
typedef struct _GPParamDefIDArray GPParamDefIDArray;
|
2024-09-06 13:38:43 +02:00
|
|
|
typedef struct _GPParamDefResource GPParamDefResource;
|
2025-01-22 17:15:28 +01:00
|
|
|
typedef struct _GPParamDefFile GPParamDefFile;
|
2024-05-06 18:38:12 +00:00
|
|
|
typedef struct _GPParam GPParam;
|
|
|
|
|
typedef struct _GPParamArray GPParamArray;
|
|
|
|
|
typedef struct _GPParamIDArray GPParamIDArray;
|
2024-09-20 21:55:21 +02:00
|
|
|
typedef struct _GPParamFormat GPParamFormat;
|
2024-05-06 18:38:12 +00:00
|
|
|
typedef struct _GPParamColor GPParamColor;
|
|
|
|
|
typedef struct _GPParamColorArray GPParamColorArray;
|
|
|
|
|
typedef struct _GPParamExportOptions GPParamExportOptions;
|
2024-11-29 17:37:23 +09:00
|
|
|
typedef struct _GPParamValueArray GPParamValueArray;
|
2024-05-06 18:38:12 +00:00
|
|
|
typedef struct _GPProcRun GPProcRun;
|
|
|
|
|
typedef struct _GPProcReturn GPProcReturn;
|
|
|
|
|
typedef struct _GPProcInstall GPProcInstall;
|
|
|
|
|
typedef struct _GPProcUninstall GPProcUninstall;
|
1997-11-24 22:05:25 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
struct _GPConfig
|
|
|
|
|
{
|
2003-11-07 17:29:02 +00:00
|
|
|
guint32 tile_width;
|
|
|
|
|
guint32 tile_height;
|
2019-08-23 22:23:23 +02:00
|
|
|
gint32 shm_id;
|
2004-09-13 13:33:56 +00:00
|
|
|
gint8 check_size;
|
|
|
|
|
gint8 check_type;
|
2004-10-04 16:21:52 +00:00
|
|
|
gint8 show_help_button;
|
2006-06-01 15:34:58 +00:00
|
|
|
gint8 use_cpu_accel;
|
2014-02-25 21:19:25 +01:00
|
|
|
gint8 use_opencl;
|
2019-10-10 00:45:41 +02:00
|
|
|
gint8 export_color_profile;
|
|
|
|
|
gint8 export_comment;
|
2018-01-11 05:14:07 +01:00
|
|
|
gint8 export_exif;
|
|
|
|
|
gint8 export_xmp;
|
|
|
|
|
gint8 export_iptc;
|
2019-10-10 00:45:41 +02:00
|
|
|
gint32 default_display_id;
|
2004-02-17 14:03:07 +00:00
|
|
|
gchar *app_name;
|
2003-11-07 17:29:02 +00:00
|
|
|
gchar *wm_class;
|
|
|
|
|
gchar *display_name;
|
|
|
|
|
gint32 monitor_number;
|
2008-03-27 16:30:29 +00:00
|
|
|
guint32 timestamp;
|
libgimpbase, libgimp, app: pass icon theme dir to plug-ins through config
Pass the current icon theme directory to plug-ins through the
config message, and add a gimp_icon_theme_dir() libgimp function
for retrieving it. Note that we already have a similar
gimp_icon_get_theme_dir() PDB function, which we keep around, since
it can be used to dynamically query for the current icon dir,
unlike the former, and since it returns a dynamically-allocated
string, while the rest of the config-related functions return
statically allocated strings.
Use the new function, instead of gimp_get_icon_theme_dir(), in
gimp_ui_init(). This allows gimp_ui_init() to run without making
any PDB calls. Consequently, this allows us to start plug-ins that
call gimp_ui_init() without entering the main loop in the main app.
We're going to add a plug-in that displays an interactive dialog
while the main app is blocking waiting for an operation to
complete, and we need to be able to start the plug-in without
entering the main loop, to avoid the possibility of arbitrary code
being executed during the wait.
Bump the protocol version.
2018-05-29 11:20:54 -04:00
|
|
|
gchar *icon_theme_dir;
|
2018-11-19 16:13:07 -05:00
|
|
|
guint64 tile_cache_size;
|
|
|
|
|
gchar *swap_path;
|
2019-09-22 17:48:16 +03:00
|
|
|
gchar *swap_compression;
|
2018-11-19 16:13:07 -05:00
|
|
|
gint32 num_processors;
|
2022-05-14 13:52:00 +02:00
|
|
|
|
2023-11-20 21:38:11 +01:00
|
|
|
/* Since protocol version 0x0111:
|
|
|
|
|
* These values are used to represent 2 GeglColor objects but we avoid
|
|
|
|
|
* initializing GEGL in the wire protocol. This leads to extremely
|
|
|
|
|
* slow startup when initializing every plug-in. So we store them as
|
|
|
|
|
* bytes and encoding string and reconstruct the GeglColor in libgimp.
|
|
|
|
|
*/
|
|
|
|
|
GBytes *check_custom_color1;
|
|
|
|
|
GBytes *check_custom_icc1;
|
|
|
|
|
gchar *check_custom_encoding1;
|
|
|
|
|
GBytes *check_custom_color2;
|
|
|
|
|
GBytes *check_custom_icc2;
|
|
|
|
|
gchar *check_custom_encoding2;
|
1997-11-24 22:05:25 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct _GPTileReq
|
|
|
|
|
{
|
2019-08-23 22:23:23 +02:00
|
|
|
gint32 drawable_id;
|
2004-10-04 16:21:52 +00:00
|
|
|
guint32 tile_num;
|
|
|
|
|
guint32 shadow;
|
1997-11-24 22:05:25 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct _GPTileData
|
|
|
|
|
{
|
2019-08-23 22:23:23 +02:00
|
|
|
gint32 drawable_id;
|
2000-03-04 00:24:39 +00:00
|
|
|
guint32 tile_num;
|
|
|
|
|
guint32 shadow;
|
|
|
|
|
guint32 bpp;
|
|
|
|
|
guint32 width;
|
|
|
|
|
guint32 height;
|
|
|
|
|
guint32 use_shm;
|
|
|
|
|
guchar *data;
|
1997-11-24 22:05:25 +00:00
|
|
|
};
|
|
|
|
|
|
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two
- Change the wire protocol's GPProcInstall to transmit the entire
information needed for constructing all GParamSpecs we use, don't
use GimpPDBArgType in GPProcInstall but an enum private to the wire
protocol plus the GParamSpec's GType name. Bump the wire protocol
version.
- Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which
take care of converting between GPParamDef and GParamSpec. They
share code as far as possible.
- Change pluginrc writing and parsing to re-use GPParamDef and the
utility functions from gimpgpparamspecs.
- Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch],
the entire core uses proper GParamSpecs from the wire protocol now,
the whole file will follow down the drain once we use a GValue
representation on the wire too.
- In gimp_plug_in_handle_proc_install(), change the "run-mode"
parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not
already an enum). and change all places in app/ to treat it as an
enum value.
- plug-ins: fix cml-explorer to register correctly, a typo in
"run-mode" was never noticed until now.
- Add gimpgpcompat.[ch] in libgimp to deal with all the transforms
between old-style wire communication and using GParamSpec and
GValue, it contains some functions that are subject to change or
even removal in the next steps.
- Change the libgimp GimpProcedure and GimpPlugIn in many ways to be
able to actually install procedures the new way.
- plug-ins: change goat-exercise to completely use the new GimpPlugIn
and GimpProcedure API, look here to see how plug-ins will look in
the future, of course subject to change until this is finished.
- Next: changing GPParam to transmit all information about a GValue.
2019-07-27 16:37:55 +02:00
|
|
|
struct _GPParamDefInt
|
|
|
|
|
{
|
2019-08-10 16:25:22 +02:00
|
|
|
gint64 min_val;
|
|
|
|
|
gint64 max_val;
|
|
|
|
|
gint64 default_val;
|
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two
- Change the wire protocol's GPProcInstall to transmit the entire
information needed for constructing all GParamSpecs we use, don't
use GimpPDBArgType in GPProcInstall but an enum private to the wire
protocol plus the GParamSpec's GType name. Bump the wire protocol
version.
- Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which
take care of converting between GPParamDef and GParamSpec. They
share code as far as possible.
- Change pluginrc writing and parsing to re-use GPParamDef and the
utility functions from gimpgpparamspecs.
- Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch],
the entire core uses proper GParamSpecs from the wire protocol now,
the whole file will follow down the drain once we use a GValue
representation on the wire too.
- In gimp_plug_in_handle_proc_install(), change the "run-mode"
parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not
already an enum). and change all places in app/ to treat it as an
enum value.
- plug-ins: fix cml-explorer to register correctly, a typo in
"run-mode" was never noticed until now.
- Add gimpgpcompat.[ch] in libgimp to deal with all the transforms
between old-style wire communication and using GParamSpec and
GValue, it contains some functions that are subject to change or
even removal in the next steps.
- Change the libgimp GimpProcedure and GimpPlugIn in many ways to be
able to actually install procedures the new way.
- plug-ins: change goat-exercise to completely use the new GimpPlugIn
and GimpProcedure API, look here to see how plug-ins will look in
the future, of course subject to change until this is finished.
- Next: changing GPParam to transmit all information about a GValue.
2019-07-27 16:37:55 +02:00
|
|
|
};
|
|
|
|
|
|
2019-07-30 15:04:06 +02:00
|
|
|
struct _GPParamDefUnit
|
|
|
|
|
{
|
|
|
|
|
gint32 allow_pixels;
|
|
|
|
|
gint32 allow_percent;
|
|
|
|
|
gint32 default_val;
|
|
|
|
|
};
|
|
|
|
|
|
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two
- Change the wire protocol's GPProcInstall to transmit the entire
information needed for constructing all GParamSpecs we use, don't
use GimpPDBArgType in GPProcInstall but an enum private to the wire
protocol plus the GParamSpec's GType name. Bump the wire protocol
version.
- Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which
take care of converting between GPParamDef and GParamSpec. They
share code as far as possible.
- Change pluginrc writing and parsing to re-use GPParamDef and the
utility functions from gimpgpparamspecs.
- Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch],
the entire core uses proper GParamSpecs from the wire protocol now,
the whole file will follow down the drain once we use a GValue
representation on the wire too.
- In gimp_plug_in_handle_proc_install(), change the "run-mode"
parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not
already an enum). and change all places in app/ to treat it as an
enum value.
- plug-ins: fix cml-explorer to register correctly, a typo in
"run-mode" was never noticed until now.
- Add gimpgpcompat.[ch] in libgimp to deal with all the transforms
between old-style wire communication and using GParamSpec and
GValue, it contains some functions that are subject to change or
even removal in the next steps.
- Change the libgimp GimpProcedure and GimpPlugIn in many ways to be
able to actually install procedures the new way.
- plug-ins: change goat-exercise to completely use the new GimpPlugIn
and GimpProcedure API, look here to see how plug-ins will look in
the future, of course subject to change until this is finished.
- Next: changing GPParam to transmit all information about a GValue.
2019-07-27 16:37:55 +02:00
|
|
|
struct _GPParamDefEnum
|
|
|
|
|
{
|
2019-09-11 21:40:17 +02:00
|
|
|
gint32 default_val;
|
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two
- Change the wire protocol's GPProcInstall to transmit the entire
information needed for constructing all GParamSpecs we use, don't
use GimpPDBArgType in GPProcInstall but an enum private to the wire
protocol plus the GParamSpec's GType name. Bump the wire protocol
version.
- Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which
take care of converting between GPParamDef and GParamSpec. They
share code as far as possible.
- Change pluginrc writing and parsing to re-use GPParamDef and the
utility functions from gimpgpparamspecs.
- Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch],
the entire core uses proper GParamSpecs from the wire protocol now,
the whole file will follow down the drain once we use a GValue
representation on the wire too.
- In gimp_plug_in_handle_proc_install(), change the "run-mode"
parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not
already an enum). and change all places in app/ to treat it as an
enum value.
- plug-ins: fix cml-explorer to register correctly, a typo in
"run-mode" was never noticed until now.
- Add gimpgpcompat.[ch] in libgimp to deal with all the transforms
between old-style wire communication and using GParamSpec and
GValue, it contains some functions that are subject to change or
even removal in the next steps.
- Change the libgimp GimpProcedure and GimpPlugIn in many ways to be
able to actually install procedures the new way.
- plug-ins: change goat-exercise to completely use the new GimpPlugIn
and GimpProcedure API, look here to see how plug-ins will look in
the future, of course subject to change until this is finished.
- Next: changing GPParam to transmit all information about a GValue.
2019-07-27 16:37:55 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct _GPParamDefBoolean
|
|
|
|
|
{
|
|
|
|
|
gint32 default_val;
|
|
|
|
|
};
|
|
|
|
|
|
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
2024-11-02 14:03:37 +01:00
|
|
|
struct _GPParamDefDouble
|
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two
- Change the wire protocol's GPProcInstall to transmit the entire
information needed for constructing all GParamSpecs we use, don't
use GimpPDBArgType in GPProcInstall but an enum private to the wire
protocol plus the GParamSpec's GType name. Bump the wire protocol
version.
- Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which
take care of converting between GPParamDef and GParamSpec. They
share code as far as possible.
- Change pluginrc writing and parsing to re-use GPParamDef and the
utility functions from gimpgpparamspecs.
- Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch],
the entire core uses proper GParamSpecs from the wire protocol now,
the whole file will follow down the drain once we use a GValue
representation on the wire too.
- In gimp_plug_in_handle_proc_install(), change the "run-mode"
parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not
already an enum). and change all places in app/ to treat it as an
enum value.
- plug-ins: fix cml-explorer to register correctly, a typo in
"run-mode" was never noticed until now.
- Add gimpgpcompat.[ch] in libgimp to deal with all the transforms
between old-style wire communication and using GParamSpec and
GValue, it contains some functions that are subject to change or
even removal in the next steps.
- Change the libgimp GimpProcedure and GimpPlugIn in many ways to be
able to actually install procedures the new way.
- plug-ins: change goat-exercise to completely use the new GimpPlugIn
and GimpProcedure API, look here to see how plug-ins will look in
the future, of course subject to change until this is finished.
- Next: changing GPParam to transmit all information about a GValue.
2019-07-27 16:37:55 +02:00
|
|
|
{
|
|
|
|
|
gdouble min_val;
|
|
|
|
|
gdouble max_val;
|
|
|
|
|
gdouble default_val;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct _GPParamDefString
|
|
|
|
|
{
|
2019-09-05 11:34:54 +02:00
|
|
|
gchar *default_val;
|
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two
- Change the wire protocol's GPProcInstall to transmit the entire
information needed for constructing all GParamSpecs we use, don't
use GimpPDBArgType in GPProcInstall but an enum private to the wire
protocol plus the GParamSpec's GType name. Bump the wire protocol
version.
- Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which
take care of converting between GPParamDef and GParamSpec. They
share code as far as possible.
- Change pluginrc writing and parsing to re-use GPParamDef and the
utility functions from gimpgpparamspecs.
- Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch],
the entire core uses proper GParamSpecs from the wire protocol now,
the whole file will follow down the drain once we use a GValue
representation on the wire too.
- In gimp_plug_in_handle_proc_install(), change the "run-mode"
parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not
already an enum). and change all places in app/ to treat it as an
enum value.
- plug-ins: fix cml-explorer to register correctly, a typo in
"run-mode" was never noticed until now.
- Add gimpgpcompat.[ch] in libgimp to deal with all the transforms
between old-style wire communication and using GParamSpec and
GValue, it contains some functions that are subject to change or
even removal in the next steps.
- Change the libgimp GimpProcedure and GimpPlugIn in many ways to be
able to actually install procedures the new way.
- plug-ins: change goat-exercise to completely use the new GimpPlugIn
and GimpProcedure API, look here to see how plug-ins will look in
the future, of course subject to change until this is finished.
- Next: changing GPParam to transmit all information about a GValue.
2019-07-27 16:37:55 +02:00
|
|
|
};
|
|
|
|
|
|
2024-02-13 16:07:24 +01:00
|
|
|
struct _GPParamDefGeglColor
|
|
|
|
|
{
|
|
|
|
|
gint32 has_alpha;
|
|
|
|
|
GPParamColor *default_val;
|
|
|
|
|
};
|
|
|
|
|
|
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two
- Change the wire protocol's GPProcInstall to transmit the entire
information needed for constructing all GParamSpecs we use, don't
use GimpPDBArgType in GPProcInstall but an enum private to the wire
protocol plus the GParamSpec's GType name. Bump the wire protocol
version.
- Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which
take care of converting between GPParamDef and GParamSpec. They
share code as far as possible.
- Change pluginrc writing and parsing to re-use GPParamDef and the
utility functions from gimpgpparamspecs.
- Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch],
the entire core uses proper GParamSpecs from the wire protocol now,
the whole file will follow down the drain once we use a GValue
representation on the wire too.
- In gimp_plug_in_handle_proc_install(), change the "run-mode"
parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not
already an enum). and change all places in app/ to treat it as an
enum value.
- plug-ins: fix cml-explorer to register correctly, a typo in
"run-mode" was never noticed until now.
- Add gimpgpcompat.[ch] in libgimp to deal with all the transforms
between old-style wire communication and using GParamSpec and
GValue, it contains some functions that are subject to change or
even removal in the next steps.
- Change the libgimp GimpProcedure and GimpPlugIn in many ways to be
able to actually install procedures the new way.
- plug-ins: change goat-exercise to completely use the new GimpPlugIn
and GimpProcedure API, look here to see how plug-ins will look in
the future, of course subject to change until this is finished.
- Next: changing GPParam to transmit all information about a GValue.
2019-07-27 16:37:55 +02:00
|
|
|
struct _GPParamDefID
|
|
|
|
|
{
|
|
|
|
|
gint32 none_ok;
|
|
|
|
|
};
|
|
|
|
|
|
2019-09-05 11:34:54 +02:00
|
|
|
struct _GPParamDefIDArray
|
|
|
|
|
{
|
|
|
|
|
gchar *type_name;
|
|
|
|
|
};
|
|
|
|
|
|
2023-08-02 23:55:33 +02:00
|
|
|
struct _GPParamDefChoice
|
|
|
|
|
{
|
|
|
|
|
GimpChoice *choice;
|
|
|
|
|
gchar *default_val;
|
|
|
|
|
};
|
|
|
|
|
|
2024-09-06 13:38:43 +02:00
|
|
|
struct _GPParamDefResource
|
|
|
|
|
{
|
|
|
|
|
gint32 none_ok;
|
|
|
|
|
gint32 default_to_context;
|
|
|
|
|
gint32 default_resource_id;
|
|
|
|
|
};
|
|
|
|
|
|
2025-01-22 17:15:28 +01:00
|
|
|
struct _GPParamDefFile
|
|
|
|
|
{
|
libgimp, libgimpbase: fix passing a file spec action through the wire.
I forgot to set meta.m_file.action into the GPParamDef! 🤦
As a side update, let's store the action as gint32 in GPParamDefFile. I
realized that otherwise, depending on the actual size of an enum type,
when casting to a (guint32 *), we crop the value! This works out in
Little Endian because we are only in small number territory, but in Big
Endian, we would always crop any action value to 0!
This was not the bug in this specific case, but it could become the
exact same bug (always passing action 0, i.e. OPEN, through the wire) on
Big Endian hardware.
2025-01-23 00:52:18 +01:00
|
|
|
/* action is a GimpFileChooserAction casted to gint32. */
|
|
|
|
|
gint32 action;
|
|
|
|
|
gint32 none_ok;
|
|
|
|
|
gchar *default_uri;
|
2025-01-22 17:15:28 +01:00
|
|
|
};
|
|
|
|
|
|
1997-11-24 22:05:25 +00:00
|
|
|
struct _GPParamDef
|
|
|
|
|
{
|
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two
- Change the wire protocol's GPProcInstall to transmit the entire
information needed for constructing all GParamSpecs we use, don't
use GimpPDBArgType in GPProcInstall but an enum private to the wire
protocol plus the GParamSpec's GType name. Bump the wire protocol
version.
- Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which
take care of converting between GPParamDef and GParamSpec. They
share code as far as possible.
- Change pluginrc writing and parsing to re-use GPParamDef and the
utility functions from gimpgpparamspecs.
- Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch],
the entire core uses proper GParamSpecs from the wire protocol now,
the whole file will follow down the drain once we use a GValue
representation on the wire too.
- In gimp_plug_in_handle_proc_install(), change the "run-mode"
parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not
already an enum). and change all places in app/ to treat it as an
enum value.
- plug-ins: fix cml-explorer to register correctly, a typo in
"run-mode" was never noticed until now.
- Add gimpgpcompat.[ch] in libgimp to deal with all the transforms
between old-style wire communication and using GParamSpec and
GValue, it contains some functions that are subject to change or
even removal in the next steps.
- Change the libgimp GimpProcedure and GimpPlugIn in many ways to be
able to actually install procedures the new way.
- plug-ins: change goat-exercise to completely use the new GimpPlugIn
and GimpProcedure API, look here to see how plug-ins will look in
the future, of course subject to change until this is finished.
- Next: changing GPParam to transmit all information about a GValue.
2019-07-27 16:37:55 +02:00
|
|
|
GPParamDefType param_def_type;
|
|
|
|
|
gchar *type_name;
|
2019-09-11 21:40:17 +02:00
|
|
|
gchar *value_type_name;
|
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two
- Change the wire protocol's GPProcInstall to transmit the entire
information needed for constructing all GParamSpecs we use, don't
use GimpPDBArgType in GPProcInstall but an enum private to the wire
protocol plus the GParamSpec's GType name. Bump the wire protocol
version.
- Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which
take care of converting between GPParamDef and GParamSpec. They
share code as far as possible.
- Change pluginrc writing and parsing to re-use GPParamDef and the
utility functions from gimpgpparamspecs.
- Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch],
the entire core uses proper GParamSpecs from the wire protocol now,
the whole file will follow down the drain once we use a GValue
representation on the wire too.
- In gimp_plug_in_handle_proc_install(), change the "run-mode"
parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not
already an enum). and change all places in app/ to treat it as an
enum value.
- plug-ins: fix cml-explorer to register correctly, a typo in
"run-mode" was never noticed until now.
- Add gimpgpcompat.[ch] in libgimp to deal with all the transforms
between old-style wire communication and using GParamSpec and
GValue, it contains some functions that are subject to change or
even removal in the next steps.
- Change the libgimp GimpProcedure and GimpPlugIn in many ways to be
able to actually install procedures the new way.
- plug-ins: change goat-exercise to completely use the new GimpPlugIn
and GimpProcedure API, look here to see how plug-ins will look in
the future, of course subject to change until this is finished.
- Next: changing GPParam to transmit all information about a GValue.
2019-07-27 16:37:55 +02:00
|
|
|
gchar *name;
|
|
|
|
|
gchar *nick;
|
|
|
|
|
gchar *blurb;
|
2019-08-19 12:54:52 +02:00
|
|
|
guint flags;
|
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two
- Change the wire protocol's GPProcInstall to transmit the entire
information needed for constructing all GParamSpecs we use, don't
use GimpPDBArgType in GPProcInstall but an enum private to the wire
protocol plus the GParamSpec's GType name. Bump the wire protocol
version.
- Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which
take care of converting between GPParamDef and GParamSpec. They
share code as far as possible.
- Change pluginrc writing and parsing to re-use GPParamDef and the
utility functions from gimpgpparamspecs.
- Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch],
the entire core uses proper GParamSpecs from the wire protocol now,
the whole file will follow down the drain once we use a GValue
representation on the wire too.
- In gimp_plug_in_handle_proc_install(), change the "run-mode"
parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not
already an enum). and change all places in app/ to treat it as an
enum value.
- plug-ins: fix cml-explorer to register correctly, a typo in
"run-mode" was never noticed until now.
- Add gimpgpcompat.[ch] in libgimp to deal with all the transforms
between old-style wire communication and using GParamSpec and
GValue, it contains some functions that are subject to change or
even removal in the next steps.
- Change the libgimp GimpProcedure and GimpPlugIn in many ways to be
able to actually install procedures the new way.
- plug-ins: change goat-exercise to completely use the new GimpPlugIn
and GimpProcedure API, look here to see how plug-ins will look in
the future, of course subject to change until this is finished.
- Next: changing GPParam to transmit all information about a GValue.
2019-07-27 16:37:55 +02:00
|
|
|
|
|
|
|
|
union
|
|
|
|
|
{
|
2024-05-06 18:38:12 +00:00
|
|
|
GPParamDefInt m_int;
|
|
|
|
|
GPParamDefUnit m_unit;
|
|
|
|
|
GPParamDefEnum m_enum;
|
|
|
|
|
GPParamDefBoolean m_boolean;
|
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
2024-11-02 14:03:37 +01:00
|
|
|
GPParamDefDouble m_double;
|
2024-05-06 18:38:12 +00:00
|
|
|
GPParamDefString m_string;
|
|
|
|
|
GPParamDefGeglColor m_gegl_color;
|
|
|
|
|
GPParamDefID m_id;
|
|
|
|
|
GPParamDefIDArray m_id_array;
|
|
|
|
|
GPParamDefChoice m_choice;
|
2024-09-06 13:38:43 +02:00
|
|
|
GPParamDefResource m_resource;
|
2025-01-22 17:15:28 +01:00
|
|
|
GPParamDefFile m_file;
|
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two
- Change the wire protocol's GPProcInstall to transmit the entire
information needed for constructing all GParamSpecs we use, don't
use GimpPDBArgType in GPProcInstall but an enum private to the wire
protocol plus the GParamSpec's GType name. Bump the wire protocol
version.
- Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which
take care of converting between GPParamDef and GParamSpec. They
share code as far as possible.
- Change pluginrc writing and parsing to re-use GPParamDef and the
utility functions from gimpgpparamspecs.
- Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch],
the entire core uses proper GParamSpecs from the wire protocol now,
the whole file will follow down the drain once we use a GValue
representation on the wire too.
- In gimp_plug_in_handle_proc_install(), change the "run-mode"
parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not
already an enum). and change all places in app/ to treat it as an
enum value.
- plug-ins: fix cml-explorer to register correctly, a typo in
"run-mode" was never noticed until now.
- Add gimpgpcompat.[ch] in libgimp to deal with all the transforms
between old-style wire communication and using GParamSpec and
GValue, it contains some functions that are subject to change or
even removal in the next steps.
- Change the libgimp GimpProcedure and GimpPlugIn in many ways to be
able to actually install procedures the new way.
- plug-ins: change goat-exercise to completely use the new GimpPlugIn
and GimpProcedure API, look here to see how plug-ins will look in
the future, of course subject to change until this is finished.
- Next: changing GPParam to transmit all information about a GValue.
2019-07-27 16:37:55 +02:00
|
|
|
} meta;
|
1997-11-24 22:05:25 +00:00
|
|
|
};
|
|
|
|
|
|
2019-08-04 23:59:25 +02:00
|
|
|
struct _GPParamArray
|
|
|
|
|
{
|
|
|
|
|
guint32 size;
|
|
|
|
|
guint8 *data;
|
|
|
|
|
};
|
|
|
|
|
|
2019-09-05 11:34:54 +02:00
|
|
|
struct _GPParamIDArray
|
|
|
|
|
{
|
|
|
|
|
gchar *type_name;
|
|
|
|
|
guint32 size;
|
|
|
|
|
gint32 *data;
|
|
|
|
|
};
|
|
|
|
|
|
2024-09-20 21:55:21 +02:00
|
|
|
struct _GPParamFormat
|
2023-11-03 21:26:51 +01:00
|
|
|
{
|
|
|
|
|
/* Transferring a BablFormat with the encoding and the ICC data. */
|
|
|
|
|
gchar *encoding;
|
|
|
|
|
guint32 profile_size;
|
|
|
|
|
guint8 *profile_data;
|
|
|
|
|
};
|
|
|
|
|
|
2024-09-20 21:55:21 +02:00
|
|
|
struct _GPParamColor
|
|
|
|
|
{
|
|
|
|
|
guint32 size;
|
|
|
|
|
guint8 data[40];
|
|
|
|
|
|
|
|
|
|
GPParamFormat format;
|
|
|
|
|
};
|
|
|
|
|
|
2023-12-27 01:07:19 +09:00
|
|
|
struct _GPParamColorArray
|
|
|
|
|
{
|
|
|
|
|
guint32 size;
|
|
|
|
|
GPParamColor *colors;
|
|
|
|
|
};
|
|
|
|
|
|
2024-05-06 18:38:12 +00:00
|
|
|
struct _GPParamExportOptions
|
|
|
|
|
{
|
2024-11-01 19:13:02 +01:00
|
|
|
/* XXX: this is an empty shell right now, because there are no export
|
|
|
|
|
* options yet. The capabilities property doesn't need to be passed
|
|
|
|
|
* through the wire because it is set by libgimp, not at run call.
|
|
|
|
|
*/
|
2024-05-06 18:38:12 +00:00
|
|
|
};
|
|
|
|
|
|
2024-11-29 17:37:23 +09:00
|
|
|
struct _GPParamValueArray
|
|
|
|
|
{
|
|
|
|
|
guint32 n_values;
|
|
|
|
|
GPParam *values;
|
|
|
|
|
};
|
|
|
|
|
|
2019-08-04 23:59:25 +02:00
|
|
|
struct _GPParam
|
|
|
|
|
{
|
|
|
|
|
GPParamType param_type;
|
|
|
|
|
gchar *type_name;
|
|
|
|
|
|
|
|
|
|
union
|
|
|
|
|
{
|
2024-05-06 18:38:12 +00:00
|
|
|
gint32 d_int;
|
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
2024-11-02 14:03:37 +01:00
|
|
|
gdouble d_double;
|
2024-05-06 18:38:12 +00:00
|
|
|
gchar *d_string;
|
|
|
|
|
gchar **d_strv;
|
|
|
|
|
GBytes *d_bytes;
|
2024-09-20 21:55:21 +02:00
|
|
|
GPParamFormat d_format;
|
2024-05-06 18:38:12 +00:00
|
|
|
GPParamColor d_gegl_color;
|
|
|
|
|
GPParamColorArray d_color_array;
|
|
|
|
|
GimpParasite d_parasite;
|
|
|
|
|
GPParamArray d_array;
|
|
|
|
|
GPParamIDArray d_id_array;
|
|
|
|
|
GPParamExportOptions d_export_options;
|
|
|
|
|
GPParamDef d_param_def;
|
2024-11-29 17:37:23 +09:00
|
|
|
GPParamValueArray d_value_array;
|
2019-08-04 23:59:25 +02:00
|
|
|
} data;
|
|
|
|
|
};
|
|
|
|
|
|
1997-11-24 22:05:25 +00:00
|
|
|
struct _GPProcRun
|
|
|
|
|
{
|
2000-03-04 00:24:39 +00:00
|
|
|
gchar *name;
|
2019-09-09 01:00:54 +02:00
|
|
|
guint32 n_params;
|
1997-11-24 22:05:25 +00:00
|
|
|
GPParam *params;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct _GPProcReturn
|
|
|
|
|
{
|
2000-03-04 00:24:39 +00:00
|
|
|
gchar *name;
|
2019-09-09 01:00:54 +02:00
|
|
|
guint32 n_params;
|
1997-11-24 22:05:25 +00:00
|
|
|
GPParam *params;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct _GPProcInstall
|
|
|
|
|
{
|
2000-03-04 00:24:39 +00:00
|
|
|
gchar *name;
|
|
|
|
|
guint32 type;
|
2019-09-09 01:00:54 +02:00
|
|
|
guint32 n_params;
|
|
|
|
|
guint32 n_return_vals;
|
1997-11-24 22:05:25 +00:00
|
|
|
GPParamDef *params;
|
|
|
|
|
GPParamDef *return_vals;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct _GPProcUninstall
|
|
|
|
|
{
|
2000-03-04 00:24:39 +00:00
|
|
|
gchar *name;
|
1997-11-24 22:05:25 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
2000-03-04 00:24:39 +00:00
|
|
|
void gp_init (void);
|
|
|
|
|
|
2002-05-16 17:41:38 +00:00
|
|
|
gboolean gp_quit_write (GIOChannel *channel,
|
|
|
|
|
gpointer user_data);
|
2000-03-04 00:24:39 +00:00
|
|
|
gboolean gp_config_write (GIOChannel *channel,
|
2006-04-12 10:53:28 +00:00
|
|
|
GPConfig *config,
|
2002-05-16 17:41:38 +00:00
|
|
|
gpointer user_data);
|
2000-03-04 00:24:39 +00:00
|
|
|
gboolean gp_tile_req_write (GIOChannel *channel,
|
2006-04-12 10:53:28 +00:00
|
|
|
GPTileReq *tile_req,
|
2002-05-16 17:41:38 +00:00
|
|
|
gpointer user_data);
|
|
|
|
|
gboolean gp_tile_ack_write (GIOChannel *channel,
|
|
|
|
|
gpointer user_data);
|
2000-03-04 00:24:39 +00:00
|
|
|
gboolean gp_tile_data_write (GIOChannel *channel,
|
2006-04-12 10:53:28 +00:00
|
|
|
GPTileData *tile_data,
|
2002-05-16 17:41:38 +00:00
|
|
|
gpointer user_data);
|
2000-03-04 00:24:39 +00:00
|
|
|
gboolean gp_proc_run_write (GIOChannel *channel,
|
2006-04-12 10:53:28 +00:00
|
|
|
GPProcRun *proc_run,
|
2002-05-16 17:41:38 +00:00
|
|
|
gpointer user_data);
|
2000-03-04 00:24:39 +00:00
|
|
|
gboolean gp_proc_return_write (GIOChannel *channel,
|
2006-04-12 10:53:28 +00:00
|
|
|
GPProcReturn *proc_return,
|
2002-05-16 17:41:38 +00:00
|
|
|
gpointer user_data);
|
2000-03-04 00:24:39 +00:00
|
|
|
gboolean gp_temp_proc_run_write (GIOChannel *channel,
|
2006-04-12 10:53:28 +00:00
|
|
|
GPProcRun *proc_run,
|
2002-05-16 17:41:38 +00:00
|
|
|
gpointer user_data);
|
2000-03-04 00:24:39 +00:00
|
|
|
gboolean gp_temp_proc_return_write (GIOChannel *channel,
|
2006-04-12 10:53:28 +00:00
|
|
|
GPProcReturn *proc_return,
|
2002-05-16 17:41:38 +00:00
|
|
|
gpointer user_data);
|
2000-03-04 00:24:39 +00:00
|
|
|
gboolean gp_proc_install_write (GIOChannel *channel,
|
2006-04-12 10:53:28 +00:00
|
|
|
GPProcInstall *proc_install,
|
2002-05-16 17:41:38 +00:00
|
|
|
gpointer user_data);
|
2000-03-04 00:24:39 +00:00
|
|
|
gboolean gp_proc_uninstall_write (GIOChannel *channel,
|
2006-04-12 10:53:28 +00:00
|
|
|
GPProcUninstall *proc_uninstall,
|
2002-05-16 17:41:38 +00:00
|
|
|
gpointer user_data);
|
|
|
|
|
gboolean gp_extension_ack_write (GIOChannel *channel,
|
|
|
|
|
gpointer user_data);
|
|
|
|
|
gboolean gp_has_init_write (GIOChannel *channel,
|
|
|
|
|
gpointer user_data);
|
1997-11-24 22:05:25 +00:00
|
|
|
|
|
|
|
|
|
2001-11-22 23:46:13 +00:00
|
|
|
G_END_DECLS
|
2000-05-30 23:38:46 +00:00
|
|
|
|
1997-11-24 22:05:25 +00:00
|
|
|
#endif /* __GIMP_PROTOCOL_H__ */
|