Commit Graph

23 Commits

Author SHA1 Message Date
Alx Sa bcdd4974bb core, pdb, plug-ins: Create GimpExportOptions class
This patch creates a GimpExportOptions class in both
libgimpbase and in libgimp. Currently it is a mostly empty
object, but it will be added to after 3.0 to allow for
additional export options (like resizing on export while
leaving the original image intact)

libgimp/gimpexport.c was removed, and most of its content
was copied into libgimp/gimpexportoptions.c. gimp_export_image ()
was replaced with gimp_export_options_get_image () in all
export plug-ins.

GimpExportProcedure has a new function to set the default
image capabilities for each plug-in on creation. It also sets up
a new callback function, which allows the options to respond to
user setting changes (such as toggling 'Save as Animation' in the
GIF or WEBP Plug-in).
2024-08-18 22:03:14 +02:00
Jehan 1add3343ad libgimpbase: removing wrong annotations.
I thought that such annotations would work and be useful to tell GIR that
a type is nothing more than a NULL-terminated array of a specific type.
But apparently GIR doesn't like these annotations and complain. So let's
just clean these out.

Fixes:

> ./../../../../../../dev/src/gimp/libgimpbase/gimpparamspecs.h:254: Warning: Gimp: unexpected annotation: array
> ../../../../../../../dev/src/gimp/libgimpbase/gimpparamspecs.h:254: Warning: Gimp: unexpected annotation: element-type
2024-08-02 14:18:44 +02:00
Jehan 9f149ef3a2 app, libgimp*, plug-ins: get rid of GimpRGB arrays now that we have GeglColor arrays. 2024-04-18 16:00:42 +02:00
Jehan 3f79f3589d Issue #10885: gimp-palette-get-colors warning and critical when…
… accessed from Python.

Creating a new function gimp_value_array_get_color_array(). This should normally
not be needed (it isn't in C), but because of GObject Introspection limitation
and the fact that pygobject will automatically try to convert GValue to the
embedded value, we get this weird situation where the result is unusable in
Python for certain types. One of these types is GimpColorArray.

I suggest an annotation request to GObject Introspection:
https://gitlab.gnome.org/GNOME/gobject-introspection/-/issues/492

I think that with such annotation, followed as a second step by pygobject
support, correctly handling NULL terminated C arrays generically should be
feasible by bindings.
2024-02-28 22:55:58 +01:00
Jehan 65f8afee68 app, libgimp, libgimpbase, pdb: GimpColorArray as a typedef to…
… NULL-terminated array of GeglColor is now a boxed type usable in PDB.
2024-02-11 23:28:04 +01:00
Jehan 4163a29af3 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-10-01 20:52:02 +02:00
Niels De Graef 89c359ce47 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:50 +02:00
Niels De Graef 8eb7f6df9e 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
2022-02-12 00:07:53 +00:00
Niels De Graef dffab0e9a4 Remove GimpInt16Array
It isn't being used by any plug-in or any code in GIMP at all even.
Let's get rid of it while we can still break API, so we can cut down on
all the complexity of the gimp-param stuff a bit.
2021-02-18 11:32:45 +00:00
Niels De Graef bba70f5869 gimpparamspecs: Add annotations about array length
Although most GObject bindings can't really deal with struct fields,
it's still a nice thing to be able to see that these are actually arrays
(it also becomes visible in the Vala VAPI file).
2020-12-25 15:02:44 +01:00
Niels De Graef 79319803a2 GimpArray: Add missing array length GIR annotation 2020-10-28 20:51:48 +01:00
Niels De Graef 5092a32e75 gimpparamspecs: Add GIR annotations
I assume that we won't need most of these explicitly in bindings, but
_if_ it's needed, then it's best to make sure that people don't struggle
because they don't have proper API without annotations.
2020-06-06 13:22:57 +02:00
Michael Natterer 9a054fc248 libgimpbase: document the members of GimpArray, GimpStringArray
and GimpObjectArray.
2019-12-27 19:55:28 +01:00
Michael Natterer 0fefb7e922 libgimpbase: add GimpObjectArray and GimpParamSpecObjectArray 2019-09-05 13:01:00 +02:00
Michael Natterer 738b17063a libgimpbase: add an own struct for GimpStringArray
instead of re-using the GimpArray struct, which was confusing
particularly because of the meaning of the "length" member.
2019-09-05 13:01:00 +02:00
Michael Natterer d62e75a41f Move GimpParamSpecString from libgimp back to app
It's just too weird to be public. Remove its properties from the wire
protocol and from pluginrc. Instead, have all GParamSpecs' flags on
the wire and in pluginrc, so we can use stuff like
GIMP_PARAM_NO_VALIDATE.

Port the remaining few places to GIMP_PROC_ARG_STRING().

I'm sure something is broken now wrt UTF-8 validation,
will add tighter checks in the next commit.
2019-08-19 12:54:52 +02:00
Michael Natterer 652fd75891 Rename GIMP_TYPE_INT8_ARRAY to GIMP_TYPE_UINT8_ARRAY
and GimpParamSpecInt8Array to GimpParamSpecUInt8Array
2019-08-15 15:04:34 +02:00
Michael Natterer 350abba213 Remove GIMP_TYPE_INT16 and GimpParamSpecInt16
Use gint and GParamSpecInt with the right value range instead.
2019-08-15 14:17:17 +02:00
Michael Natterer 5a09523214 Remove GIMP_TYPE_INT32 and GimpParamSpecInt32
Use gint and GParamSpecInt instead.
2019-08-15 14:04:56 +02:00
Michael Natterer 1bf90ec77f Remove GIMP_TYPE_INT8 and GimpParamSpecInt8
Use guchar and GParamSpecUChar instead.
2019-08-15 13:34:11 +02:00
Michael Natterer 4add4c6645 libgimpbase: add a GimpStringArray typedef and use it 2019-08-09 12:54:09 +02:00
Michael Natterer 63695b4b21 libgimbase: merge gimpparam.h into gimpparamspecs.h
which means that it's now included normally via gimpbase.h
and not any longer via gimpbasetypes.h which we only did out
of lazyness. A *lot* of files in libgimp* and app/ now need to
2019-07-31 10:16:21 +02:00
Michael Natterer 76ee0f6559 app, libgimpbase: move lots of GValue and GParamSpec types to libgimpbase
all the stuff from app/core/gimpparamspecs.[ch] that is not about
image, drawable etc IDs, these will have to go to libgimp with
different implementations than in app/.
2019-07-26 15:54:33 +02:00