It may be more efficient this way on supported compilers.
Some of the private functions cannot be marked with this macro because
they are used across GIMP libraries (for instance some libgimp
functions are used in libgimpui, but are not meant to be public), while
they are not made public in headers. These are still considered private,
as far as API stability is concerned.
Preferences > Image Import and Export tab has various Export Policies,
which are mostly for safety reasons. One may want to default at never
exporting specific metadata. This got broken and anyway the logic was
not good enough.
Now these policies are followed in interactive mode, unless an export
has already happened for this specific export plug-in on this specific
file (in this case, we reuse the last values). We don't want settings to
unexpectedly change in such a case.
In last-vals and non-interactive run-mode though, we don't follow the
Preferences policies, since in the former case, we want to reuse exactly
the same settings (e.g. we don't want an Export discarding metadata
which explicitly checked in the Export As) and in the latter case, it is
the developer's responsibility to set up expected options.
gimp_image_metadata_load_prepare(), gimp_image_metadata_load_finish()
and gimp_image_metadata_save_finish() are only ever used internally now,
so there is no need to expose them.
If we realize that we need them as public functions later, or someone
reports a valid use case, we can always bring them back later.
Also improves a bit various annotations.
On generating our PDB files, we were
getting warnings about uninitialized strings.
This is because descriptions and authors
had been left off three .pdb files. Adding
these in resolved the warnings.
A new PDB author entry was also added
for Idriss Fekir.
These function names look like they should be applied to a
GimpPaletteEntry, which is a type which doesn't exist in libgimp. This
naming is much more appropriate.
Fix a generic case when gimp_window_set_transient() is called on an
already mapped window: the handle argument was missing.
The part in bmp-export though, in fact, I am still a bit at a loss.
Somehow calling gimp_window_set_transient() was making the dialog not
showing up at all, yet kinda blocking the bmp plug-in (waiting for a
response to the non-displayed dialog) and various features in the main
GIMP GUI too.
Calling gtk_widget_show() first, before setting transient was enough to
make the dialog finally work as it should, but this is really not ideal.
I compared to other cases in other plug-ins where the set_transient()
function was called before the dialog was shown and it is working fine.
I just cannot find the proper reason. So this will do for now.
They are now replaced by the more generic gimp_palette_[gs]et_colormap(),
hence making less of a particular concept of "image colormap". It's just
a palette attached to the image (and restricted to the image format).
It was an equality because I think the conversion from palette format to
"RGBA float" should go through the exact same babl code path, however it
is done in the API. And that is the case on my machine where I get
indeed perfect equality. But apparently not on the CI.
Though I guess investigating further would not be a bad idea, let's
consider this a minor issue (as a general rule, comparing float with
epsilon is still a recommended software usage), and just add a comment.
GBytes are a bit annoying to handle, so I'm renaming the PDB procedure
to a private _gimp_palette_get_bytes() instead, and making a wrapper
function which returns a C array and both the number of colors or number
of bytes. The latter is needed for introspection (otherwise the binding
can't know the size of the C array), but for the C API, both these
returned integers can be considered redundant (since one can be computed
from the oher), so only one at a time is mandatory.
When we want to set a full palette based on an existing one, no need to
request the full colormap from core to libgimp then back. Just set the
palette which is nothing more than an empty shell around a resource ID.
We have a bunch of special-casing format passing through the PDB, but
either we were only passing the encoding, or else we were reconstructing
the full format through private intermediate functions. In the
space-invasion world, this is not right. Let's have a proper "format"
type for PDB which does all the relevant data-passing for us, once and
for all!
Note that I am creating a wrapper boxed type GimpBablFormat whose only
goal is to have recognizable GValue since Babl types don't have GType-s.
Moreover I'm not using the GeglParamSpecFormat either, because it just
uses pointers which again are a bit annoying in our various PDB code.
Having a simple boxed arg is better.
gimp_brushes_popup() was triggering a popup allowing to change not only
the brush, but also the "paint mode", the opacity and the spacing. As
far as I could see, this was used nowhere for the paint mode and
opacity.
As for the spacing, it looks like gfig was indeed getting this data,
except that the GimpBrushSelect was disabling the effect on this scale
by setting change_brush_spacing to FALSE when calling
gimp_brush_factory_view_new(), and even setting this to TRUE, it was not
working fine anyway. Rather than debugging this, let's simplify the API.
Such settings seems like additional paint settings which don't have to
be in the brush selection. If someone wants people to also select an
opacity, spacing or paint mode, it would be much more efficient to add
separate plug-in arguments for these.
Additionally, I fix GimpBrushFactoryView not to show the spacing scale
when change_brush_spacing was set to FALSE anyway. This is just a bogus
widget then, which can only confuse people.
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.
After commit #a7bc5f07, these plug-ins assert in local_grad_data_refresh().
A comment is clearly stating that the widget must be allocated, so make
sure that the callback is only connected at allocation.
This abstract spec type is basically a GParamSpecObject with a default
value. It will be used by various object spec with default values, such
as GimpParamSpecColor, GimpParamSpecUnit and all GimpParamSpecResource
subtypes. Also it has a duplicate() class method so that every spec type
can implement the proper way to duplicate itself.
This fixes the fact that in gimp_config_param_spec_duplicate(), all
unknown object spec types (because they are implemented in libgimp,
which is invisible to libgimpconfig) are just copied as
GParamSpecObject, hence losing default values and other parameters.
As a second enhancement, it also makes it easier to detect the object
spec types for which we have default value support in
gimp_config_reset_properties().
As a side fix, gimp_param_spec_color() now just always duplicates the
passed default color, making it hence much easier to avoid bugs when
reusing a GeglColor.
- There is no reason whatsoever to make gimp_param_resource_value_set_default()
a no-op on core side. Also remove the whole commenting on this basic
function, especially as it's mostly wrong (why would core not use
default values? Why would we not transfer ownership? That's the whole
point of g_value_set_object() which increases the reference, hence
transfer ownership to the new reference…)
- Also removes the comment on GimpParamResource which is just explaining
basic GObject stuff and would only confuse contributors.
- Small indentation or coding-style fixes.
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.
As discussed in !1725, there is an init order issue, which is that you
cannot obtain any of these ID objects as long as the GimpProcedure is
not created. In particular, now that GimpResource arguments can have
defaults, we will want to query such resource in the create_procedure()
implementation of a plug-in (where the GimpProcedure is not running yet,
as we are defining it!).
Anyway I don't really see the point of these multiple-level hash tables
all storing a reference to the same object. Let's just store in the
GimpPlugIn's hash tables once and give the same reference to any
procedure (anyway we make it clear that these objects belong to libgimp
and must not be freed, so it's a bug all the same if someone frees
them). Then it also fixes the init order issue.
This handle is one of the opaque window handles as returned by
gimp_dialog_get_native_handle() or gimp_progress_get_window_handle() and
therefore it works even across processes. Now any export procedure using
the GimpExportProcedureDialog will call "plug-in-metadata-editor" as a
transient window of itself when clicking the "Metadata (edit)" button.
In particular, the Metadata editor won't be hidden by mistake when
appearing or similar issues.
Nevertheless it only works for systems where we have a transient window
implementation (so far, only X11 and Wayland, since the Windows
implementation is currently commented out because of #10229, and we have
no macOS implementation).
Note though that setting destroy-with-parent doesn't work, most likely
because the GimpExportProcedureDialog is still waiting for the Metadata
editor procedure to return (commit 54d01b5a0b), otherwise we end up with
a bad state in GIMP Protocol.
A proper solution to this will likely be to create a temp procedure from
metadata-editor to request it to close from another plug-in.
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.
