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

1147 lines
65 KiB
C
Raw Permalink Normal View History

libgimp: add gimpprocedure-params.h which looks much like gimpconfig-params.h and contains macros (e.g. GIMP_PROC_ARG_BOOLEAN() and GIMP_PROC_VAL_BOOLEAN()) for all GimpProcedure argument and return value types supported by the protocol, and makes the boilerplate of setting up a procedure more readable and much less indented. This file is C-only and not introspected.
2019-08-19 09:56:20 +02:00
/* LIBGIMP - The GIMP Library
* Copyright (C) 1995 Spencer Kimball and Peter Mattis
*
* gimpprocedure-params.h
* Copyright (C) 2019 Michael Natterer <mitch@gimp.org>
*
* This library is free software: you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 3 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Library General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library. If not, see
* <https://www.gnu.org/licenses/>.
*/
#if !defined (__GIMP_H_INSIDE__) && !defined (GIMP_COMPILATION)
#error "Only <libgimp/gimp.h> can be included directly."
#endif
#ifndef __GIMP_PROCEDURE_PARAMS_H__
#define __GIMP_PROCEDURE_PARAMS_H__
G_BEGIN_DECLS
/* For information look into the C source or the html documentation */
/**
* SECTION: gimpprocedure-params
* @title: GimpProcedure-params
* @short_description: Macros and defines to add procedure arguments
* and return values.
*
* Macros and defines to add procedure arguments and return values.
**/
libgimp: add a gazillion of macros to gimpprocedure-params.h that make dealing with value arrays easier and shorter, e.g. g_value_get_boolean (gimp_value_array_index (args, n)): becomes: GIMP_VALUES_GET_BOOLEAN (args, n);
2019-08-20 01:00:47 +02:00
/* boolean */
#define GIMP_VALUES_GET_BOOLEAN(args, n) \
g_value_get_boolean (gimp_value_array_index (args, n))
#define GIMP_VALUES_SET_BOOLEAN(args, n, value) \
g_value_set_boolean (gimp_value_array_index (args, n), value)
/* int */
#define GIMP_VALUES_GET_INT(args, n) \
g_value_get_int (gimp_value_array_index (args, n))
#define GIMP_VALUES_SET_INT(args, n, value) \
g_value_set_int (gimp_value_array_index (args, n), value)
/* uint */
libgimp: add missing stuff to gimpprocedure-params.h Add some accessors, and the complete set of macros for GimpParasite and GParamSpec.
2019-09-04 02:39:02 +02:00
#define GIMP_VALUES_GET_UINT(args, n) \
g_value_get_uint (gimp_value_array_index (args, n))
#define GIMP_VALUES_SET_UINT(args, n, value) \
g_value_set_uint (gimp_value_array_index (args, n), value)
libgimp: add a gazillion of macros to gimpprocedure-params.h that make dealing with value arrays easier and shorter, e.g. g_value_get_boolean (gimp_value_array_index (args, n)): becomes: GIMP_VALUES_GET_BOOLEAN (args, n);
2019-08-20 01:00:47 +02:00
/* uchar */
#define GIMP_VALUES_GET_UCHAR(args, n) \
g_value_get_uchar (gimp_value_array_index (args, n))
#define GIMP_VALUES_SET_UCHAR(args, n, value) \
g_value_set_uchar (gimp_value_array_index (args, n), value)
/* double */
#define GIMP_VALUES_GET_DOUBLE(args, n) \
g_value_get_double (gimp_value_array_index (args, n))
#define GIMP_VALUES_SET_DOUBLE(args, n, value) \
g_value_set_double (gimp_value_array_index (args, n), value)
/* enum */
#define GIMP_VALUES_GET_ENUM(args, n) \
g_value_get_enum (gimp_value_array_index (args, n))
#define GIMP_VALUES_SET_ENUM(args, n, value) \
g_value_set_enum (gimp_value_array_index (args, n), value)
app, libgimp: new GimpChoice procedure argument. These will replace the int arguments used in place of enums. The problem of int arguments used as list of choices is that it makes calling PDB functions very opaque. This is especially bad when a list is long, so you constantly have to refer to the documentation to understand what a series of numbers mean in argument lists. And the second issue is that plug-in developers have to manually maintain a list of values both in the GUI and in the documentation string. This help text may get out-of-sync, may end up with missing values or whatnot. Also if it is used as tooltips, it makes for very weird tooltips in the graphical interface, with an overlong technical list of int-values mapping which should ideally only be made visible in the PDB procedure browser listing.
2023-08-02 23:55:33 +02:00
/* choice */
#define GIMP_VALUES_GET_CHOICE(args, n) \
g_value_get_int (gimp_value_array_index (args, n))
#define GIMP_VALUES_SET_CHOICE(args, n, value) \
g_value_set_int (gimp_value_array_index (args, n), value)
libgimp: add a gazillion of macros to gimpprocedure-params.h that make dealing with value arrays easier and shorter, e.g. g_value_get_boolean (gimp_value_array_index (args, n)): becomes: GIMP_VALUES_GET_BOOLEAN (args, n);
2019-08-20 01:00:47 +02:00
/* string */
#define GIMP_VALUES_GET_STRING(args, n) \
g_value_get_string (gimp_value_array_index (args, n))
#define GIMP_VALUES_DUP_STRING(args, n) \
g_value_dup_string (gimp_value_array_index (args, n))
#define GIMP_VALUES_SET_STRING(args, n, value) \
g_value_set_string (gimp_value_array_index (args, n), value)
#define GIMP_VALUES_TAKE_STRING(args, n, value) \
g_value_take_string (gimp_value_array_index (args, n), value)
libgimp: add macros for GeglColor arguments for GimpProcedure.
2024-02-14 23:46:03 +01:00
/* color */
/* TODO:
* 1. has_alpha is currently bogus and doesn't do anything yet.
* 2. Also wouldn't none_ok be useful for color arguments (accepting a NULL
* GeglColor)?
* 3. GEGL also provides a gegl_param_spec_color_from_string() allowing to
* initialize the default with a list of standard colors. Wouldn't it be
* interesting to also have this?
*/
#define GIMP_VALUES_GET_COLOR(args, n, value) \
g_value_get_object (gimp_value_array_index (args, n), value)
#define GIMP_VALUES_SET_COLOR(args, n, value) \
g_value_set_object (gimp_value_array_index (args, n), value)
libgimp: add missing stuff to gimpprocedure-params.h Add some accessors, and the complete set of macros for GimpParasite and GParamSpec.
2019-09-04 02:39:02 +02:00
/* parasite */
#define GIMP_VALUES_GET_PARASITE(args, n) \
g_value_get_boxed (gimp_value_array_index (args, n))
#define GIMP_VALUES_DUP_PARASITE(args, n) \
g_value_dup_boxed (gimp_value_array_index (args, n))
#define GIMP_VALUES_SET_PARASITE(args, n, value) \
g_value_set_boxed (gimp_value_array_index (args, n), value)
#define GIMP_VALUES_TAKE_PARASITE(args, n, value) \
g_value_take_boxed (gimp_value_array_index (args, n), value)
/* param */
#define GIMP_VALUES_GET_PARAM(args, n) \
g_value_get_param (gimp_value_array_index (args, n))
#define GIMP_VALUES_DUP_PARAM(args, n) \
g_value_dup_param (gimp_value_array_index (args, n))
#define GIMP_VALUES_SET_PARAM(args, n, value) \
g_value_set_param (gimp_value_array_index (args, n), value)
#define GIMP_VALUES_TAKE_PARAM(args, n, value) \
g_value_take_param (gimp_value_array_index (args, n), value)
Remove GimpUint8Array in favor of GBytes GLib has a specific type for byte arrays: `GBytes` (and it's underlying GType `G_TYPE_BYTES`). By using this type, we can avoid having a `GimpUint8Array` which is a bit cumbersome to use for both the C API, as well as bindings. By using `GBytes`, we allow other languages to pass on byte arrays as they are used to, while the bindings will make sure to do the right thing. In the end, it makes the API a little bit simpler for everyone, and reduces confusion for people who are used to working with byte arrays in other C/GLib based code (and not having 2 different types to denote the same thing). Related: https://gitlab.gnome.org/GNOME/gimp/-/issues/5919
2023-05-23 23:37:46 +02:00
/* bytes */
libgimp: add a gazillion of macros to gimpprocedure-params.h that make dealing with value arrays easier and shorter, e.g. g_value_get_boolean (gimp_value_array_index (args, n)): becomes: GIMP_VALUES_GET_BOOLEAN (args, n);
2019-08-20 01:00:47 +02:00
Remove GimpUint8Array in favor of GBytes GLib has a specific type for byte arrays: `GBytes` (and it's underlying GType `G_TYPE_BYTES`). By using this type, we can avoid having a `GimpUint8Array` which is a bit cumbersome to use for both the C API, as well as bindings. By using `GBytes`, we allow other languages to pass on byte arrays as they are used to, while the bindings will make sure to do the right thing. In the end, it makes the API a little bit simpler for everyone, and reduces confusion for people who are used to working with byte arrays in other C/GLib based code (and not having 2 different types to denote the same thing). Related: https://gitlab.gnome.org/GNOME/gimp/-/issues/5919
2023-05-23 23:37:46 +02:00
#define GIMP_VALUES_GET_BYTES(args, n) \
g_value_get_boxed (gimp_value_array_index (args, n))
libgimp: add a gazillion of macros to gimpprocedure-params.h that make dealing with value arrays easier and shorter, e.g. g_value_get_boolean (gimp_value_array_index (args, n)): becomes: GIMP_VALUES_GET_BOOLEAN (args, n);
2019-08-20 01:00:47 +02:00
Remove GimpUint8Array in favor of GBytes GLib has a specific type for byte arrays: `GBytes` (and it's underlying GType `G_TYPE_BYTES`). By using this type, we can avoid having a `GimpUint8Array` which is a bit cumbersome to use for both the C API, as well as bindings. By using `GBytes`, we allow other languages to pass on byte arrays as they are used to, while the bindings will make sure to do the right thing. In the end, it makes the API a little bit simpler for everyone, and reduces confusion for people who are used to working with byte arrays in other C/GLib based code (and not having 2 different types to denote the same thing). Related: https://gitlab.gnome.org/GNOME/gimp/-/issues/5919
2023-05-23 23:37:46 +02:00
#define GIMP_VALUES_DUP_BYTES(args, n) \
g_value_dup_boxed (gimp_value_array_index (args, n))
libgimp: add a gazillion of macros to gimpprocedure-params.h that make dealing with value arrays easier and shorter, e.g. g_value_get_boolean (gimp_value_array_index (args, n)): becomes: GIMP_VALUES_GET_BOOLEAN (args, n);
2019-08-20 01:00:47 +02:00
app, libgimp*, pdb, plug-ins: reimplement generic inter-process transient window. Having windows ID as guint32 is a mistake. Different systems have different protocols. In Wayland in particular, Windows handles are exchanged as strings. What this commit does is the following: In core: - get_window_id() virtual function in core GimpProgress is changed to return a GBytes, as a generic "data" to represent a window differently on different systems. - All implementations of get_window_id() in various classes implementing this interface are updated accordingly: * GimpSubProgress * GimpDisplay returns the handle of its shell. * GimpDisplayShell now creates its window handle at construction with libgimpwidget's gimp_widget_set_native_handle() and simply return this handle every time it's requested. * GimpFileDialog also creates its window handle at construction with gimp_widget_set_native_handle(). - gimp_window_set_transient_for() in core is changed to take a GimpProgress as argument (instead of a guint32 ID), requests and process the ID itself, according to the running platform. In particular, the following were improved: * Unlike old code, it will work even if the window is not visible yet. In such a case, the function simply adds a signal handler to set transient at mapping. It makes it easier to use it at construction in a reliable way. * It now works for Wayland too, additionally to X11. - GimpPdbProgress now exchanges a GBytes too with the command GIMP_PROGRESS_COMMAND_GET_WINDOW. - display_get_window_id() in gimp-gui.h also returns a GBytes now. PDB/libgimp: - gimp_display_get_window_handle() and gimp_progress_get_window_handle() now return a GBytes to represent a window handle in an opaque way (depending on the running platform). In libgimp: - GimpProgress's get_window() virtual function changed to return a GBytes and renamed get_window_handle(). - In particular GimpProgressBar is the only implementation of get_window_handle(). It creates its handle at object construction with libgimpwidget's gimp_widget_set_native_handle() and the virtual method's implementation simply returns the GBytes. In libgimpUi: - gimp_ui_get_display_window() and gimp_ui_get_progress_window() were removed. We should not assume anymore that it is possible to create a GdkWindow to be used. For instance this is not possible with Wayland which has its own way to set a window transient with a string handle. - gimp_window_set_transient_for_display() and gimp_window_set_transient() now use an internal implementation similar to core gimp_window_set_transient_for(), with the same improvements (works even at construction when the window is not visible yet + works for Wayland too). In libgimpwidgets: - New gimp_widget_set_native_handle() is a helper function used both in core and libgimp* libraries for widgets which we want to be usable as possible parents. It takes care of getting the relevant window handle (depending on the running platform) and stores it in a given pointer, either immediately or after a callback once the widget is mapped. So it can be used at construction. Also it sets a handle for X11 or Wayland. In plug-ins: - Screenshot uses the new gimp_progress_get_window_handle() directly now in its X11 code path and creates out of it a GdkWindows itself with gdk_x11_window_foreign_new_for_display(). Our inter-process transient implementation only worked for X11, and with this commit, it works for Wayland too. There is code for Windows but it is currently disabled as it apparently hangs (there is a comment in-code which links to this old report: https://bugzilla.gnome.org/show_bug.cgi?id=359538). NikcDC tested yesterday with re-enabling the code and said they experienced a freeze. ;-( Finally there is no infrastructure yet to make this work on macOS and apparently there is no implementation of window handle in GDK for macOS that I could find. I'm not sure if macOS doesn't have this concept of setting transient on another processus's window or GDK is simply lacking the implementation.
2023-08-14 14:23:06 +02:00
#define GIMP_VALUES_SET_BYTES(args, n, value) \
Remove GimpUint8Array in favor of GBytes GLib has a specific type for byte arrays: `GBytes` (and it's underlying GType `G_TYPE_BYTES`). By using this type, we can avoid having a `GimpUint8Array` which is a bit cumbersome to use for both the C API, as well as bindings. By using `GBytes`, we allow other languages to pass on byte arrays as they are used to, while the bindings will make sure to do the right thing. In the end, it makes the API a little bit simpler for everyone, and reduces confusion for people who are used to working with byte arrays in other C/GLib based code (and not having 2 different types to denote the same thing). Related: https://gitlab.gnome.org/GNOME/gimp/-/issues/5919
2023-05-23 23:37:46 +02:00
g_value_set_boxed (gimp_value_array_index (args, n), value)
libgimp: add a gazillion of macros to gimpprocedure-params.h that make dealing with value arrays easier and shorter, e.g. g_value_get_boolean (gimp_value_array_index (args, n)): becomes: GIMP_VALUES_GET_BOOLEAN (args, n);
2019-08-20 01:00:47 +02:00
Remove GimpUint8Array in favor of GBytes GLib has a specific type for byte arrays: `GBytes` (and it's underlying GType `G_TYPE_BYTES`). By using this type, we can avoid having a `GimpUint8Array` which is a bit cumbersome to use for both the C API, as well as bindings. By using `GBytes`, we allow other languages to pass on byte arrays as they are used to, while the bindings will make sure to do the right thing. In the end, it makes the API a little bit simpler for everyone, and reduces confusion for people who are used to working with byte arrays in other C/GLib based code (and not having 2 different types to denote the same thing). Related: https://gitlab.gnome.org/GNOME/gimp/-/issues/5919
2023-05-23 23:37:46 +02:00
#define GIMP_VALUES_TAKE_BYTES(args, n, value, length) \
g_value_take_boxed (gimp_value_array_index (args, n), value)
libgimp: add a gazillion of macros to gimpprocedure-params.h that make dealing with value arrays easier and shorter, e.g. g_value_get_boolean (gimp_value_array_index (args, n)): becomes: GIMP_VALUES_GET_BOOLEAN (args, n);
2019-08-20 01:00:47 +02:00
/* 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 09:48:14 +02:00
#define GIMP_VALUES_GET_INT32_ARRAY(args, n, length) \
gimp_value_get_int32_array (gimp_value_array_index (args, n), length)
libgimp: add a gazillion of macros to gimpprocedure-params.h that make dealing with value arrays easier and shorter, e.g. g_value_get_boolean (gimp_value_array_index (args, n)): becomes: GIMP_VALUES_GET_BOOLEAN (args, n);
2019-08-20 01:00:47 +02: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 09:48:14 +02:00
#define GIMP_VALUES_DUP_INT32_ARRAY(args, n, length) \
gimp_value_dup_int32_array (gimp_value_array_index (args, n), length)
libgimp: add a gazillion of macros to gimpprocedure-params.h that make dealing with value arrays easier and shorter, e.g. g_value_get_boolean (gimp_value_array_index (args, n)): becomes: GIMP_VALUES_GET_BOOLEAN (args, n);
2019-08-20 01:00:47 +02:00
libgimp: fix GIMP_VALUES_(SET|TAKE)_*_ARRAY() macros. A length argument is required by corresponding gimp_value_set_*_array() functions.
2019-08-30 00:32:18 +02:00
#define GIMP_VALUES_SET_INT32_ARRAY(args, n, value, length) \
gimp_value_set_int32_array (gimp_value_array_index (args, n), value, length)
libgimp: add a gazillion of macros to gimpprocedure-params.h that make dealing with value arrays easier and shorter, e.g. g_value_get_boolean (gimp_value_array_index (args, n)): becomes: GIMP_VALUES_GET_BOOLEAN (args, n);
2019-08-20 01:00:47 +02:00
libgimp: fix GIMP_VALUES_(SET|TAKE)_*_ARRAY() macros. A length argument is required by corresponding gimp_value_set_*_array() functions.
2019-08-30 00:32:18 +02:00
#define GIMP_VALUES_TAKE_INT32_ARRAY(args, n, value, length) \
gimp_value_take_int32_array (gimp_value_array_index (args, n), value, length)
libgimp: add a gazillion of macros to gimpprocedure-params.h that make dealing with value arrays easier and shorter, e.g. g_value_get_boolean (gimp_value_array_index (args, n)): becomes: GIMP_VALUES_GET_BOOLEAN (args, n);
2019-08-20 01:00:47 +02:00
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/. Several types functions were using the wording "float" historically to mean double-precision, e.g. the float array type (which was in fact a double array). Or the scanner function gimp_scanner_parse_float() was in fact returning a double value. What if we wanted someday to actually add float (usually this naming means in C the single-precision IEEE 754 floating point representation) support? How would we name this? Now technically it's not entirely wrong (a double is still a floating point). So I've been wondering if that is because maybe we never planned to have float and double precision may be good enough for all usage in a plug-in API (which doesn't have to be as generic so the higher precision is enough)? But how can we be sure? Also we already had some functions using the wording double (e.g. gimp_procedure_add_double_argument()), so let's just go the safe route and use the accurate wording. The additional change in PDB is internal, but there too, I was also finding very confusing that we were naming double-precision float as 'float' type. So I took the opportunity to update this. It doesn't change any signature. In fact the whole commit doesn't change any type or code logic, only naming, except for one bug fix in the middle which I encountered while renaming: in gimp_scanner_parse_deprecated_color(), I discovered a hidden bug in scanning (color-hsv*) values, which was mistakenly using a double type for an array of float.
2024-11-02 14:03:37 +01:00
/* double array */
libgimp: add a gazillion of macros to gimpprocedure-params.h that make dealing with value arrays easier and shorter, e.g. g_value_get_boolean (gimp_value_array_index (args, n)): becomes: GIMP_VALUES_GET_BOOLEAN (args, n);
2019-08-20 01:00:47 +02:00
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/. Several types functions were using the wording "float" historically to mean double-precision, e.g. the float array type (which was in fact a double array). Or the scanner function gimp_scanner_parse_float() was in fact returning a double value. What if we wanted someday to actually add float (usually this naming means in C the single-precision IEEE 754 floating point representation) support? How would we name this? Now technically it's not entirely wrong (a double is still a floating point). So I've been wondering if that is because maybe we never planned to have float and double precision may be good enough for all usage in a plug-in API (which doesn't have to be as generic so the higher precision is enough)? But how can we be sure? Also we already had some functions using the wording double (e.g. gimp_procedure_add_double_argument()), so let's just go the safe route and use the accurate wording. The additional change in PDB is internal, but there too, I was also finding very confusing that we were naming double-precision float as 'float' type. So I took the opportunity to update this. It doesn't change any signature. In fact the whole commit doesn't change any type or code logic, only naming, except for one bug fix in the middle which I encountered while renaming: in gimp_scanner_parse_deprecated_color(), I discovered a hidden bug in scanning (color-hsv*) values, which was mistakenly using a double type for an array of float.
2024-11-02 14:03:37 +01:00
#define GIMP_VALUES_GET_DOUBLE_ARRAY(args, n, length) \
gimp_value_get_double_array (gimp_value_array_index (args, n), length)
libgimp: add a gazillion of macros to gimpprocedure-params.h that make dealing with value arrays easier and shorter, e.g. g_value_get_boolean (gimp_value_array_index (args, n)): becomes: GIMP_VALUES_GET_BOOLEAN (args, n);
2019-08-20 01:00:47 +02:00
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/. Several types functions were using the wording "float" historically to mean double-precision, e.g. the float array type (which was in fact a double array). Or the scanner function gimp_scanner_parse_float() was in fact returning a double value. What if we wanted someday to actually add float (usually this naming means in C the single-precision IEEE 754 floating point representation) support? How would we name this? Now technically it's not entirely wrong (a double is still a floating point). So I've been wondering if that is because maybe we never planned to have float and double precision may be good enough for all usage in a plug-in API (which doesn't have to be as generic so the higher precision is enough)? But how can we be sure? Also we already had some functions using the wording double (e.g. gimp_procedure_add_double_argument()), so let's just go the safe route and use the accurate wording. The additional change in PDB is internal, but there too, I was also finding very confusing that we were naming double-precision float as 'float' type. So I took the opportunity to update this. It doesn't change any signature. In fact the whole commit doesn't change any type or code logic, only naming, except for one bug fix in the middle which I encountered while renaming: in gimp_scanner_parse_deprecated_color(), I discovered a hidden bug in scanning (color-hsv*) values, which was mistakenly using a double type for an array of float.
2024-11-02 14:03:37 +01:00
#define GIMP_VALUES_DUP_DOUBLE_ARRAY(args, n, length) \
gimp_value_dup_double_array (gimp_value_array_index (args, n), length)
libgimp: add a gazillion of macros to gimpprocedure-params.h that make dealing with value arrays easier and shorter, e.g. g_value_get_boolean (gimp_value_array_index (args, n)): becomes: GIMP_VALUES_GET_BOOLEAN (args, n);
2019-08-20 01:00:47 +02:00
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/. Several types functions were using the wording "float" historically to mean double-precision, e.g. the float array type (which was in fact a double array). Or the scanner function gimp_scanner_parse_float() was in fact returning a double value. What if we wanted someday to actually add float (usually this naming means in C the single-precision IEEE 754 floating point representation) support? How would we name this? Now technically it's not entirely wrong (a double is still a floating point). So I've been wondering if that is because maybe we never planned to have float and double precision may be good enough for all usage in a plug-in API (which doesn't have to be as generic so the higher precision is enough)? But how can we be sure? Also we already had some functions using the wording double (e.g. gimp_procedure_add_double_argument()), so let's just go the safe route and use the accurate wording. The additional change in PDB is internal, but there too, I was also finding very confusing that we were naming double-precision float as 'float' type. So I took the opportunity to update this. It doesn't change any signature. In fact the whole commit doesn't change any type or code logic, only naming, except for one bug fix in the middle which I encountered while renaming: in gimp_scanner_parse_deprecated_color(), I discovered a hidden bug in scanning (color-hsv*) values, which was mistakenly using a double type for an array of float.
2024-11-02 14:03:37 +01:00
#define GIMP_VALUES_SET_DOUBLE_ARRAY(args, n, value, length) \
gimp_value_set_double_array (gimp_value_array_index (args, n), value, length)
libgimp: add a gazillion of macros to gimpprocedure-params.h that make dealing with value arrays easier and shorter, e.g. g_value_get_boolean (gimp_value_array_index (args, n)): becomes: GIMP_VALUES_GET_BOOLEAN (args, n);
2019-08-20 01:00:47 +02:00
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/. Several types functions were using the wording "float" historically to mean double-precision, e.g. the float array type (which was in fact a double array). Or the scanner function gimp_scanner_parse_float() was in fact returning a double value. What if we wanted someday to actually add float (usually this naming means in C the single-precision IEEE 754 floating point representation) support? How would we name this? Now technically it's not entirely wrong (a double is still a floating point). So I've been wondering if that is because maybe we never planned to have float and double precision may be good enough for all usage in a plug-in API (which doesn't have to be as generic so the higher precision is enough)? But how can we be sure? Also we already had some functions using the wording double (e.g. gimp_procedure_add_double_argument()), so let's just go the safe route and use the accurate wording. The additional change in PDB is internal, but there too, I was also finding very confusing that we were naming double-precision float as 'float' type. So I took the opportunity to update this. It doesn't change any signature. In fact the whole commit doesn't change any type or code logic, only naming, except for one bug fix in the middle which I encountered while renaming: in gimp_scanner_parse_deprecated_color(), I discovered a hidden bug in scanning (color-hsv*) values, which was mistakenly using a double type for an array of float.
2024-11-02 14:03:37 +01:00
#define GIMP_VALUES_TAKE_DOUBLE_ARRAY(args, n, value, length) \
gimp_value_take_double_array (gimp_value_array_index (args, n), value, length)
libgimp: add a gazillion of macros to gimpprocedure-params.h that make dealing with value arrays easier and shorter, e.g. g_value_get_boolean (gimp_value_array_index (args, n)): becomes: GIMP_VALUES_GET_BOOLEAN (args, n);
2019-08-20 01:00:47 +02:00
Remove GimpStringArray in favor of GStrv GLib has a specific type of NULL-terminated string arrays: `G_TYPE_STRV`, which is the `GType` of `char**` aka `GStrv`. By using this type, we can avoid having a `GimpStringArray` which is a bit cumbersome to use for both the C API, as well as bindings. By using `GStrv`, we allow other languages to pass on string lists as they are used to, while the bindings will make sure to do the right thing. In the end, it makes the API a little bit simpler for everyone, and reduces confusion for people who are used to working with string arrays in other C/GLib based code (and not having 2 different types to denote the same thing). Related: https://gitlab.gnome.org/GNOME/gimp/-/issues/5919
2020-12-23 21:15:43 +01:00
/* string array (strv) */
libgimp: add a gazillion of macros to gimpprocedure-params.h that make dealing with value arrays easier and shorter, e.g. g_value_get_boolean (gimp_value_array_index (args, n)): becomes: GIMP_VALUES_GET_BOOLEAN (args, n);
2019-08-20 01:00:47 +02:00
Remove GimpStringArray in favor of GStrv GLib has a specific type of NULL-terminated string arrays: `G_TYPE_STRV`, which is the `GType` of `char**` aka `GStrv`. By using this type, we can avoid having a `GimpStringArray` which is a bit cumbersome to use for both the C API, as well as bindings. By using `GStrv`, we allow other languages to pass on string lists as they are used to, while the bindings will make sure to do the right thing. In the end, it makes the API a little bit simpler for everyone, and reduces confusion for people who are used to working with string arrays in other C/GLib based code (and not having 2 different types to denote the same thing). Related: https://gitlab.gnome.org/GNOME/gimp/-/issues/5919
2020-12-23 21:15:43 +01:00
#define GIMP_VALUES_GET_STRV(args, n) \
g_value_get_boxed (gimp_value_array_index (args, n))
libgimp: add a gazillion of macros to gimpprocedure-params.h that make dealing with value arrays easier and shorter, e.g. g_value_get_boolean (gimp_value_array_index (args, n)): becomes: GIMP_VALUES_GET_BOOLEAN (args, n);
2019-08-20 01:00:47 +02:00
Remove GimpStringArray in favor of GStrv GLib has a specific type of NULL-terminated string arrays: `G_TYPE_STRV`, which is the `GType` of `char**` aka `GStrv`. By using this type, we can avoid having a `GimpStringArray` which is a bit cumbersome to use for both the C API, as well as bindings. By using `GStrv`, we allow other languages to pass on string lists as they are used to, while the bindings will make sure to do the right thing. In the end, it makes the API a little bit simpler for everyone, and reduces confusion for people who are used to working with string arrays in other C/GLib based code (and not having 2 different types to denote the same thing). Related: https://gitlab.gnome.org/GNOME/gimp/-/issues/5919
2020-12-23 21:15:43 +01:00
#define GIMP_VALUES_DUP_STRV(args, n) \
g_value_dup_boxed (gimp_value_array_index (args, n))
libgimp: add a gazillion of macros to gimpprocedure-params.h that make dealing with value arrays easier and shorter, e.g. g_value_get_boolean (gimp_value_array_index (args, n)): becomes: GIMP_VALUES_GET_BOOLEAN (args, n);
2019-08-20 01:00:47 +02:00
Remove GimpStringArray in favor of GStrv GLib has a specific type of NULL-terminated string arrays: `G_TYPE_STRV`, which is the `GType` of `char**` aka `GStrv`. By using this type, we can avoid having a `GimpStringArray` which is a bit cumbersome to use for both the C API, as well as bindings. By using `GStrv`, we allow other languages to pass on string lists as they are used to, while the bindings will make sure to do the right thing. In the end, it makes the API a little bit simpler for everyone, and reduces confusion for people who are used to working with string arrays in other C/GLib based code (and not having 2 different types to denote the same thing). Related: https://gitlab.gnome.org/GNOME/gimp/-/issues/5919
2020-12-23 21:15:43 +01:00
#define GIMP_VALUES_SET_STRV(args, n, value) \
g_value_set_boxed (gimp_value_array_index (args, n), value)
libgimp: add a gazillion of macros to gimpprocedure-params.h that make dealing with value arrays easier and shorter, e.g. g_value_get_boolean (gimp_value_array_index (args, n)): becomes: GIMP_VALUES_GET_BOOLEAN (args, n);
2019-08-20 01:00:47 +02:00
Remove GimpStringArray in favor of GStrv GLib has a specific type of NULL-terminated string arrays: `G_TYPE_STRV`, which is the `GType` of `char**` aka `GStrv`. By using this type, we can avoid having a `GimpStringArray` which is a bit cumbersome to use for both the C API, as well as bindings. By using `GStrv`, we allow other languages to pass on string lists as they are used to, while the bindings will make sure to do the right thing. In the end, it makes the API a little bit simpler for everyone, and reduces confusion for people who are used to working with string arrays in other C/GLib based code (and not having 2 different types to denote the same thing). Related: https://gitlab.gnome.org/GNOME/gimp/-/issues/5919
2020-12-23 21:15:43 +01:00
#define GIMP_VALUES_TAKE_STRV(args, n, value) \
g_value_take_boxed (gimp_value_array_index (args, n), value)
libgimp: add a gazillion of macros to gimpprocedure-params.h that make dealing with value arrays easier and shorter, e.g. g_value_get_boolean (gimp_value_array_index (args, n)): becomes: GIMP_VALUES_GET_BOOLEAN (args, n);
2019-08-20 01:00:47 +02:00
libgimp: add object array convenience macros to gimpprocedure-params.h
2019-09-05 11:40:29 +02:00
/* object array */
app, libgimp*, plug-ins: move all GimpObjectArray procedure args to GimpCoreObjectArray.
2024-10-22 22:46:21 +02:00
#define GIMP_VALUES_GET_CORE_OBJECT_ARRAY(args, n) \
(gpointer) g_value_get_boxed (gimp_value_array_index (args, n))
#define GIMP_VALUES_DUP_CORE_OBJECT_ARRAY(args, n) \
(gpointer) g_value_dup_boxed (gimp_value_array_index (args, n))
#define GIMP_VALUES_SET_CORE_OBJECT_ARRAY(args, n, value) \
g_value_set_boxed (gimp_value_array_index (args, n), (gconstpointer) value)
#define GIMP_VALUES_TAKE_CORE_OBJECT_ARRAY(args, n, value) \
g_value_take_boxed (gimp_value_array_index (args, n), (gconstpointer) value)
libgimp: add a gazillion of macros to gimpprocedure-params.h that make dealing with value arrays easier and shorter, e.g. g_value_get_boolean (gimp_value_array_index (args, n)): becomes: GIMP_VALUES_GET_BOOLEAN (args, n);
2019-08-20 01:00:47 +02:00
/* display */
libgimp: add missing stuff to gimpprocedure-params.h Add some accessors, and the complete set of macros for GimpParasite and GParamSpec.
2019-09-04 02:39:02 +02:00
#define GIMP_VALUES_GET_DISPLAY(args, n) \
g_value_get_object (gimp_value_array_index (args, n))
libgimp: add convenience macros GIMP_VALUES_GET_FOO_ID() becuse some plug-ins really want the ID for good reasons and not the object, and code looks so much nicer when the entire list of arguments is extracted using the macros.
2019-09-05 13:22:37 +02:00
#define GIMP_VALUES_GET_DISPLAY_ID(args, n) \
gimp_display_get_id (g_value_get_object (gimp_value_array_index (args, n)))
libgimp: add missing stuff to gimpprocedure-params.h Add some accessors, and the complete set of macros for GimpParasite and GParamSpec.
2019-09-04 02:39:02 +02:00
#define GIMP_VALUES_SET_DISPLAY(args, n, value) \
g_value_set_object (gimp_value_array_index (args, n), value)
libgimp: add a gazillion of macros to gimpprocedure-params.h that make dealing with value arrays easier and shorter, e.g. g_value_get_boolean (gimp_value_array_index (args, n)): becomes: GIMP_VALUES_GET_BOOLEAN (args, n);
2019-08-20 01:00:47 +02:00
/* image */
#define GIMP_VALUES_GET_IMAGE(args, n) \
libgimp: GimpSaveProcedure() now uses GimpImage/GimpDrawable object... ... as parameters. And GimpLoadProcedure() now expects the run() function to return a GimpImage object.
2019-08-14 14:59:40 +02:00
g_value_get_object (gimp_value_array_index (args, n))
libgimp: add a gazillion of macros to gimpprocedure-params.h that make dealing with value arrays easier and shorter, e.g. g_value_get_boolean (gimp_value_array_index (args, n)): becomes: GIMP_VALUES_GET_BOOLEAN (args, n);
2019-08-20 01:00:47 +02:00
libgimp: add convenience macros GIMP_VALUES_GET_FOO_ID() becuse some plug-ins really want the ID for good reasons and not the object, and code looks so much nicer when the entire list of arguments is extracted using the macros.
2019-09-05 13:22:37 +02:00
#define GIMP_VALUES_GET_IMAGE_ID(args, n) \
gimp_image_get_id (g_value_get_object (gimp_value_array_index (args, n)))
libgimp: add a gazillion of macros to gimpprocedure-params.h that make dealing with value arrays easier and shorter, e.g. g_value_get_boolean (gimp_value_array_index (args, n)): becomes: GIMP_VALUES_GET_BOOLEAN (args, n);
2019-08-20 01:00:47 +02:00
#define GIMP_VALUES_SET_IMAGE(args, n, value) \
libgimp: GimpSaveProcedure() now uses GimpImage/GimpDrawable object... ... as parameters. And GimpLoadProcedure() now expects the run() function to return a GimpImage object.
2019-08-14 14:59:40 +02:00
g_value_set_object (gimp_value_array_index (args, n), value)
libgimp: add a gazillion of macros to gimpprocedure-params.h that make dealing with value arrays easier and shorter, e.g. g_value_get_boolean (gimp_value_array_index (args, n)): becomes: GIMP_VALUES_GET_BOOLEAN (args, n);
2019-08-20 01:00:47 +02:00
/* item */
#define GIMP_VALUES_GET_ITEM(args, n) \
libgimp: GimpSaveProcedure() now uses GimpImage/GimpDrawable object... ... as parameters. And GimpLoadProcedure() now expects the run() function to return a GimpImage object.
2019-08-14 14:59:40 +02:00
g_value_get_object (gimp_value_array_index (args, n))
libgimp: add a gazillion of macros to gimpprocedure-params.h that make dealing with value arrays easier and shorter, e.g. g_value_get_boolean (gimp_value_array_index (args, n)): becomes: GIMP_VALUES_GET_BOOLEAN (args, n);
2019-08-20 01:00:47 +02:00
libgimp: add convenience macros GIMP_VALUES_GET_FOO_ID() becuse some plug-ins really want the ID for good reasons and not the object, and code looks so much nicer when the entire list of arguments is extracted using the macros.
2019-09-05 13:22:37 +02:00
#define GIMP_VALUES_GET_ITEM_ID(args, n) \
gimp_item_get_id (g_value_get_object (gimp_value_array_index (args, n)))
libgimp: add a gazillion of macros to gimpprocedure-params.h that make dealing with value arrays easier and shorter, e.g. g_value_get_boolean (gimp_value_array_index (args, n)): becomes: GIMP_VALUES_GET_BOOLEAN (args, n);
2019-08-20 01:00:47 +02:00
#define GIMP_VALUES_SET_ITEM(args, n, value) \
libgimp: GimpSaveProcedure() now uses GimpImage/GimpDrawable object... ... as parameters. And GimpLoadProcedure() now expects the run() function to return a GimpImage object.
2019-08-14 14:59:40 +02:00
g_value_set_object (gimp_value_array_index (args, n), value)
libgimp: add a gazillion of macros to gimpprocedure-params.h that make dealing with value arrays easier and shorter, e.g. g_value_get_boolean (gimp_value_array_index (args, n)): becomes: GIMP_VALUES_GET_BOOLEAN (args, n);
2019-08-20 01:00:47 +02:00
/* drawable */
#define GIMP_VALUES_GET_DRAWABLE(args, n) \
libgimp: GimpSaveProcedure() now uses GimpImage/GimpDrawable object... ... as parameters. And GimpLoadProcedure() now expects the run() function to return a GimpImage object.
2019-08-14 14:59:40 +02:00
g_value_get_object (gimp_value_array_index (args, n))
libgimp: add a gazillion of macros to gimpprocedure-params.h that make dealing with value arrays easier and shorter, e.g. g_value_get_boolean (gimp_value_array_index (args, n)): becomes: GIMP_VALUES_GET_BOOLEAN (args, n);
2019-08-20 01:00:47 +02:00
libgimp: add convenience macros GIMP_VALUES_GET_FOO_ID() becuse some plug-ins really want the ID for good reasons and not the object, and code looks so much nicer when the entire list of arguments is extracted using the macros.
2019-09-05 13:22:37 +02:00
#define GIMP_VALUES_GET_DRAWABLE_ID(args, n) \
gimp_item_get_id (g_value_get_object (gimp_value_array_index (args, n)))
libgimp: add a gazillion of macros to gimpprocedure-params.h that make dealing with value arrays easier and shorter, e.g. g_value_get_boolean (gimp_value_array_index (args, n)): becomes: GIMP_VALUES_GET_BOOLEAN (args, n);
2019-08-20 01:00:47 +02:00
#define GIMP_VALUES_SET_DRAWABLE(args, n, value) \
libgimp: GimpSaveProcedure() now uses GimpImage/GimpDrawable object... ... as parameters. And GimpLoadProcedure() now expects the run() function to return a GimpImage object.
2019-08-14 14:59:40 +02:00
g_value_set_object (gimp_value_array_index (args, n), value)
libgimp: add a gazillion of macros to gimpprocedure-params.h that make dealing with value arrays easier and shorter, e.g. g_value_get_boolean (gimp_value_array_index (args, n)): becomes: GIMP_VALUES_GET_BOOLEAN (args, n);
2019-08-20 01:00:47 +02:00
/* layer */
#define GIMP_VALUES_GET_LAYER(args, n) \
libgimp: GimpSaveProcedure() now uses GimpImage/GimpDrawable object... ... as parameters. And GimpLoadProcedure() now expects the run() function to return a GimpImage object.
2019-08-14 14:59:40 +02:00
g_value_get_object (gimp_value_array_index (args, n))
libgimp: add a gazillion of macros to gimpprocedure-params.h that make dealing with value arrays easier and shorter, e.g. g_value_get_boolean (gimp_value_array_index (args, n)): becomes: GIMP_VALUES_GET_BOOLEAN (args, n);
2019-08-20 01:00:47 +02:00
libgimp: add convenience macros GIMP_VALUES_GET_FOO_ID() becuse some plug-ins really want the ID for good reasons and not the object, and code looks so much nicer when the entire list of arguments is extracted using the macros.
2019-09-05 13:22:37 +02:00
#define GIMP_VALUES_GET_LAYER_ID(args, n) \
gimp_item_get_id (g_value_get_object (gimp_value_array_index (args, n)))
libgimp: add a gazillion of macros to gimpprocedure-params.h that make dealing with value arrays easier and shorter, e.g. g_value_get_boolean (gimp_value_array_index (args, n)): becomes: GIMP_VALUES_GET_BOOLEAN (args, n);
2019-08-20 01:00:47 +02:00
#define GIMP_VALUES_SET_LAYER(args, n, value) \
libgimp: GimpSaveProcedure() now uses GimpImage/GimpDrawable object... ... as parameters. And GimpLoadProcedure() now expects the run() function to return a GimpImage object.
2019-08-14 14:59:40 +02:00
g_value_set_object (gimp_value_array_index (args, n), value)
libgimp: add a gazillion of macros to gimpprocedure-params.h that make dealing with value arrays easier and shorter, e.g. g_value_get_boolean (gimp_value_array_index (args, n)): becomes: GIMP_VALUES_GET_BOOLEAN (args, n);
2019-08-20 01:00:47 +02:00
app, libgimp, pdb, plug-ins: new GimpTextLayer class in libgimp. Now text layers are proper types, which means that the binding API will also be nicer (e.g. `txt_layer.set_text('hello world')` in Python). This commit also adds the param specs allowing to create plug-in procedures with text layer parameters. Finally it fixes the few calls in file-pdf-save (apparently the only plug-in using specific text layer API right now) with explicit type conversion.
2022-09-30 16:21:47 +02:00
/* text layer */
#define GIMP_VALUES_GET_TEXT_LAYER(args, n) \
g_value_get_object (gimp_value_array_index (args, n))
#define GIMP_VALUES_GET_TEXT_LAYER_ID(args, n) \
gimp_item_get_id (g_value_get_object (gimp_value_array_index (args, n)))
#define GIMP_VALUES_SET_TEXT_LAYER(args, n, value) \
g_value_set_object (gimp_value_array_index (args, n), value)
app, libgimp, pdb, plug-ins: new GimpGroupLayer class in libgimp. Also: - renaming gimp_layer_group_new() to gimp_group_layer_new() in order to keep the same name as in core code (i.e. GimpGroupLayer, not GimpLayerGroup). - renaming gimp_image_merge_layer_group() to gimp_group_layer_merge() - new functions: gimp_procedure_add_group_layer_argument(), gimp_procedure_add_group_layer_aux_argument() and gimp_procedure_add_group_layer_return_value(). This can be tested, e.g. in Python with these calls: ```py i = Gimp.get_images()[0] g = Gimp.GroupLayer.new(i, "hello") i.insert_layer(g, None, 1) g2 = Gimp.GroupLayer.new(i, "world") i.insert_layer(g2, g, 1) g.merge() ``` This was work started long ago, stored in an old stash which I finally finish now! :-)
2024-07-06 17:24:11 +02:00
/* group layer */
#define GIMP_VALUES_GET_GROUP_LAYER(args, n) \
g_value_get_object (gimp_value_array_index (args, n))
#define GIMP_VALUES_GET_GROUP_LAYER_ID(args, n) \
gimp_item_get_id (g_value_get_object (gimp_value_array_index (args, n)))
#define GIMP_VALUES_SET_GROUP_LAYER(args, n, value) \
g_value_set_object (gimp_value_array_index (args, n), value)
libgimp: add a gazillion of macros to gimpprocedure-params.h that make dealing with value arrays easier and shorter, e.g. g_value_get_boolean (gimp_value_array_index (args, n)): becomes: GIMP_VALUES_GET_BOOLEAN (args, n);
2019-08-20 01:00:47 +02:00
/* channel */
#define GIMP_VALUES_GET_CHANNEL(args, n) \
libgimp: GimpSaveProcedure() now uses GimpImage/GimpDrawable object... ... as parameters. And GimpLoadProcedure() now expects the run() function to return a GimpImage object.
2019-08-14 14:59:40 +02:00
g_value_get_object (gimp_value_array_index (args, n))
libgimp: add a gazillion of macros to gimpprocedure-params.h that make dealing with value arrays easier and shorter, e.g. g_value_get_boolean (gimp_value_array_index (args, n)): becomes: GIMP_VALUES_GET_BOOLEAN (args, n);
2019-08-20 01:00:47 +02:00
libgimp: add convenience macros GIMP_VALUES_GET_FOO_ID() becuse some plug-ins really want the ID for good reasons and not the object, and code looks so much nicer when the entire list of arguments is extracted using the macros.
2019-09-05 13:22:37 +02:00
#define GIMP_VALUES_GET_CHANNEL_ID(args, n) \
gimp_item_get_id (g_value_get_object (gimp_value_array_index (args, n)))
libgimp: add a gazillion of macros to gimpprocedure-params.h that make dealing with value arrays easier and shorter, e.g. g_value_get_boolean (gimp_value_array_index (args, n)): becomes: GIMP_VALUES_GET_BOOLEAN (args, n);
2019-08-20 01:00:47 +02:00
#define GIMP_VALUES_SET_CHANNEL(args, n, value) \
libgimp: GimpSaveProcedure() now uses GimpImage/GimpDrawable object... ... as parameters. And GimpLoadProcedure() now expects the run() function to return a GimpImage object.
2019-08-14 14:59:40 +02:00
g_value_set_object (gimp_value_array_index (args, n), value)
libgimp: add a gazillion of macros to gimpprocedure-params.h that make dealing with value arrays easier and shorter, e.g. g_value_get_boolean (gimp_value_array_index (args, n)): becomes: GIMP_VALUES_GET_BOOLEAN (args, n);
2019-08-20 01:00:47 +02:00
/* layer mask */
#define GIMP_VALUES_GET_LAYER_MASK(args, n) \
libgimp: GimpSaveProcedure() now uses GimpImage/GimpDrawable object... ... as parameters. And GimpLoadProcedure() now expects the run() function to return a GimpImage object.
2019-08-14 14:59:40 +02:00
g_value_get_object (gimp_value_array_index (args, n))
libgimp: add a gazillion of macros to gimpprocedure-params.h that make dealing with value arrays easier and shorter, e.g. g_value_get_boolean (gimp_value_array_index (args, n)): becomes: GIMP_VALUES_GET_BOOLEAN (args, n);
2019-08-20 01:00:47 +02:00
libgimp: add convenience macros GIMP_VALUES_GET_FOO_ID() becuse some plug-ins really want the ID for good reasons and not the object, and code looks so much nicer when the entire list of arguments is extracted using the macros.
2019-09-05 13:22:37 +02:00
#define GIMP_VALUES_GET_LAYER_MASK_ID(args, n) \
gimp_item_get_id (g_value_get_object (gimp_value_array_index (args, n)))
libgimp: add a gazillion of macros to gimpprocedure-params.h that make dealing with value arrays easier and shorter, e.g. g_value_get_boolean (gimp_value_array_index (args, n)): becomes: GIMP_VALUES_GET_BOOLEAN (args, n);
2019-08-20 01:00:47 +02:00
#define GIMP_VALUES_SET_LAYER_MASK(args, n, value) \
libgimp: GimpSaveProcedure() now uses GimpImage/GimpDrawable object... ... as parameters. And GimpLoadProcedure() now expects the run() function to return a GimpImage object.
2019-08-14 14:59:40 +02:00
g_value_set_object (gimp_value_array_index (args, n), value)
libgimp: add a gazillion of macros to gimpprocedure-params.h that make dealing with value arrays easier and shorter, e.g. g_value_get_boolean (gimp_value_array_index (args, n)): becomes: GIMP_VALUES_GET_BOOLEAN (args, n);
2019-08-20 01:00:47 +02:00
/* selection */
#define GIMP_VALUES_GET_SELECTION(args, n) \
libgimp: GimpSaveProcedure() now uses GimpImage/GimpDrawable object... ... as parameters. And GimpLoadProcedure() now expects the run() function to return a GimpImage object.
2019-08-14 14:59:40 +02:00
g_value_get_object (gimp_value_array_index (args, n))
libgimp: add a gazillion of macros to gimpprocedure-params.h that make dealing with value arrays easier and shorter, e.g. g_value_get_boolean (gimp_value_array_index (args, n)): becomes: GIMP_VALUES_GET_BOOLEAN (args, n);
2019-08-20 01:00:47 +02:00
libgimp: add convenience macros GIMP_VALUES_GET_FOO_ID() becuse some plug-ins really want the ID for good reasons and not the object, and code looks so much nicer when the entire list of arguments is extracted using the macros.
2019-09-05 13:22:37 +02:00
#define GIMP_VALUES_GET_SELECTION_ID(args, n) \
gimp_item_get_id (g_value_get_object (gimp_value_array_index (args, n)))
libgimp: add a gazillion of macros to gimpprocedure-params.h that make dealing with value arrays easier and shorter, e.g. g_value_get_boolean (gimp_value_array_index (args, n)): becomes: GIMP_VALUES_GET_BOOLEAN (args, n);
2019-08-20 01:00:47 +02:00
#define GIMP_VALUES_SET_SELECTION(args, n, value) \
libgimp: GimpSaveProcedure() now uses GimpImage/GimpDrawable object... ... as parameters. And GimpLoadProcedure() now expects the run() function to return a GimpImage object.
2019-08-14 14:59:40 +02:00
g_value_set_object (gimp_value_array_index (args, n), value)
libgimp: add a gazillion of macros to gimpprocedure-params.h that make dealing with value arrays easier and shorter, e.g. g_value_get_boolean (gimp_value_array_index (args, n)): becomes: GIMP_VALUES_GET_BOOLEAN (args, n);
2019-08-20 01:00:47 +02:00
app: Rename app/core GimpVectors vectors API... ...to path. Changes the names of gimp_vectors_* () API to gimp_path[s]_* (). Renames related files to [path] instead of [vectors], along with relevant enums and functions.
2024-07-13 05:07:57 +00:00
/* path */
libgimp: add a gazillion of macros to gimpprocedure-params.h that make dealing with value arrays easier and shorter, e.g. g_value_get_boolean (gimp_value_array_index (args, n)): becomes: GIMP_VALUES_GET_BOOLEAN (args, n);
2019-08-20 01:00:47 +02:00
libgimp, app, pdb: Rename GimpVectors to GimpPath This commit renames the GimpVectors object to GimpPath in both app/core and in libgimp. It also renames the files to gimppath.[ch] and updates the relevant build and translation files. There are still outstanding gimp_vectors_* () functions on the app side that need to be renamed in a subsequent commit.
2024-07-12 06:16:25 +00:00
#define GIMP_VALUES_GET_PATH(args, n) \
libgimp: GimpSaveProcedure() now uses GimpImage/GimpDrawable object... ... as parameters. And GimpLoadProcedure() now expects the run() function to return a GimpImage object.
2019-08-14 14:59:40 +02:00
g_value_get_object (gimp_value_array_index (args, n))
libgimp: add a gazillion of macros to gimpprocedure-params.h that make dealing with value arrays easier and shorter, e.g. g_value_get_boolean (gimp_value_array_index (args, n)): becomes: GIMP_VALUES_GET_BOOLEAN (args, n);
2019-08-20 01:00:47 +02:00
libgimp, app, pdb: Rename GimpVectors to GimpPath This commit renames the GimpVectors object to GimpPath in both app/core and in libgimp. It also renames the files to gimppath.[ch] and updates the relevant build and translation files. There are still outstanding gimp_vectors_* () functions on the app side that need to be renamed in a subsequent commit.
2024-07-12 06:16:25 +00:00
#define GIMP_VALUES_GET_PATH_ID(args, n) \
libgimp: add convenience macros GIMP_VALUES_GET_FOO_ID() becuse some plug-ins really want the ID for good reasons and not the object, and code looks so much nicer when the entire list of arguments is extracted using the macros.
2019-09-05 13:22:37 +02:00
gimp_item_get_id (g_value_get_object (gimp_value_array_index (args, n)))
libgimp, app, pdb: Rename GimpVectors to GimpPath This commit renames the GimpVectors object to GimpPath in both app/core and in libgimp. It also renames the files to gimppath.[ch] and updates the relevant build and translation files. There are still outstanding gimp_vectors_* () functions on the app side that need to be renamed in a subsequent commit.
2024-07-12 06:16:25 +00:00
#define GIMP_VALUES_SET_PATH(args, n, value) \
libgimp: GimpSaveProcedure() now uses GimpImage/GimpDrawable object... ... as parameters. And GimpLoadProcedure() now expects the run() function to return a GimpImage object.
2019-08-14 14:59:40 +02:00
g_value_set_object (gimp_value_array_index (args, n), value)
libgimp: add a gazillion of macros to gimpprocedure-params.h that make dealing with value arrays easier and shorter, e.g. g_value_get_boolean (gimp_value_array_index (args, n)): becomes: GIMP_VALUES_GET_BOOLEAN (args, n);
2019-08-20 01:00:47 +02:00
libgimp: add gimpprocedure-params.h which looks much like gimpconfig-params.h and contains macros (e.g. GIMP_PROC_ARG_BOOLEAN() and GIMP_PROC_VAL_BOOLEAN()) for all GimpProcedure argument and return value types supported by the protocol, and makes the boilerplate of setting up a procedure more readable and much less indented. This file is C-only and not introspected.
2019-08-19 09:56:20 +02:00
app, libgimp, pdb: passing GimpDrawableFilter across the wire. A few functions were added, but the main one is gimp_drawable_get_filters() to request the list of filters applied non-destructively on a drawable. We can't do much with these for the time being, but this will come. WIP.
2024-11-25 04:38:39 +09:00
/* Drawable Filter */
#define GIMP_VALUES_GET_DRAWABLE_FILTER(args, n) \
g_value_get_object (gimp_value_array_index (args, n))
#define GIMP_VALUES_GET_DRAWABLE_FILTER_ID(args, n) \
gimp_drawable_filter_get_id (g_value_get_object (gimp_value_array_index (args, n)))
#define GIMP_VALUES_SET_DRAWABLE_FILTER(args, n, value) \
g_value_set_object (gimp_value_array_index (args, n), value)
pdb, app, libgimp, plug-ins: replace most PDB filenames/URIs by GFile and in an attack of madness, changes almost all file plug-in code to use GFile instead of filenames, which means passing the GFile down to the bottom and get its filename at the very end where it's actually needed.
2019-09-11 21:48:34 +02:00
/* file */
#define GIMP_VALUES_GET_FILE(args, n) \
g_value_get_object (gimp_value_array_index (args, n))
#define GIMP_VALUES_DUP_FILE(args, n) \
g_value_dup_object (gimp_value_array_index (args, n))
#define GIMP_VALUES_SET_FILE(args, n, value) \
g_value_set_object (gimp_value_array_index (args, n), value)
#define GIMP_VALUES_TAKE_FILE(args, n, value) \
g_value_take_object (gimp_value_array_index (args, n), value)
2.99 libgimp: add GimpResource, GimpBrush, GimpPropWidgetBrush So procedures can declare args and GimpProcedureDialog show chooser widgets Fix so is no error dialog on id_is_valid for resources Palette.pdb changes and testing Memory mgt changes Gradient pdb Font and Pattern tests Test brush, palette Cleanup, remove generator Rebase, edit docs, install test-dialog.py Whitespace, and fix failed distcheck Fix some clang-format, fix fail distcheck Fix distcheck Cleanup from review Jehan
2022-09-05 19:28:35 -04:00
/* Resource */
pdb: GimpResource: add is_editable(), rename(), duplicate(). delete() and remove the API from its subclasses.
2023-06-06 16:33:36 +02:00
#define GIMP_VALUES_GET_RESOURCE(args, n) \
g_value_get_object (gimp_value_array_index (args, n))
#define GIMP_VALUES_SET_RESOURCE(args, n, value) \
g_value_set_object (gimp_value_array_index (args, n), value)
2.99 libgimp: add GimpResource, GimpBrush, GimpPropWidgetBrush So procedures can declare args and GimpProcedureDialog show chooser widgets Fix so is no error dialog on id_is_valid for resources Palette.pdb changes and testing Memory mgt changes Gradient pdb Font and Pattern tests Test brush, palette Cleanup, remove generator Rebase, edit docs, install test-dialog.py Whitespace, and fix failed distcheck Fix some clang-format, fix fail distcheck Fix distcheck Cleanup from review Jehan
2022-09-05 19:28:35 -04:00
#define GIMP_VALUES_GET_BRUSH(args, n) \
g_value_get_object (gimp_value_array_index (args, n))
#define GIMP_VALUES_SET_BRUSH(args, n, value) \
g_value_set_object (gimp_value_array_index (args, n), value)
#define GIMP_VALUES_GET_FONT(args, n) \
g_value_get_object (gimp_value_array_index (args, n))
#define GIMP_VALUES_SET_FONT(args, n, value) \
g_value_set_object (gimp_value_array_index (args, n), value)
#define GIMP_VALUES_GET_GRADIENT(args, n) \
g_value_get_object (gimp_value_array_index (args, n))
#define GIMP_VALUES_SET_GRADIENT(args, n, value) \
g_value_set_object (gimp_value_array_index (args, n), value)
#define GIMP_VALUES_GET_PALETTE(args, n) \
g_value_get_object (gimp_value_array_index (args, n))
#define GIMP_VALUES_SET_PALETTE(args, n, value) \
g_value_set_object (gimp_value_array_index (args, n), value)
#define GIMP_VALUES_GET_PATTERN(args, n) \
g_value_get_object (gimp_value_array_index (args, n))
#define GIMP_VALUES_SET_PATTERN(args, n, value) \
g_value_set_object (gimp_value_array_index (args, n), value)
Issue #8900 and #9923: reimplementing GimpUnit as a proper class. This fixes all our GObject Introspection issues with GimpUnit which was both an enum and an int-derived type of user-defined units *completing* the enum values. GIR clearly didn't like this! Now GimpUnit is a proper class and units are unique objects, allowing to compare them with an identity test (i.e. `unit == gimp_unit_pixel ()` tells us if unit is the pixel unit or not), which makes it easy to use, just like with int, yet adding also methods, making for nicer introspected API. As an aside, this also fixes #10738, by having all the built-in units retrievable even if libgimpbase had not been properly initialized with gimp_base_init(). I haven't checked in details how GIR works to introspect, but it looks like it loads the library to inspect and runs functions, hence triggering some CRITICALS because virtual methods (supposed to be initialized with gimp_base_init() run by libgimp) are not set. This new code won't trigger any critical because the vtable method are now not necessary, at least for all built-in units. Note that GimpUnit is still in libgimpbase. It could have been moved to libgimp in order to avoid any virtual method table (since we need to keep core and libgimp side's units in sync, PDB is required), but too many libgimpwidgets widgets were already using GimpUnit. And technically most of GimpUnit logic doesn't require PDB (only the creation/sync part). This is one of the reasons why user-created GimpUnit list is handled and stored differently from other types of objects. Globally this simplifies the code a lot too and we don't need separate implementations of various utils for core and libgimp, which means less prone to errors.
2024-07-25 20:55:21 +02:00
/* Unit */
#define GIMP_VALUES_GET_UNIT(args, n) \
g_value_get_object (gimp_value_array_index (args, n))
#define GIMP_VALUES_SET_UNIT(args, n, value) \
g_value_set_object (gimp_value_array_index (args, n), value)
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
void gimp_procedure_add_boolean_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean value,
GParamFlags flags);
void gimp_procedure_add_boolean_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean value,
GParamFlags flags);
void gimp_procedure_add_boolean_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean value,
GParamFlags flags);
void gimp_procedure_add_int_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gint min,
gint max,
gint value,
GParamFlags flags);
void gimp_procedure_add_int_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gint min,
gint max,
gint value,
GParamFlags flags);
void gimp_procedure_add_int_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gint min,
gint max,
gint value,
GParamFlags flags);
void gimp_procedure_add_uint_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
guint min,
guint max,
guint value,
GParamFlags flags);
void gimp_procedure_add_uint_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
guint min,
guint max,
guint value,
GParamFlags flags);
void gimp_procedure_add_uint_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
guint min,
guint max,
guint value,
GParamFlags flags);
void gimp_procedure_add_unit_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean show_pixels,
gboolean show_percent,
Issue #8900 and #9923: reimplementing GimpUnit as a proper class. This fixes all our GObject Introspection issues with GimpUnit which was both an enum and an int-derived type of user-defined units *completing* the enum values. GIR clearly didn't like this! Now GimpUnit is a proper class and units are unique objects, allowing to compare them with an identity test (i.e. `unit == gimp_unit_pixel ()` tells us if unit is the pixel unit or not), which makes it easy to use, just like with int, yet adding also methods, making for nicer introspected API. As an aside, this also fixes #10738, by having all the built-in units retrievable even if libgimpbase had not been properly initialized with gimp_base_init(). I haven't checked in details how GIR works to introspect, but it looks like it loads the library to inspect and runs functions, hence triggering some CRITICALS because virtual methods (supposed to be initialized with gimp_base_init() run by libgimp) are not set. This new code won't trigger any critical because the vtable method are now not necessary, at least for all built-in units. Note that GimpUnit is still in libgimpbase. It could have been moved to libgimp in order to avoid any virtual method table (since we need to keep core and libgimp side's units in sync, PDB is required), but too many libgimpwidgets widgets were already using GimpUnit. And technically most of GimpUnit logic doesn't require PDB (only the creation/sync part). This is one of the reasons why user-created GimpUnit list is handled and stored differently from other types of objects. Globally this simplifies the code a lot too and we don't need separate implementations of various utils for core and libgimp, which means less prone to errors.
2024-07-25 20:55:21 +02:00
GimpUnit *value,
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
GParamFlags flags);
void gimp_procedure_add_unit_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean show_pixels,
gboolean show_percent,
Issue #8900 and #9923: reimplementing GimpUnit as a proper class. This fixes all our GObject Introspection issues with GimpUnit which was both an enum and an int-derived type of user-defined units *completing* the enum values. GIR clearly didn't like this! Now GimpUnit is a proper class and units are unique objects, allowing to compare them with an identity test (i.e. `unit == gimp_unit_pixel ()` tells us if unit is the pixel unit or not), which makes it easy to use, just like with int, yet adding also methods, making for nicer introspected API. As an aside, this also fixes #10738, by having all the built-in units retrievable even if libgimpbase had not been properly initialized with gimp_base_init(). I haven't checked in details how GIR works to introspect, but it looks like it loads the library to inspect and runs functions, hence triggering some CRITICALS because virtual methods (supposed to be initialized with gimp_base_init() run by libgimp) are not set. This new code won't trigger any critical because the vtable method are now not necessary, at least for all built-in units. Note that GimpUnit is still in libgimpbase. It could have been moved to libgimp in order to avoid any virtual method table (since we need to keep core and libgimp side's units in sync, PDB is required), but too many libgimpwidgets widgets were already using GimpUnit. And technically most of GimpUnit logic doesn't require PDB (only the creation/sync part). This is one of the reasons why user-created GimpUnit list is handled and stored differently from other types of objects. Globally this simplifies the code a lot too and we don't need separate implementations of various utils for core and libgimp, which means less prone to errors.
2024-07-25 20:55:21 +02:00
GimpUnit *value,
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
GParamFlags flags);
void gimp_procedure_add_unit_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean show_pixels,
gboolean show_percent,
Issue #8900 and #9923: reimplementing GimpUnit as a proper class. This fixes all our GObject Introspection issues with GimpUnit which was both an enum and an int-derived type of user-defined units *completing* the enum values. GIR clearly didn't like this! Now GimpUnit is a proper class and units are unique objects, allowing to compare them with an identity test (i.e. `unit == gimp_unit_pixel ()` tells us if unit is the pixel unit or not), which makes it easy to use, just like with int, yet adding also methods, making for nicer introspected API. As an aside, this also fixes #10738, by having all the built-in units retrievable even if libgimpbase had not been properly initialized with gimp_base_init(). I haven't checked in details how GIR works to introspect, but it looks like it loads the library to inspect and runs functions, hence triggering some CRITICALS because virtual methods (supposed to be initialized with gimp_base_init() run by libgimp) are not set. This new code won't trigger any critical because the vtable method are now not necessary, at least for all built-in units. Note that GimpUnit is still in libgimpbase. It could have been moved to libgimp in order to avoid any virtual method table (since we need to keep core and libgimp side's units in sync, PDB is required), but too many libgimpwidgets widgets were already using GimpUnit. And technically most of GimpUnit logic doesn't require PDB (only the creation/sync part). This is one of the reasons why user-created GimpUnit list is handled and stored differently from other types of objects. Globally this simplifies the code a lot too and we don't need separate implementations of various utils for core and libgimp, which means less prone to errors.
2024-07-25 20:55:21 +02:00
GimpUnit *value,
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
GParamFlags flags);
void gimp_procedure_add_double_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gdouble min,
gdouble max,
gdouble value,
GParamFlags flags);
void gimp_procedure_add_double_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gdouble min,
gdouble max,
gdouble value,
GParamFlags flags);
void gimp_procedure_add_double_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gdouble min,
gdouble max,
gdouble value,
GParamFlags flags);
void gimp_procedure_add_enum_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GType enum_type,
gint value,
GParamFlags flags);
void gimp_procedure_add_enum_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GType enum_type,
gint value,
GParamFlags flags);
void gimp_procedure_add_enum_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GType enum_type,
gint value,
GParamFlags flags);
void gimp_procedure_add_choice_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GimpChoice *choice,
const gchar *value,
GParamFlags flags);
void gimp_procedure_add_choice_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GimpChoice *choice,
const gchar *value,
GParamFlags flags);
void gimp_procedure_add_choice_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GimpChoice *choice,
const gchar *value,
GParamFlags flags);
void gimp_procedure_add_string_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
const gchar *value,
GParamFlags flags);
void gimp_procedure_add_string_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
const gchar *value,
GParamFlags flags);
void gimp_procedure_add_string_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
const gchar *value,
GParamFlags flags);
void gimp_procedure_add_color_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean has_alpha,
GeglColor *value,
GParamFlags flags);
void gimp_procedure_add_color_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean has_alpha,
GeglColor *value,
GParamFlags flags);
void gimp_procedure_add_color_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean has_alpha,
GeglColor *value,
GParamFlags flags);
void gimp_procedure_add_color_from_string_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean has_alpha,
const gchar *value,
GParamFlags flags);
void gimp_procedure_add_color_from_string_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean has_alpha,
const gchar *value,
GParamFlags flags);
void gimp_procedure_add_color_from_string_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean has_alpha,
const gchar *value,
GParamFlags flags);
void gimp_procedure_add_parasite_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GParamFlags flags);
void gimp_procedure_add_parasite_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GParamFlags flags);
void gimp_procedure_add_parasite_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GParamFlags flags);
void gimp_procedure_add_param_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GType param_type,
GParamFlags flags);
void gimp_procedure_add_param_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GType param_type,
GParamFlags flags);
void gimp_procedure_add_param_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GType param_type,
GParamFlags flags);
void gimp_procedure_add_bytes_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GParamFlags flags);
void gimp_procedure_add_bytes_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GParamFlags flags);
void gimp_procedure_add_bytes_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GParamFlags flags);
void gimp_procedure_add_int32_array_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GParamFlags flags);
void gimp_procedure_add_int32_array_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GParamFlags flags);
void gimp_procedure_add_int32_array_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GParamFlags flags);
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/. Several types functions were using the wording "float" historically to mean double-precision, e.g. the float array type (which was in fact a double array). Or the scanner function gimp_scanner_parse_float() was in fact returning a double value. What if we wanted someday to actually add float (usually this naming means in C the single-precision IEEE 754 floating point representation) support? How would we name this? Now technically it's not entirely wrong (a double is still a floating point). So I've been wondering if that is because maybe we never planned to have float and double precision may be good enough for all usage in a plug-in API (which doesn't have to be as generic so the higher precision is enough)? But how can we be sure? Also we already had some functions using the wording double (e.g. gimp_procedure_add_double_argument()), so let's just go the safe route and use the accurate wording. The additional change in PDB is internal, but there too, I was also finding very confusing that we were naming double-precision float as 'float' type. So I took the opportunity to update this. It doesn't change any signature. In fact the whole commit doesn't change any type or code logic, only naming, except for one bug fix in the middle which I encountered while renaming: in gimp_scanner_parse_deprecated_color(), I discovered a hidden bug in scanning (color-hsv*) values, which was mistakenly using a double type for an array of float.
2024-11-02 14:03:37 +01:00
void gimp_procedure_add_double_array_argument (GimpProcedure *procedure,
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
const gchar *name,
const gchar *nick,
const gchar *blurb,
GParamFlags flags);
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/. Several types functions were using the wording "float" historically to mean double-precision, e.g. the float array type (which was in fact a double array). Or the scanner function gimp_scanner_parse_float() was in fact returning a double value. What if we wanted someday to actually add float (usually this naming means in C the single-precision IEEE 754 floating point representation) support? How would we name this? Now technically it's not entirely wrong (a double is still a floating point). So I've been wondering if that is because maybe we never planned to have float and double precision may be good enough for all usage in a plug-in API (which doesn't have to be as generic so the higher precision is enough)? But how can we be sure? Also we already had some functions using the wording double (e.g. gimp_procedure_add_double_argument()), so let's just go the safe route and use the accurate wording. The additional change in PDB is internal, but there too, I was also finding very confusing that we were naming double-precision float as 'float' type. So I took the opportunity to update this. It doesn't change any signature. In fact the whole commit doesn't change any type or code logic, only naming, except for one bug fix in the middle which I encountered while renaming: in gimp_scanner_parse_deprecated_color(), I discovered a hidden bug in scanning (color-hsv*) values, which was mistakenly using a double type for an array of float.
2024-11-02 14:03:37 +01:00
void gimp_procedure_add_double_array_aux_argument (GimpProcedure *procedure,
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
const gchar *name,
const gchar *nick,
const gchar *blurb,
GParamFlags flags);
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/. Several types functions were using the wording "float" historically to mean double-precision, e.g. the float array type (which was in fact a double array). Or the scanner function gimp_scanner_parse_float() was in fact returning a double value. What if we wanted someday to actually add float (usually this naming means in C the single-precision IEEE 754 floating point representation) support? How would we name this? Now technically it's not entirely wrong (a double is still a floating point). So I've been wondering if that is because maybe we never planned to have float and double precision may be good enough for all usage in a plug-in API (which doesn't have to be as generic so the higher precision is enough)? But how can we be sure? Also we already had some functions using the wording double (e.g. gimp_procedure_add_double_argument()), so let's just go the safe route and use the accurate wording. The additional change in PDB is internal, but there too, I was also finding very confusing that we were naming double-precision float as 'float' type. So I took the opportunity to update this. It doesn't change any signature. In fact the whole commit doesn't change any type or code logic, only naming, except for one bug fix in the middle which I encountered while renaming: in gimp_scanner_parse_deprecated_color(), I discovered a hidden bug in scanning (color-hsv*) values, which was mistakenly using a double type for an array of float.
2024-11-02 14:03:37 +01:00
void gimp_procedure_add_double_array_return_value (GimpProcedure *procedure,
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
const gchar *name,
const gchar *nick,
const gchar *blurb,
GParamFlags flags);
void gimp_procedure_add_string_array_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GParamFlags flags);
void gimp_procedure_add_string_array_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GParamFlags flags);
void gimp_procedure_add_string_array_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GParamFlags flags);
app, libgimp*, plug-ins: move all GimpObjectArray procedure args to GimpCoreObjectArray.
2024-10-22 22:46:21 +02:00
void gimp_procedure_add_core_object_array_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GType object_type,
GParamFlags flags);
void gimp_procedure_add_core_object_array_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GType object_type,
GParamFlags flags);
void gimp_procedure_add_core_object_array_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
const gchar *blurb,
GType object_type,
GParamFlags flags);
void gimp_procedure_add_display_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags);
void gimp_procedure_add_display_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags);
void gimp_procedure_add_display_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags);
void gimp_procedure_add_image_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags);
void gimp_procedure_add_image_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags);
void gimp_procedure_add_image_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags);
void gimp_procedure_add_item_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags);
void gimp_procedure_add_item_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags);
void gimp_procedure_add_item_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags);
void gimp_procedure_add_drawable_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags);
void gimp_procedure_add_drawable_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags);
void gimp_procedure_add_drawable_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags);
void gimp_procedure_add_layer_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags);
void gimp_procedure_add_layer_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags);
void gimp_procedure_add_layer_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags);
void gimp_procedure_add_text_layer_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags);
void gimp_procedure_add_text_layer_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags);
void gimp_procedure_add_text_layer_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags);
app, libgimp, pdb, plug-ins: new GimpGroupLayer class in libgimp. Also: - renaming gimp_layer_group_new() to gimp_group_layer_new() in order to keep the same name as in core code (i.e. GimpGroupLayer, not GimpLayerGroup). - renaming gimp_image_merge_layer_group() to gimp_group_layer_merge() - new functions: gimp_procedure_add_group_layer_argument(), gimp_procedure_add_group_layer_aux_argument() and gimp_procedure_add_group_layer_return_value(). This can be tested, e.g. in Python with these calls: ```py i = Gimp.get_images()[0] g = Gimp.GroupLayer.new(i, "hello") i.insert_layer(g, None, 1) g2 = Gimp.GroupLayer.new(i, "world") i.insert_layer(g2, g, 1) g.merge() ``` This was work started long ago, stored in an old stash which I finally finish now! :-)
2024-07-06 17:24:11 +02:00
void gimp_procedure_add_group_layer_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags);
void gimp_procedure_add_group_layer_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags);
void gimp_procedure_add_group_layer_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags);
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
void gimp_procedure_add_channel_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags);
void gimp_procedure_add_channel_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags);
void gimp_procedure_add_channel_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags);
void gimp_procedure_add_layer_mask_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags);
void gimp_procedure_add_layer_mask_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags);
void gimp_procedure_add_layer_mask_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags);
void gimp_procedure_add_selection_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags);
void gimp_procedure_add_selection_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags);
void gimp_procedure_add_selection_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags);
app: Rename app/core GimpVectors vectors API... ...to path. Changes the names of gimp_vectors_* () API to gimp_path[s]_* (). Renames related files to [path] instead of [vectors], along with relevant enums and functions.
2024-07-13 05:07:57 +00:00
void gimp_procedure_add_path_argument (GimpProcedure *procedure,
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags);
app: Rename app/core GimpVectors vectors API... ...to path. Changes the names of gimp_vectors_* () API to gimp_path[s]_* (). Renames related files to [path] instead of [vectors], along with relevant enums and functions.
2024-07-13 05:07:57 +00:00
void gimp_procedure_add_path_aux_argument (GimpProcedure *procedure,
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags);
app: Rename app/core GimpVectors vectors API... ...to path. Changes the names of gimp_vectors_* () API to gimp_path[s]_* (). Renames related files to [path] instead of [vectors], along with relevant enums and functions.
2024-07-13 05:07:57 +00:00
void gimp_procedure_add_path_return_value (GimpProcedure *procedure,
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
const gchar *name,
const gchar *nick,
const gchar *blurb,
gboolean none_ok,
GParamFlags flags);
Issue #12045: no defaults for plugin args of type File. libgimpbase: - Mew GimpFileChooserAction enum type: basically a near-mapping of GtkFileChooserAction (GTK is not accessible from libgimpbase) with an added GIMP_FILE_CHOOSER_ACTION_ANY. - New GimpParamSpecFile param spec type: based off GimpParamSpecObject, it has a default value, but also a none_ok and action argument. This way, we can also know from the argument type if this is a file argument meant for selecting a normal file or a folder, or for saving into a file, or for creating a directory. libgimp, plug-ins: - All existing file arguments (until now using a standard GParamSpecObject param with GFile value type) were moved to the new GimpParamSpecFile. - Script-Fu in particular will now generate the appropriate param type depending on whether it is an SF-FILENAME or SF-DIRNAME. - File arguments are now stored between runs as a URI rather than as a path. As far as I can tell, a GFile always has a URI, but not always a path (in particular remote file won't have a path).
2025-01-22 17:15:28 +01:00
void gimp_procedure_add_file_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GimpFileChooserAction action,
gboolean none_ok,
libgimp: fix introspection. The variable name was not the same on function declaration and definition/annotations and this was confusing GIR scanner.
2025-01-22 21:26:17 +01:00
GFile *default_file,
Issue #12045: no defaults for plugin args of type File. libgimpbase: - Mew GimpFileChooserAction enum type: basically a near-mapping of GtkFileChooserAction (GTK is not accessible from libgimpbase) with an added GIMP_FILE_CHOOSER_ACTION_ANY. - New GimpParamSpecFile param spec type: based off GimpParamSpecObject, it has a default value, but also a none_ok and action argument. This way, we can also know from the argument type if this is a file argument meant for selecting a normal file or a folder, or for saving into a file, or for creating a directory. libgimp, plug-ins: - All existing file arguments (until now using a standard GParamSpecObject param with GFile value type) were moved to the new GimpParamSpecFile. - Script-Fu in particular will now generate the appropriate param type depending on whether it is an SF-FILENAME or SF-DIRNAME. - File arguments are now stored between runs as a URI rather than as a path. As far as I can tell, a GFile always has a URI, but not always a path (in particular remote file won't have a path).
2025-01-22 17:15:28 +01:00
GParamFlags flags);
void gimp_procedure_add_file_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GimpFileChooserAction action,
gboolean none_ok,
libgimp: fix introspection. The variable name was not the same on function declaration and definition/annotations and this was confusing GIR scanner.
2025-01-22 21:26:17 +01:00
GFile *default_file,
Issue #12045: no defaults for plugin args of type File. libgimpbase: - Mew GimpFileChooserAction enum type: basically a near-mapping of GtkFileChooserAction (GTK is not accessible from libgimpbase) with an added GIMP_FILE_CHOOSER_ACTION_ANY. - New GimpParamSpecFile param spec type: based off GimpParamSpecObject, it has a default value, but also a none_ok and action argument. This way, we can also know from the argument type if this is a file argument meant for selecting a normal file or a folder, or for saving into a file, or for creating a directory. libgimp, plug-ins: - All existing file arguments (until now using a standard GParamSpecObject param with GFile value type) were moved to the new GimpParamSpecFile. - Script-Fu in particular will now generate the appropriate param type depending on whether it is an SF-FILENAME or SF-DIRNAME. - File arguments are now stored between runs as a URI rather than as a path. As far as I can tell, a GFile always has a URI, but not always a path (in particular remote file won't have a path).
2025-01-22 17:15:28 +01:00
GParamFlags flags);
void gimp_procedure_add_file_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GParamFlags flags);
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
void gimp_procedure_add_resource_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
libgimp, plug-ins: fix gimp_procedure_add_*_argument() where `*` is a resource type. The correspondant param specs' fourth arg was a `none_ok` boolean, not a type. Carry over this argument to the gimp_procedure_add_*() function.
2024-07-05 22:19:34 +02:00
gboolean none_ok,
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
GimpResource *default_value,
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
GParamFlags flags);
void gimp_procedure_add_resource_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
GimpResource *default_value,
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
GParamFlags flags);
void gimp_procedure_add_resource_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GParamFlags flags);
void gimp_procedure_add_brush_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
libgimp, plug-ins: fix gimp_procedure_add_*_argument() where `*` is a resource type. The correspondant param specs' fourth arg was a `none_ok` boolean, not a type. Carry over this argument to the gimp_procedure_add_*() function.
2024-07-05 22:19:34 +02:00
gboolean none_ok,
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
GimpBrush *default_value,
app, libgimp, pdb, plug-ins: add ability to default to context for all resource args. Also fixes the passing of the resource param definitions through PDB. There was some weird assumption, with a comment, in commit 73733335c8 that this was unneeded, which meant that we were not able to properly recreate the right param spec over the wire.
2024-09-06 13:38:43 +02:00
gboolean default_to_context,
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
GParamFlags flags);
void gimp_procedure_add_brush_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
GimpBrush *default_value,
app, libgimp, pdb, plug-ins: add ability to default to context for all resource args. Also fixes the passing of the resource param definitions through PDB. There was some weird assumption, with a comment, in commit 73733335c8 that this was unneeded, which meant that we were not able to properly recreate the right param spec over the wire.
2024-09-06 13:38:43 +02:00
gboolean default_to_context,
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
GParamFlags flags);
void gimp_procedure_add_brush_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GParamFlags flags);
void gimp_procedure_add_font_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
libgimp, plug-ins: fix gimp_procedure_add_*_argument() where `*` is a resource type. The correspondant param specs' fourth arg was a `none_ok` boolean, not a type. Carry over this argument to the gimp_procedure_add_*() function.
2024-07-05 22:19:34 +02:00
gboolean none_ok,
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
GimpFont *default_value,
app, libgimp, pdb, plug-ins: add ability to default to context for all resource args. Also fixes the passing of the resource param definitions through PDB. There was some weird assumption, with a comment, in commit 73733335c8 that this was unneeded, which meant that we were not able to properly recreate the right param spec over the wire.
2024-09-06 13:38:43 +02:00
gboolean default_to_context,
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
GParamFlags flags);
void gimp_procedure_add_font_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
GimpFont *default_value,
app, libgimp, pdb, plug-ins: add ability to default to context for all resource args. Also fixes the passing of the resource param definitions through PDB. There was some weird assumption, with a comment, in commit 73733335c8 that this was unneeded, which meant that we were not able to properly recreate the right param spec over the wire.
2024-09-06 13:38:43 +02:00
gboolean default_to_context,
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
GParamFlags flags);
void gimp_procedure_add_font_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GParamFlags flags);
void gimp_procedure_add_gradient_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
libgimp, plug-ins: fix gimp_procedure_add_*_argument() where `*` is a resource type. The correspondant param specs' fourth arg was a `none_ok` boolean, not a type. Carry over this argument to the gimp_procedure_add_*() function.
2024-07-05 22:19:34 +02:00
gboolean none_ok,
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
GimpGradient *default_value,
app, libgimp, pdb, plug-ins: add ability to default to context for all resource args. Also fixes the passing of the resource param definitions through PDB. There was some weird assumption, with a comment, in commit 73733335c8 that this was unneeded, which meant that we were not able to properly recreate the right param spec over the wire.
2024-09-06 13:38:43 +02:00
gboolean default_to_context,
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
GParamFlags flags);
void gimp_procedure_add_gradient_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
GimpGradient *default_value,
app, libgimp, pdb, plug-ins: add ability to default to context for all resource args. Also fixes the passing of the resource param definitions through PDB. There was some weird assumption, with a comment, in commit 73733335c8 that this was unneeded, which meant that we were not able to properly recreate the right param spec over the wire.
2024-09-06 13:38:43 +02:00
gboolean default_to_context,
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
GParamFlags flags);
void gimp_procedure_add_gradient_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GParamFlags flags);
void gimp_procedure_add_palette_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
libgimp, plug-ins: fix gimp_procedure_add_*_argument() where `*` is a resource type. The correspondant param specs' fourth arg was a `none_ok` boolean, not a type. Carry over this argument to the gimp_procedure_add_*() function.
2024-07-05 22:19:34 +02:00
gboolean none_ok,
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
GimpPalette *default_value,
app, libgimp, pdb, plug-ins: add ability to default to context for all resource args. Also fixes the passing of the resource param definitions through PDB. There was some weird assumption, with a comment, in commit 73733335c8 that this was unneeded, which meant that we were not able to properly recreate the right param spec over the wire.
2024-09-06 13:38:43 +02:00
gboolean default_to_context,
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
GParamFlags flags);
void gimp_procedure_add_palette_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
GimpPalette *default_value,
app, libgimp, pdb, plug-ins: add ability to default to context for all resource args. Also fixes the passing of the resource param definitions through PDB. There was some weird assumption, with a comment, in commit 73733335c8 that this was unneeded, which meant that we were not able to properly recreate the right param spec over the wire.
2024-09-06 13:38:43 +02:00
gboolean default_to_context,
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
GParamFlags flags);
void gimp_procedure_add_palette_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GParamFlags flags);
void gimp_procedure_add_pattern_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
libgimp, plug-ins: fix gimp_procedure_add_*_argument() where `*` is a resource type. The correspondant param specs' fourth arg was a `none_ok` boolean, not a type. Carry over this argument to the gimp_procedure_add_*() function.
2024-07-05 22:19:34 +02:00
gboolean none_ok,
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
GimpPattern *default_value,
app, libgimp, pdb, plug-ins: add ability to default to context for all resource args. Also fixes the passing of the resource param definitions through PDB. There was some weird assumption, with a comment, in commit 73733335c8 that this was unneeded, which meant that we were not able to properly recreate the right param spec over the wire.
2024-09-06 13:38:43 +02:00
gboolean default_to_context,
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
GParamFlags flags);
void gimp_procedure_add_pattern_aux_argument (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
libgimp: plugins: fix #10950 resource defaults not effective Now you can declare a default value when declaring resource arguments to a PDB procedure. Add default behavior to GimpParamSpecResource. Add field and override g_param_spec_value_set_default. Fix the plugins that have resource arguments. Some plugins temporarily use a hardcoded default instead of declared default. ScriptFu plugins, TODO. Misc fix to the test plugin for this case: test-dialog.py. Dev>Demo>Test dialog... TODO 10822 Lava plugin issue depends on this. Note film.c fixed but still doesn't work.
2024-07-27 08:18:54 -04:00
GimpPattern *default_value,
app, libgimp, pdb, plug-ins: add ability to default to context for all resource args. Also fixes the passing of the resource param definitions through PDB. There was some weird assumption, with a comment, in commit 73733335c8 that this was unneeded, which meant that we were not able to properly recreate the right param spec over the wire.
2024-09-06 13:38:43 +02:00
gboolean default_to_context,
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
GParamFlags flags);
void gimp_procedure_add_pattern_return_value (GimpProcedure *procedure,
const gchar *name,
const gchar *nick,
const gchar *blurb,
GParamFlags flags);
libgimp: add gimpprocedure-params.h which looks much like gimpconfig-params.h and contains macros (e.g. GIMP_PROC_ARG_BOOLEAN() and GIMP_PROC_VAL_BOOLEAN()) for all GimpProcedure argument and return value types supported by the protocol, and makes the boilerplate of setting up a procedure more readable and much less indented. This file is C-only and not introspected.
2019-08-19 09:56:20 +02:00
G_END_DECLS
#endif /* __GIMP_PROCEDURE_PARAMS_H__ */
Reference in a new issue Copy permalink