The previous PDB generation was losing pre-formatting inside
triple-backticked blocks. In particular we were losing indentation
(which was already ugly in C, but even syntactically wrong when
displaying Python code samples). And it was also making us add
double-newlines between every code lines, which was annoying.
This updated code now leaves triple-backticked sections as-is.
Unfortunately I was completely unable to do this by modifying the
existing functions, which were modifying the input arg in-place. So I
made them into functions returning the result. But then there is another
part of code (niceargs()) where changing array contents doesn't work
properly, and worse it seems to corrupt the array somehow (because I
have generation breakage in completely-different pieces of the PDB
generation code). I believe there is some passing-by reference/value
concepts in perl which I don't quite get (they use `&`, `\` and other
symbols and even searching for these, I don't quite understand how to
use them the right way) but I've spent already too much time on this. So
since I've got something working now by having duplicate functions, I'll
let someone else from the future, who knows better perl, re-merge these
functions if they know how.
The 'help' field needs to be single-quoted so that @-values do not look
like perl variables, hence breaking GIR annotations.
Fixing:
> Possible unintended interpolation of @Gimp in string at /home/jehan/dev/src/gimp/pdb/groups/item.pdb line 64.
I double-checked the gi-docgen docs and realized the "Note:" were all on
the same line as previous text. I had forgotten it just removed one
newline. So if I want a new paragraph (double-newline in markdown), I
need 3 newlines in the pdb file.
All the functions working with object's IDs are mostly internal. They
are still made public because they can be useful and are relevant in
specific use cases (i.e. using IDs to reference items in specific
widgets, such as drop-down lists, or when temporarily storing an item as
integer, etc.).
Yet it should be made clear that these usages are the exception rather
than the norm.
Otherwise, building the devel docs errors out like this:
```
FAILED: devel-docs/reference/gimp/libgimp-3.0
...
WARNING: Unknown namespace ExportReturn
[enum@ExportReturn.EXPORT].
^~~~~~~~~~~~~~~~~~~~~~~~~~
```
Signed-off-by: Nils Philippsen <nils@tiptoe.de>
- Fix annotations for gimp_export_options_get_image() to make it
actually introspectable with the GimpImage being both input and
output. Even though the logic doesn't change much (the input image may
be overriden or not), it doesn't matter for introspection because
images are handled centrally by libgimp and therefore must not be
freed. Actually deleting the image from the central list of images
though remains a manual action depending on code logic, not some
automatic action to be handled by binding engines.
- Add G_GNUC_WARN_UNUSED_RESULT to gimp_export_options_get_image()
because ignoring the returned value is rarely a good idea (as you
usually want to delete the image).
- Remove gimp_export_options_new(): we don't need this constructor
because at this point, the best is to tell plug-in developers to just
pass NULL everywhere. This leaves us free to create a more useful
default constructor if needed, in the future. Main description for
GimpExportOptions has also been updated to say this.
- Add a data_destroy callback for the user data passed in
gimp_export_procedure_set_capabilities().
- Fixing annotations of 'export_options' object from pdb/pdb.pl: input
args would actually be (nullable) and would not transfer ownership
(calling code must still free the object). Return value's ownership on
the other hand is fully transfered.
- Add C and Python unit testing for GimpExportOptions and
gimp_export_options_get_image() in particular.
- Fix or improve various details.
Note that I have also considered for a long time changing the signature
of gimp_export_options_get_image() to return a boolean indicating
whether `image` had been replaced (hence needed deletion) or not. This
also meant getting rid of the GimpExportReturn enum. Right now it would
work because there are no third case, but I was considering the future
possibility that for instance we got some impossible conversion for some
future capability. I'm not sure it would ever happen; and for sure, this
is not desirable because it implies an export failure a bit late in the
workflow. But just in case, let's keep the enum return value. It does
not even make the using code that much more complicated (well just a
value comparison instead of a simple boolean test).
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).
gimp-buffer-get-image-type returns the output of
gimp_babl_format_get_image_type (), which itself returns
a GimpImageType enum. However, the PDB claims that
it's a GimpImageBaseType enum instead. This patch fixes
the documentation to match the actual output enum type.
There was a weird instance of build failure in CI when compiling one of
the libgimpui files. It could not find one of the PDB-generated
function:
> ../libgimp/gimpaspectpreview.c:329:19: error: call to undeclared function 'gimp_image_get_selection'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
My assumption is that as a multi-threaded build, this file was compiled
just at the same time as the PDB was generating it, and therefore it was
empty, hence a very bad timing creating a build failure.
As I recall, I created the bogus stamp file stamp-pdbgen.h specifically
for such race condition issues (because meson has no generic dependency
rule, so we can't just ask one job to wait for another). We were using
this bogus object as source to libgimp, but not libgimpui.
Hopefully this will fix the problem and it won't re-happen randomly.
Unlike the other bindings (Lua, JS, Vala) where we only have a demo
plug-in, we actually have a bunch of interesting and useful Python
plug-ins.
Furthermore, we are running several Python scripts through GIMP during
our build (to generate a few images), so pygobject becomes a build
dependency anyway, even if it may not be a run dependency with
-Dpython=disabled.
This all becomes a bit confusing and in fact handling this case (of not
installing Python plug-ins) seems like an annoyance while we lose good
core plug-ins. So let's just make Python plug-ins mandatory. It's not
like Python is very controversial these days, and AFAWK, it is available
on every platform out there.
Rather than trying to implement full i18n plural support, we just remove
this failed attempt from the past. The fact is that to get proper
support, we'd basically need to reimplement a Gettext-like plural
definition syntax within our API, then ask people to write down this
plural definition for their language, then to write every plural form…
all this for custom units which only them will ever see!
Moreover code investigation shows that the singular form was simply
never used, and the plural form was always used (whatever the actual
unit value displayed).
As for the "identifier", this was a text which was never shown anywhere
(except in the unit editor) and for all built-in units, as well as
default unitrc units, it was equivalent to the English plural value.
So we now just have a unique name which is the "long label" to be used
everywhere in the GUI, and abbreviation will be basically the "short
label". That's it. No useless (or worse, not actually usable because it
was not generic internationalization) values anymore!
Legacy plug-ins like Checkerboard (legacy) under Render Patterns lost
their Help button, although using F1 was still working.
Due to changes in how procedures are called, `gimp_dialog_constructed`
was called before the help-id was set.
The simplest way to fix this, is to call
`G_OBJECT_CLASS (parent_class)->constructed (object);`
at a later time in `gimp_procedure_dialog_constructed` after we have
set the help-id there.
Right now, it only tests a few API, such as creating an image, then a
text layer, then inserting it in the image.
This is a test to avoid regression bug after having fixed#9923 in a
previous commit.
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.
We allow passing NULL gvalue for an empty GimpObjectArray, for convenience.
For example to plugin sel2path which doesn't use drawables.
But crossing the wire, create an empty GimpObjectArray
having an arbitrary type for elements.
...in non-interactive cases.
gimp_export_image () handles various
tasks like rasterizing NDE filters. It only
runs in interactive cases however, so if the
users calls gimp-file-save the filters are
not exported.
Since Jehan removed the hidden dialogue
in 0dc9ff7c, we can now safely call
gimp_export_image () in all cases to make
image export more consistent. This step is
also preparation for setting up the new
API with GimpExportOptions.
GimpPlugin improperly destroys proxies after each run of a temporary procedure.
A temporary procedure may pass reference to proxy to main procedure.
Proxies should live as long as the main procedure of a plugin,
or for an extension plugin, until only the extension main procedure
is on the procedure stack. More discussion in the issue.
Extract method gimp_plug_in_proc_run.
Call it from two new methods: main_proc_run and temp_proc_run,
which do more e.g. cleanup.
Extract methods for cleanup, main_proc_cleanup and temp_proc_cleanup
Add method is_proc_stack_empty
Though I am not fond of these macros for our core code (it makes the
code more cumbersome especially for using private data in derivable
types), this definitely makes sense for public API, since it would allow
easier modifications with less chances of messing API/ABI stability.
...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.
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.
...to paths.
Similar to d0bdbdfd, but covering the
app/core versions of the API instead of
libgimp. Changes the names of
gimp_image_*_vectors () API to
gimp_image_*_path[s] ().
Also renames some related functions such
as gimp_image_pick_path (). The next step
will be to rename the gimp_vectors_* () to
gimp_path_* ().
Refactor: extract method gimp_widget_free_native_handle.
This reduces duplication of code and encapsulates Wayland specific code.
Call the new function in more places.
This is expected to fix#11613 but it is hard to be sure
since the exact sequence of events in 11613 was never determined
and only reproduceable in some flatpak builds.
Calling the new function in more places also should eliminate leaks.
But I did not test there was a leak prior to this fix.
...to paths
Follow-up to d0bdbdfd. Changes all
gimp_vectors_* () PDB to gimp_path_* ()
and renames relevant PDB files from
vectors to path.
The next step will be to rename
GimpVectors in libgimp to GimpPath,
removing the last (public) trace of it.
...to paths
The first step in converting GimpVectors
to GimpPath. The PDB API for any
gimp_image_*_vectors () is now
gimp_image_*_paths ().
This commit only covers libgimp, and
the app/core versions will be renamed in
a following commit.
Functions creating a new GeglBuffer should trigger a warning if the
result if unused, because this is potentially a big memory leak.
Similarly objects created by functions creating new layers should be
handled (usually by adding the layer to the image with
gimp_image_insert_layer()), because they also come with a buffer and
possibly quite some important memory leak.
If the type is not registered, g_type_from_name() is not able to find
the GType from the type name.
Fixes:
> gimp_gp_param_to_value: type name GimpGroupLayer is not registered
Also add a bit more type handling code.
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! :-)
In most bindings, they would just result in the same signature as the
_get_ variants (which people have been used to, since the GIMP 2
series). Also I was told that apparently in some bindings where this
would make a different signature, the (skip) annotation could be ignored
anyway.
The original reason to skip these was because the new _list_ API were
introspected basically to a similar function signature, except with a
useless return value, at least in pygobject binding where the list size
was also returned.
Though it seems that in fact, only the docstring was wrong. The real
signature was apparently already the same.
See: https://gitlab.gnome.org/GNOME/pygobject/-/issues/352
Therefore since the _get_ naming is more consistent compared to other
existing function, let's re-integrate the _get_ functions for array of
items or images.
This basically reverts commit 15ec254148.
Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value().
We now have specific public functions for every supported type and it's
in fact much better to use them. The generic functions gave the feeling
that we could use any GParamSpec as procedure argument, whereas we in
fact depend on what the PDB support, and only these subtypes.
These were created because of some limitation/bug in pygobject, which is
now much better worked around by having specific functions for every
argument type supported by the PDB.
Resolves#11018.
Currently, babl formats are saved as strings when
passed as params. However, indexed palettes do not
use a "standard" encoding string but are created from
palettes (with a custom format). This results in an
error when we attempt to recreate the babl format from
the custom string encoding, as it doesn't exist at that
point.
This patch mitigates the problem by converting the indexed
color to RGB/A 8-bit when used in params. In the future when
indexed mode supports different color spaces and higher
precision, we will need to remove the hard coding. For now,
it solves the immediate problem.
With the new API introduced int d1c4457f,
we next need to port all plug-ins using
the argument macros to functions.
This will allow us to remove the macros
as part of the 3.0 API clean-up.
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.
While setting a plug-in as transient usually worked, it was failing in
cases the plug-in's progress bar was not initialized (i.e. if
progress_init() was not called before setting the dialog transient).
This commit stores the calling display, core side too (libgimp side, the
plug-in already had the calling display ID information), and we use this
when a GimpProgress has not been created yet.
… native dimensions/ratio display by default.
Also adding gimp_vector_load_procedure_extract_dimensions() public
function allowing plug-ins to query the native size or ratio of a vector
file.
Previous gimp_procedure_run_config() was in fact only good for private usage
inside the various run() methods for the different GimpProcedure subtypes. The
problem with this implementation is that the returned config object is not
complete. For instance, for a GimpLoadProcedure, the "run-mode" and "file"
properties are not part of the config object so you cannot call a
GimpLoadProcedure with any of the gimp_procedure_run*() functions.
Note: we had some working usage, e.g. in file-openraster, but only because it
was running the load procedure as a GimpPDBProcedure whose returned config
object was indeed always complete!
As a consequence, I rename gimp_procedure_run_config() as an internal-only
function _gimp_procedure_create_run_config() and I create a new
gimp_procedure_run_config() which always return a full config with all
arguments.
It was a bad idea to bind width/height with pixel density. These are separate
things. You may want to set specific pixel dimensions while keeping a given
resolution.
Moreover I am now properly storing aspect ratio in the widget, otherwise with
integer computation, we are just losing too much precision and the ratio is in
fact changing constantly as you change dimensions.
The bogus 0×0 default values for width×height properties are only because we
don't know the real native size of the image. Once we have computed it, we can
change the param spec defaults, so that hitting "Reset to Factory Defaults" sets
width, height and resolution to the actual file's default values (if resolution
is not a metadata in the format, which is apparently the case for all vector
formats we currently support, then 300.0 stays the default resolution).
I'm moving the logic of choosing a correct default for width/height by adding an
"extract dimensions" callback in the procedure. The logic is that every vector
format out there should likely have metadata either for pixel dimensions or
physical dimensions, or at the very least for no-unit dimensions (ratio only).
Vector load procedures will have to implement only the extraction of such data
in a callback called by GIMP but not how to act upon them, so that we have a
common logic for all vector images.
I am implementing this callback first in the SVG plug-in, moving all the code
to extract dimensions (and improving it) in this callback.
Also I am deleting "file-svg-load-thumb" procedure. I could simply reimplement
it using the same code, but it looks to me like this is very useless for vector
formats to have a specific thumbnail procedure (unless it were to use very
specific metadata for faster result). This is vector data, just ask it directly
at the proper bounding box size.
This includes a new function gimp_prop_choice_radio_frame_new() which
creates GimpIntRadioFrame from GimpChoice properties.
GimpChoice GimpProcedure arguments are still creating a combo box by
default, but it is now possible to override this default behavior to get
a radio frame by calling first:
```C
gimp_procedure_dialog_get_widget (dialog, "arg-name", GIMP_TYPE_INT_RADIO_FRAME);
```
Some apps that write EXIF metadata, forgot to add the charset to
certain tags that require it. The main case is Exif.Photo.UserComment.
This caused us to show a warning about an invalid charset, in addition
to not showing it in our Metdata Viewer.
We fix this by reading the raw data for that tag when we encounter the
above error. The raw data is then validated as utf-8 and converted
to a string if valid.
We then resave this tag to our metadata to force it to have the
correct charset; that way we don't have to do any checking in other
places in our code.
Note: there are a few other tags that also use a charset. We may have
to check those too, eventually.
By defining `GIMP_DISABLE_DEPRECATED` when creating the GObject
Introspection file, we're actually not (or only partially) generating
some of the documentation of some files that are marked as deprecated.
One example that should now properly generate documentation is
`GimpFileEntry`.
As noted by Anders Jonsson, the wrong parameter description
was removed when the API was updated. Other aspects of the
descriptions were also updated to account for the change.
Port all plug-ins to retrieve the layers
directly from the image rather than
having them passed in. This resolves some
issues with introspection and sets the
foundation for future API work.
- Fix a few broken references and an inconsistent argument name.
- Add the new headers in the introspectable header list.
- Add a few missing class descriptions for GimpProcedure and subclasses.
Instead of filling default GUI for a specific type of plug-in procedure in
fill_list(), we add 2 methods:
* fill_start() is ensured to run once (and only once) before any fill_list()
code runs.
* fill_end() is ensured to run once (and only once) after all fill_list() ran.
This takes care of 2 kind of GUI bugs which we could have:
1. First if no explicit fill were run (i.e. neither gimp_procedure_dialog_fill()
nor gimp_procedure_dialog_fill_list() were ever run), then the default
interface would not be added to the dialog. Yet this case could happen when
we don't want anything else but the default GUI (this will be the case in the
upcoming file-wmf-load GUI).
2. Second if at the opposite, you fill several times fill functions (I hadn't
thought of this, but noticed some already started to do this in our ported
plug-ins), we obviously don't want the default GUI to be added several times
either.
As expected, it is made to reuse shared code for every GimpVectorLoadProcedure.
In particular, they all need to choose dimensions to load at, so we are sharing
a same GimpResolutionEntry widget logic everywhere now.
I am in fact still very unsure about the code logic for this widget by the way
for these reasons:
* It still puts too much emphasis on the "resolution" (pixel density) part,
which makes people believe it's important, while they should in fact choose
the pixel dimensions most of the time and not care about the pixel density.
* Right now we can't break ratio (which in fact was already impossible in most
vector format plug-ins we had). Do we want to add a chain and allow this?
* If we consider the pixel density as the one we want to set the document with
(which may not be the same thing as the one from when we load the document),
we also want to break link between width/height dimensions and pixel density.
Right now we can't (updating one field updates the others too).
* There is always this issue of precision with pixel density vs. pixel
dimensions because we don't necessarily find the same values when computing
from one side to another because of lack of precision and this confuses
people.
* Finally there is the question of multi-page documents (e.g. PDF) where the
chosen dimensions are the document dimensions whereas each page may have a
different size which has to be recomputed independently and this got me
off-by-one errors. I think I'll need to review a bit the logic, but I'll do
once I've ported all the vector format load plug-ins first to see the most
common usages.
The code comes from plug-ins/common/file-pdf-load.c and apparently it used to be
in libgimpwidgets (very long ago). I'm copying it to its own file and massively
improve the code (depending on property binding which makes the behavior much
more robust).
Still I left it as private because I don't want to say the API is finale without
having tested it a bit more. But eventually we should make it public for
plug-ins to use it directly too. When this happens, it should get back to
libgimpwidgets.
It's still basic but will help to share code for support of various vector-able
formats, such as the logic for dimensioning them, but also the generated GUI.
Not only this, but we are paving the way for the link layers (though it'll be
after GIMP 3, we want plug-in procedures' API to stay stable) by giving a way
for a plug-in procedure to advertize a vector format support. This way, the core
will know when a source file is vector and can be directly reloaded at any
target size (right now, in my MR for link layers, the list of "vector" formats
is hardcoded, which is not reliable).
When there is a very long comment shown in the export dialog, the
dialog expands horizontally. Possibly making it wider than your screen
instead of wrapping the text.
Let's set word wrapping for the text view. That way the text will
wrap at a reasonable length and use the multiline text view instead
of just the first line.
… since forever anyway!
GIMP used to have a second export dialog, a generically generated one, appearing
either before or after (depending on when gimp_export_image() was called) the
custom export dialog implemented by the plug-in code. This has been hidden deep
in code since forever (since version 2.8.0 in fact, I believe) and only kept
hidden behind an environment variable "GIMP_INTERACTIVE_EXPORT". I don't think
we'll ever revive this, so let's clean up.
In fact, not one, but in worst case even 2 more dialogs were hidden behind this
variable! The first dialog (confirm_save_dialog()) was a confirmation when the
selected drawable was a layer mask or a channel (and not a layer). Most export
code don't even seem to care about the selected drawables anymore anyway (cf.
issue #7370), except with gimp_file_save() non-interactively (issue #8855),
which is a real mess of inconsistency anyway.
The second dialog (export_dialog()) was listing the various actions to do on a
copy of the image to help the plug-in (e.g. merge layers/flatten image, etc.)
and possibly give choices to some of these actions. Though there is definitely
no reason to request this kind of thing anymore, especially for a short-lasting
image copy, the list of action could still be interesting in the future, not as
information of what is going to be done, but as information of the kind of data
loss of the exported format. I could imagine we want to be able to reuse such
information for generating types of data loss per format in the export dialog,
in particular in the context of my long-term export workflow refactoring (from
which resizing before export such as #2531 are part of, but the whole
refactoring project is much wider).
In the whole discussion of #5858, there will be the question on whether we don't
want plug-ins to be directly given a "ready-to-use" image depending on
capabilities they advertized in create_procedure().
… test-color-parser.c file.
The file libgimpcolor/test-color-parser.c was compiled but never actually called
by the build. Now that we have a nice infrastructure to test libgimp API, I am
moving it there with the new format. Doing this also allowed me to discover some
bugs in CSS parsing, as well as discover Python binding was failing here (cf.
the few previous commits).
Only one test is disabled so far, the one where 4 digits are used per channel in
hexadecimal notation: "#64649595eded". This format simply doesn't appear
anywhere in the spec, and also the result values in the samples listing don't
even fit. So far, I'm just unsure what to do with it, if we want to keep this
support (of some kind of higher precision hex notation, but not specified, so is
it even used by anyone?) or not.
All the other tests just work in both C and Python!
This is meant to obsolete GeglParamColor with at least an additional argument
has_alpha which we need in GIMP. It allows to advertize when a parameter wants
an opaque color, which in particular means we know when displaying a GUI to pick
colors with alpha or not.
In some binding (e.g. Python), we have not found how to create GeglParamColor
specs for PDB procedures, so we use GParamObject specs with `GeglColor`
object_type. Have our code handle both variants.
Fixes:
> GIMP-WARNING: _gimp_gp_param_def_to_param_spec: GParamSpec type unsupported 'GeglParamColor'
Of course such generic spec won't have any future option which we may add to a
dedicated param spec (and despite adding code to handle a default value, adding
a default color still doesn't work according to tests).
There are no plug-ins which uses GimpRGB for procedure argument, nor is there
any base PDB procedure. We don't pass this type anymore through from/to
core/plug-ins. So let's clean the whole code out as a next step to get rid of
GimpRGB from our codebase!
The comment I had written back then was wrong. Meson in fact can create an env
object from another with a simple assignment (which copies the object, rather
than pointing to a same object), per the answer which has been given to me in:
https://github.com/mesonbuild/meson/issues/13045
This allows to have a properly separate environment (when using GIMP as a build
tool, we don't want to load the test files).
The previous commit worked for all the compiled executables, but for Python
plug-ins (and likely all other GObject-Introspected bindings), we need to
generate a temporary typelib linking to the in-build-directory libgimp*
libraries.
This is similar to what the script `package/macports_build_app.sh` does for
packaging in gimp-macos-build repository.
Calling gimp_selection_float from a Python plug-in could make it crash
with an error like Calling error for procedure 'gimp-selection-float':
Item x cannot be used because it is not a group item.
This is caused by an incorrect check for group layers.
gimp_pdb_item_is_group returns an error when the condition is False,
while we only want an error when a group layer is selected (True).
Thus we need to use gimp_pdb_item_is_not_group, which returns an error
when the item is a group, which is what we want.
These function names are a little confusing, we might need to think
about better naming sometime.
I added C/Python tests for this function, so that we can test whether
this works correctly.
Without this, there is no easy way to quietly check for existence of a resource by name.
Needed when plugin authors can name defaults for resource args by name.
Add tests to script-fu/test/tests
Mainly fixing GimpRGB comments and
parameters that are unused (or in unused
functions).
GimpCircle and GimpGradientChooser
have color conversions ported to use
GeglColor exclusively.
- Replaces GimpRGB in Channel Dialog
with gdouble array, as was done in
channel_options_color_changed ()
- Replace %ld with G_GSIZE_FORMAT
in libgimp checkboard color message to
fix warning in Windows build
- Set file-gih documentation text as
translatable.
Resolves#10992.
GimpTextLayer's color attribute was
updated from GimpRGB to GeglColor,
but gimp-text-layer-set-color still passed
in GimpRGB. This patch updates the PDB
call to match the property type.
Most of the C boiler-plate code is generated so that all you have to do is
implement the run() function with test code in it.
Also adding a README to make it all very clear and easy to add new tests.
With Python binding, it gets very easy to test new functions. I've been
wondering if we need C counterparts, but really since it's a GObject
Introspection binding, if a function succeeds there, it should also succeed in C
code.
For now, I'm testing a few of GimpPalette API. Not all of it yet. Also I test
both the direct C binding and PDB procedure since in some cases, one or the
other may not properly working. See #10885.
We were missing GimpColorArray support in one function. Note that the specific
example in Python in #10885 still doesn't work, but for a second reason:
gimp_value_array_index() returns a GValue which pygobject automatically tries to
transform to the contained data. And unfortunately it doesn't know about our
GimpColorArray type so we end with unusable boxed type generic data.
Since the color space invasion, GimpRGB
properties do not create widgets anymore.
For Python plug-ins, we need to add
GeglColor properties as GObjects with
GeglColor value types as a workaround.
This patch does this and updates the
Foggify plug-in with the new datatype.
Though I had already implemented passing GeglColor through the PDB, it was not
complete. In particular, the protocol was not able to pass GeglParamColor specs.
Fixes:
> LibGimp-WARNING **: 16:06:09.451: _gimp_gp_param_def_to_param_spec: GParamSpec type unsupported 'GeglParamColor'
This is part of the fix to issue #10811, though it's not complete yet.
I still see some limitations in GimpGradient, and in particular, they are still
always stored as RGB in GGR files. It would be nice if we could store the actual
color format. This way, if someone chooses a gradient stop as Lab or CMYK color,
that's what the gradient file would keep track of. But also even storing the
space of a color (instead of storing/loading always in sRGB, even though this
may still work fine as we store unbounded double values). This might warrant for
a v2 of GGR file format.
This commit also fixes loading of SVG gradient which was apparently broken
regarding hexadecimal color parsing.
Finally I improve gegl_color_set_alpha() by adding an alpha channel when the
initial format had none.
The invasion extended to some core widgets too, in particular GimpColorPanel (a
subclass of GimpColorButton). There was quite a lot of code depending on these
widgets.
We pass 2 GeglColor through the wire now. Since it is passed very early
(when sharing the configuration), I had some issues with initialization
order of GEGL, and in particular when calling gegl_init() before
gegl_config() inside _gimp_config(), I had a bunch of such criticals:
> Plugin script-fu: GLib-GObject: CRITICAL: Two different plugins tried to register 'GeglOpPlugIn-transform-core'
Anyway in the end, I store the passed colors as raw bytes and strings in
the GPConfig object, and re-construct the GeglColor last minute in
_gimp_config().
One of the big improvement in this commit is that text layers are now much
better at space accuracy. They were already space-aware, yet rendered as sRGB u8
only before being converted to the image's space. It means that text layers had
the following limitations:
* Any color out of sRGB gamut were trimmed.
* Precision was always 8-bit (even if the image was high-bit depth).
Now GimpTextLayout keeps track of its source space (for RGB and CMYK only, this
won't be as easy when we will support more backend, since Cairo has only RGB
support for image data) and the image TRC (in case it bypasses the color space's
TRB) and it draws within this gamut and space.
It means first that we are not limited to sRGB colors; we will draw text main
color in the full image gamut, with still 2 remaining limitations:
* Unbounded colors are impossible because Pango format (to color text) uses
hexadecimal (so even with half/float images, you can't draw out-of-gamut text
unfortunately).
* Main color precision is still 8-bit, yet a tiny bit better than before as we
at least follow TRC (so we avoid some of the precision loss when converting,
even though the bit-depth is still the biggest loss).
The outline color on the other hand is drawn through Cairo API entirely, in
float. This means that the outline color will now be without any precision loss.
Note that this depends on CAIRO_FORMAT_RGBA128F which is only available since
Cairo 1.17.2 which is not in Debian bookworm (our current baseline for GIMP
3.0). It means that the old precision will still happen with older Cairo
version, as determined by #if code at compilation.
- app: gimp_context_get_(foreground|background)() are now returning a GeglColor.
- libgimp: PDB functions named similarly in libgimp are returning a newly
allocated GeglColor too.
- A few other PDB functions (the ones using these functions) were updated and
their signature changed to use GeglColor too, when relevant. Plug-ins which
use any of the changed libgimp functions were fixed.
- GimpContext: signals "(foreground|background)-changed" are now passing a
GeglColor.
- libgimpconfig: new macro GIMP_CONFIG_PROP_COLOR using gegl_param_spec_color().
- GimpContext: properties "foreground" and "background" are now GeglParamColor
properties.
- app: All code interacting with GimpContext objects were updated to receive a
GeglColor (that they may still convert, or no, to GimpRGB for now).
- app: gimp_prop_gegl_color_button_new() was added as an alternative to
gimp_prop_color_button_new() when the property is a GeglParamColor. Eventually
the former should replace completely the latter.
- libgimpwidgets: gimp_prop_color_area_new() now works on GeglParamColor
properties only.
- libgimp: gimp_procedure_dialog_get_widget() will generate a GimpColorArea for
GeglTypeParamColor arguments.
Also the color is internally stored as GeglColor, though there are still get
APIs and signals using GimpRGB.
The equivalent PDB functions are also changed to use GeglColor, same as app/
functions.
This is a first commit to really getting rid of GimpRGB within core and
PDB/plug-in code. This will make color conversion reliability a lot better as
GeglColor will handle conversions for us. The goal is that we should keep origin
color space (for instance when picking colors in a GimpPickable, or when storing
in the FG/BG colors or in paletters) until the last second and convert at use
only.
It's still very much work-in-progress.
These 2 functions were removed in commit 89c359ce. They were in fact used and
clearly this historical API seems interesting (though we can likely do the same
thing using the drawable GeglBuffer, but this way is much easier).
This is now reimplemented using GeglColor instead of raw data.
Eventually this is meant to fully replace GimpRGB (as well as GimpHSV, GimpHSL
and GimpCMYK), both in libgimp and in core code, as part of both the space
invasion and the API rework. For this first commit, I keep this new object side
by side to GimpRGB.
MINGW64
- uses 0x601 as value for _WIN32_WINNT. No need for us to define
it to that value or even lower values in some places.
This also gets rid of: warning: "_WIN32_WINNT" redefined
- has 0x0502 for WINVER, so get rid of us setting it to 0x0500 in
gimp-app-test-utils.h. It also seems that the need to use G_OS_WIN32
has disappeared here.
- DIRECTINPUT_VERSION is 0x0800, no need for us to set it to that value.
- AI_ADDRCONFIG was apparently missing from the MINGW headers in the
past, but not anymore.
- Do not leak allocated return value of gegl_node_to_xml_full().
- When merging layer effects, use gimp_drawable_filter_commit(), making
sure we use the exact same code path as when applying layer effects
destructively from the start. This also ensures that filters are
properly removed from the filter stack (unlike
gimp_drawable_merge_filter()), which was the reason why the rendering
was wrong (hence getting the buffer without effects first, then
reapplying it after was only a workaround to an actual bug).
- When removing a filter, verify the object still exists before doing
anything with it. If this was the last reference, we don't want to
call functions on this object. In gimp_drawable_filter_commit(), we
set up a weak pointer. In gimp_drawable_filter_remove_filter() itself,
we save the pointer to the filter's drawable before actual removal (as
we don't want to dereference a freed object later on).
- export_merge_layer_effects() should merge filters recursively through
layer groups.
- clean up the XCF code:
* No need to wrap the effect pointers list into 2 zero offset. Only
have one zero offset to indicate the list end.
* Add the layer effect mask in the effect structure (not in the layer
structure), similar as for layer masks.
* Effect name and icon made as main data in the structure, not as
properties.
This patch implements an initial form of
non-destructive editing. Filters now stay active
instead of being immediately merged down.
A new column is added to the layer tree view, which
can be clicked to show a pop-over menu.
Filters can currently be hidden/shown, edited, reordered,
deleted, and merged down from this pop-over menu.
Currently, this works on layers and layer selections only.
Plenty of room for improvement!
Resolves#10651
The "Remove All Guides" script calls
gimp-image-find-next-guide, which per
its description can take in 0. However,
the parameter sets 1 as the minimum
value.
This patch fixes the range so that it can
accept 0, which enables the Remove All
Guides script to work again.
It also updates the script to the new
multi-layer aware API.
Due to GObject Introspection we can't have the last part of an
identifier start with a digit, since that part will be used in Python
as the identifier, and Python doesn't allow that to start with a digit.
e.g. GIMP_ROTATE_90 would be used in Python as
image.rotate(Gimp.RotationType.90)
To fix this we add DEGREES in front of the number, without a '_',
even though that looks ugly.
These are not usable by plug-ins anymore which should store their data between
runs as arguments or aux arguments (in case of values which should be stored
from one run to another but are not really usable for non-interactive scripts).
These are per-plug-in (not polluting the whole process space with just random
strings as identifiers which could be used by other plug-ins) and even survive
restarts of GIMP.
I still keep these functions, but only internally, as they are used to store
settings of GimpAspectPreview, GimpDrawablePreview and GimpZoomPreview across
plug-in runs. Still I changed their API to set and return a GBytes directly
(mimicking the private PDB functions' API).
Also I remove gimp_pdb_get_data_size() which is useless when exchanging GBytes
directly.
Note that the 2 functions are still exported in the library, and only not
advertized through headers (so they are not really internal, just hidden), on
purpose, because we need to call them in libgimpui. So it is still relatively
easy for a plug-in to use them. Nevertheless I made clear in the function
documentation that these must not be considered public and could end up deleted
at any time. Any plug-in still trying to call these takes the risk of having
their code relying on unreliable API.
gimp_procedure_new_return_values() takes ownership of the passed GError (it
allows, among other things, to call it directly as return value). So we must not
try and free it afterwards.
The gimp_procedure_run() already existed, though it was with an ordered
GimpValueArray array of arguments. Its usage feels redundant to the series of
gimp_pdb_run_procedure*() functions (which is confusing), but
gimp_procedure_run() was actually a bit more generic, because it does not
necessarily calls GimpProcedure-s through the PDB! For instance, it can runs a
local GimpProcedure, such as the case of one procedure which would want to call
another procedure in the same plug-in, but without having to go through PDB. Of
course, for local code, you may as well run relevant functions directly, yet it
makes sense that if one of the redundant-looking function is removed, it should
be the more specific one. Also gimp_procedure_run() feels a lot simpler and
logical, API wise.
A main difference in usage is that now, plug-in developers have to first
explicitly look up the GimpPdbProcedure with gimp_pdb_lookup_procedure() when
they wish to call PDB procedures on the wire. This was done anyway in the
gimp_pdb_run_procedure*() code, now it's explicit (rather than calling by name
directly).
Concretely:
* gimp_pdb_run_procedure(), gimp_pdb_run_procedure_config() and
gimp_pdb_run_procedure_valist() are removed.
* gimp_procedure_run() API is modified to use a variable args list instead of a
GimpValueArray.
* gimp_procedure_run_config() and gimp_procedure_run_valist() are added.
* gimp_procedure_run_config() in particular will be the one used in bindings
which don't have variable args support through a (rename-to
gimp_procedure_run) annotation.
Passing (name, type, value) triplets is actually useless because we can get the
type information from the procedure/config anyway. That only adds one more
verification to do. Let's just change the function so that we pass (name, value)
couples instead, pretty much like in `g_object_set()`.
As far as plug-in API is concerned, at least the calling API, order of arguments
when calling PDB procedures doesn't matter anymore.
Order still matters for creating procedures with standard arguments (for
instance, "run-mode" is first, then image, or file, drawables or whatnot,
depending on the subtype of procedure), but not for calling with libgimp.
Concretely in this commit:
- gimp_pdb_run_procedure_argv() was removed as it's intrinsically order-based.
- gimp_pdb_run_procedure() and gimp_pdb_run_procedure_valist() stay but their
semantic changes. Instead of an ordered list of (type, value) couple, it's now
an unordered list of (name, type, value) triplets. This way, you can also
ignore as many args as you want if you intend to keep them default. For
instance, say you have a procedure with 20 args and you only want to change
the last one and keep the 19 first with default values: while you used to have
to write down all 20 args annoyingly, now you can just list the only arg you
care about.
There are 2 important consequences here:
1. Calling PDB procedures becomes much more semantic, which means scripts with
PDB calls are simpler (smaller list of arguments) and easier to read (when
you had 5 int arguments in a row, you couldn't know what they refer to,
except by always checking the PDB source; now you'll have associated names,
such as "width", "height" and so on) hence maintain.
2. We will have the ability to add arguments and even order the new arguments in
middle of existing arguments without breaking compatibility. The only thing
which will matter will be that default values of new arguments will have to
behave like when the arg didn't exist. This way, existing scripts will not be
broken. This will avoid us having to always create variants of PDB procedure
(like original "file-bla-save", then variant "file-bla-save-2" and so on)
each time we add arguments.
Note: gimp_pdb_run_procedure_array() was not removed yet because it's currently
used by the PDB. To be followed.
This partially revert some of the changes in commit 652a1b4388 because the
Windows CI suddenly failed because of this (my local build on Linux didn't have
any problem though) with:
> /usr/bin/x86_64-w64-mingw32-ld: libgimp/libgimpui-3.0-0.dll.p/gimpproceduredialog.c.obj: in function `gimp_procedure_dialog_save_defaults':
> /builds/GNOME/gimp/_build/../libgimp/gimpproceduredialog.c:2570:(.text+0x633): undefined reference to `_gimp_procedure_config_save_default'
> /usr/bin/x86_64-w64-mingw32-ld: /builds/GNOME/gimp/_build/../libgimp/gimpproceduredialog.c:2576:(.text+0x644): undefined reference to `_gimp_procedure_config_has_default'
> /usr/bin/x86_64-w64-mingw32-ld: libgimp/libgimpui-3.0-0.dll.p/gimpproceduredialog.c.obj: in function `gimp_procedure_dialog_load_defaults':
> /builds/GNOME/gimp/_build/../libgimp/gimpproceduredialog.c:2549:(.text+0xa2f): undefined reference to `_gimp_procedure_config_load_default'
> /usr/bin/x86_64-w64-mingw32-ld: libgimp/libgimpui-3.0-0.dll.p/gimpproceduredialog.c.obj: in function `gimp_procedure_dialog_constructed':
> /builds/GNOME/gimp/_build/../libgimp/gimpproceduredialog.c:368:(.text+0x11b1): undefined reference to `_gimp_procedure_config_has_default'
This is because these functions are used not only inside libgimp but also
across inside libgimpui. As a consequence, the build fails when linking
libgimpui.
This goes with our planned change of not making GimpProcedure arguments order
relevant anymore regarding the PDB API. In particular, it means we don't want to
use GimpValueArray for various procedure arguments API, but directly
GimpProcedureConfig objects.
This change will allow to add or reorder arguments in the future, so that we
won't have to create new PDB procedures when adding new arguments, while still
keeping PDB API stability.
Some of these should not even be visible by libgimp and were just fine as static
as well! For the rest, I make them really private (not only with a private
header).
We cannot be 100% sure generically (i.e. for all possible bindings available
with GObject Introspection) if bindings add their own reference to objects or
not. Clearly we have cases when they always do (Lua, Javascript), cases when
they do only in certain conditions (global Python variables) and cases when they
don't (Vala). What we know for sure is that in these script languages,
developers don't manually manage memory anyway. So the additional reference is
not their fact.
So let's just maintain a list of automatic memory managed binding languages,
among the few we officially support (i.e. the ones for which we have working
test plug-ins) and verify by executable extension if the plug-in is written in
one of these.
Both keeping a manually-updated list and verifying by extension are not so
pretty solution, but for now it will do.
As explained in the comment above, the reference might actually be owned by the
binding code (not by the plug-in code) and therefore can still be released
afterwards. Freeing it now while we don't own the reference exposes us to
double-free crashes.
Until now, it was not really possible to delete a colormap color, but since we
now use GimpPalette, people would definitely try to do so. It just makes sense
to allow doing this, but only if the color is unused.
Additionally when we do this, all the pixels refering to bigger indexes will be
edited so that they continue to refer to the same color (bigger indexes are
shifted by -1). Therefore removing an unused color does not change the image
render.
I wondered if we might want more options, e.g. the ability to delete a color
without fixing indexes (i.e. that colors over the deleted color index would
shift to the next color). This would even allow to delete used colors (though
now the last index would have to be unused one, unless we cycle colors).
Yet I don't think this should belong to this basic API. The most expected
behavior when deleting a color from an image colormap is to fix all indexes
stored in pixels so that the image still shows the same. So that's what this
function will do in this generic usage.
This is meant to replace gimp_image_get_colormap() (see also #9477).
We likely won't need a gimp_image_set_palette() because we can simply edit the
image's colormap/palette with GimpPalette API now and it is directly updated.
For instance, the following code changes the first entry in the image palette to
red, immediately:
```python
i = Gimp.list_images()[0]
p = i.get_palette()
c = Gimp.RGB()
c.r = 1.0
p.entry_set_color(0, c)
```
For this to work fine, I added a new concept to GimpData, which is that they can
be tied to a GimpImage (instead of a GFile). Image palettes are not considered
internals, they are just tied to their image, therefore they can be edited by
scripts/plug-ins.
Additionally with this commit, editing an image's colormap from libgimp API also
generates undo steps now.
Jehan