We could have tweaked further the code to guess what is a meta file
procedure or not (what we have done until now) but I decided to be more
explicit and added gimp_file_procedure_[gs]et_meta() functions to
libgimp to tag a specific import/export procedure to implement a meta
format.
gimp_file_procedure_set_extensions() would still be used to list well
known formats using this meta format, for instance "hgt.zip" or
"xcf.xz,xcfxz" but the meta extension (simply "zip" or "xz"
respectively) would be used as such. No more "guessing" using the list
of extensions and assuming that at least one of them would have a dot
within.
… and reset their undo stack.
This is a followup to #14463 as I realized that images opened directly
by a load procedure may still be dirty, first if the plug-in developers
didn't think of cleaning themselves the image at the end, but even as we
add some metadata which adds an undo step too. So even if the plug-in
developer made a perfect job, the image would still end up dirty if it
has metadata!
Let's just make so that GimpLoadProcedure clean the image explicitly.
Note that other types of plug-ins creating images won't have such code
as we cannot anticipate every case. In fact, in some use case, maybe
someone may want a plug-in to return a dirty image with undo steps! At
least for load procedures, we can consider these pretty standardized,
knowing we want them clean upon loading.
See commit 822c26f709. We decided to solve #14463 by having
gimp_file_load() always force-clean the image and reset the undo stack.
Therefore fix the docs again.
Commit 6874c47544 was not correct as we generate some type/values
description, extensively using Pango markup.
This additional fix does not change the logic from the aforementionned
commit, which is that the blurb still is just plain text (nor markup),
which we properly escape to display as-is, mixed with Pango markup.
I did wonder if it was supposed to be markup, and after a bit of test, I
could confirm that adding random markup in some other arguments, it does
sometimes styles the text, and other times, it just display the tags.
So I'm leaving an API warning to review this for GIMP 4.
This also fixes WARNINGs when a tag-like text is added:
https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/2469#note_2574483
The 'Plugin Browser' and 'Procedure Browser' use the same logic for
enforcing the minimum size of the details page and the list views. And
both are doing it by first setting the minimum: size of GtkTreeView and
then they climb up the widget tree to do the same. This is not ideal.
Setting the minimum size of GtkTreeView is not necessary because it is
inside of GtkScrolledWindow which makes this request moot. It also does
not enforce the minimum height of the widget for that reason. And if
GimpBrowser ever changes, both browsers will need to update their logic.
Moving the size enforcing a level up is logical and more robust.
Using an explicit value of width for the height of the dialog window
makes little sense. This makes the size of the dialog window clear.
And now the height of the list widget is set with its own macro instead
of piggybacking on the dialog window height.
We need 2 lines in the PDB for it to be an empty line in the C file,
which in turn will be interpreted as markdown-like lists for the
gi-docgen generated HTML docs.
- Consistently add the text about inserting items into the image after
creation, with correct function links/references.
- Consistent grammar for function blurb.
- Make @name argument nullable for gimp_path_new().
This patch moves the enums for GimpTextOutline
and GimpTextOutlineDirection so that they are
accessible to plug-ins/scripts. This will allow
for us to add PDB functions to get/set text outline
properties.
When the Exif metadata comment after our adjusting was NULL, we got a
critical:
CRITICAL **: 14:09:21.853: gboolean gexiv2_metadata_set_exif_tag_string
(GExiv2Metadata *, const gchar *, const gchar *, GError **):
assertion 'value != NULL' failed
Instead of trying to set the tag with a NULL value, remove the (now
empty) tag, if there was any.
See issue #15032
In gimp_image_metadata_interpret_comment (), it's
possible to set the variable comment to NULL.
We then have a later if statement that checks if index 0
of "comment" is \0 - if comment is NULL when this
check occurs, we cause a crash.
This patch adds a check to confirm comment is not NULL
before running this if statement.
Our build files were relying 'sysroot' to find gexiv2.h but this is
not possible with Apple Clang om which sysroot points to macOS SDK.
So, exotic environments like Homebrew were failing. Let's fix this.
As discussed with NikcDC, this will be useful, for instance for the SVG
export to know the mime type of the linked file. If not PNG, JPG or SVG,
we may want to output a small warning that some viewers may not be able
to read such files, since the SVG spec makes the support of these 3
formats only as mandatory.
This patch adds additional API for setting the stroke/fill
properties of vector layers. You can now set/get color, stroke
width and stroke style via the PDB. Pattern get/set API is not
yet implemented.
This patch also updates a missing parameter check for GimpVectorLayer
in gimp_config_param_spec_duplicate (), and adds additional API
in /app to make it easier to safely retrieve GimpVectorLayerOptions.
This macro will generate a #warning message when we'll move on to 3.99
series (which means we will be on our way to GIMP 4). And it will become
an #error message on 4.0.0, hence preventing us from releasing unless we
actually resolve all these warnings.
Resolution may mean actually breaking the API/ABI, or just deciding that
it's not a good idea in the end, or finding another solution. But
something will have to be decided.
Please everyone use this macro when you discover issues where it looks
like we could improve the API (in a breaking way) so that we don't
forget when approaching GIMP 4 (pushing further the improvement).
Updating the 2 place where I was already using a GIMP_CHECK_VERSION()
with #warning, and adding a new usage in the compose plug-in, per
discussion in MR !2424.
Previous implementation was always keeping ratio. If the width/height
argument were of a different aspect, librsvg simply fits the image with
original aspect within the box. Now we will appropriately scale
differently on both dimensions to have the image fill the whole box.
Note that this doesn't work with librsvg before 2.46.0 (not that it's
not possible, just that I haven't looked at how it should be implemented
there (which would be a different implementation anyway since there is
no cairo step).
Finally I add a build warning for when we'll prepare for GIMP 4, as the
pixel density arg needs to be split in 2 (each dimension can have its
own PPI), even though this is not really needed right now.
On export, when synchronizing the comment with the metadata equivalents,
we did not consider that the comment could have been changed in the
export dialog comment field. In fact, we already updated the metadata
before that happened in gimp_image_metadata_save_prepare.
To fix that
- We remove it from the above mentioned function, since that is too
early.
- Add the (possibly) updated comment to the exported_image as a
comment parasite so that we can access the updated value, but only
when synchronizing metadata is allowed, and saving comments is enabled.
- Synchronize the comment, taken from the parasite, with its metadata
counterparts in gimp_image_metadata_save_filter, but only when
synchronizing is allowed and saving comments is enabled.
Note that due to this the synchronized metadata comments are only
visible in the exported file. The metadata in the opened image is
not updated.
This patch adds PDB functions to get and set the PaintOptions
fade-length and fade-repeat properties. This settings can be
used together with gimp_context_set_emulate_brush_dynamics ()
to further control how the paint strokes are drawn in a script
or plug-in.
This patch improves vector layer UX based on feedback.
In summary:
* Makes vector layer editable from the Path tool
* Adds initial PDB for creating vector layers in scripts
* Size vector layers to the path size, rather than image
* Transform tools utilize the path for resizing
* Path tool automatically selects vector layer path
This reverts commit 246f9d284f.
This only reverts the part modifying libgimp* headers. All the part
switching to #pragma once in app/ was kept. See #14668.
at devel-docs
Due to me using an enum name that only ended in one word instead of
the other enums also adding `SAVE_`, the enum values in the gir
scanner were assigned a double name, causing API breakage and a
failure to build the documentation.
So, let's conform to the other enums and change the name of our
enum to `GIMP_METADATA_SAVE_UPDATE`.
Closes#5856 - provide a way to export images without adding or
changing any metadata.
Handles issue #3490 together with !2367. The latter makes sure that
an image comment when present is favored over similar metadata tags.
This commit makes sure that when you disable the preference to
update metadata automatically, it does not synchronize the
image comment with similar metadata tags (possibly overwriting other
metadata), it does not update the modification date, and does not
add or update software and change history metadata.
This adds a metadata preference (enabled by default) that on export
determines whether we add and update some non essential metadata.
When this setting is disabled, we only touch the metadata that we
cannot avoid (e.g. updating size, presence of thumbnail, etc.).
The charset=[ascii|InvalidCharsetId] comment originates from broken
handling in exiv2 of Exif.Photo.UserComment. However, due to the way
we (or possibly other programs) write comments, this could have
propagated to the generic image comment and to the
Exif.Image.ImageDescription metadata tag.
By adding a check for an existing comment first, the metadata tags
were not necessarily checked anymore.
To fix this in all cases we need to unconditionally read and interpret
the comment and both metadata tags.
We move handling of charset=InvalidCharsetId to the already existing
function gimp_image_metadata_interpret_comment by adding some
parameters and call this function for all three cases.
always loading comment from metadata
I noticed that if there was text in one of the metadata tags that we
consider equivalent to the image comment, the first one of those
always took precedence over an actual image comment that an image
may have.
Let's change that to only use metadata comments if the image didn't
have a comment set. So, if present, load the gimp-comment parasite
and set that as comment. If not present, we try to load a comment
from metadata.
Whatever a plug-in does, it should not be able to trigger WARNINGs or
CRITICALs on the core process. Here this was possible when requesting an
array of param specs with gimp_drawable_filter_operation_get_pspecs() on
a GEGL operation, while GIMP doesn't support all types for this filter's
arguments. Trying to send unsupported type specs through the wire would
fail.
Unfortunately just saying that we must add support for these types is
not enough because we simply cannot support every possible types. First
because even in current GEGL core filters, there are types we might
never support (e.g. audio fragments?). But even more because third-party
filters could have custom types too (just like our own filters have
custom GIMP types).
So instead, acknowledge that some types cannot be sent through the wire,
verify when it's one such argument and simply output an informational
message on stderr (because the info of a non-supported type is still
interesting in case this is something we should in fact add support for;
it's much better than silently ignoring the argument).
This will be used in particular for adding GimpTRCType to libgimp.
Otherwise it generates some broken gimp_TRCtype_get_type() function
name.
For this use case, we need to look-ahead a bit in the regular
expression.
...if Save Comment option is enabled.
Currently, it's possible to unknowingly export an image
without a comment, even if it exists, if the "Save Comment"
option is left unchecked. This patch adds a signal whenever
the "Save Comment" checkbox is clicked (and when the dialogue
is first opened) that uses its active status to set the sensitive
status of the comment text area. If unchecked, the text area will
be marked as insensitive so it can't be edited.
… depending on the number of choices.
Enforcing a UX decision into code from GIMP/Design/gimp-ux#323.
Note that this is not a perfect automatization, since the right default
widget may still be a combo box even for limited choices arguments, when
the dialog is crowded.
It still improves the defaults, and it is still possible to override the
widget on case by case (just as of now).
...to GimpProcedureDialog.
This patch allows plugin developers to create a
GimpCoordinates widget (two GimpSizeEntries linked
together with a chain and with a units combo) in the
GimpProcedureDialog.
It is largely a wrapper for gimp_prop_coordinates_new ().
This patch also makes that function more responsive
to the unit property, now that GimpUnit has a proper
GParamSpec implementation. The default unit and
whether we show pixels, percents, or the resolution
spinners can now be determined via the unit
parameter (if set) rather than relying on
hardcoded values.
As a demonstration, the Tile plug-in's width/height
entries were restored to what they were before the
GimpProcedureDialog port, with units and a chain
link between values.
gimp_procedure_add_uint_argument () creates an unsigned integer
parameter. It's functionally equivalent for creating dialogue widgets,
but since we only checked for G_TYPE_PARAM_INT, these parameters
did not generate widgets in GimpProcedureDialog.
This patch adds a check for G_TYPE_PARAM_UINT in relevant sections
to resolve the issue.
This is to make sure than regardless of how many fonts there are, font loading
won't delay startup.
FontConfig if compiled against libxml2 might fail to parse huge xml configs.
So instead of passing it a huge xml, pass the xml every MAX_NUM_FONTS_PER_CONFIG (currently 1000) fonts.
Also made GimpFontFactory custom config strings private because there is no reason for them to be public.
- No need of local_grad_data_new(). Just set default variables in init()
as it should be.
- Also move gimp_gradient_chooser_draw_interior() to the init()
function, so that the new() function is only a wrapper of
g_object_new() which is the proper way to implement new classes.
- Get rid of wrong comment.
This commit message has been rewritten by the reviewer (Jehan) because
the original message was not right. It was originally meant to fix#13189
but it was only doing so as a side effect of getting rid of the slice
API.
We still push it as a second step (with updated message) because it's
not a bad idea to stop using the slice API where we can as it's anyway
no more than a malloc/free synonym since GLib 2.76 and might get
deprecated some day.
Even though this is mostly the same thing now, it's only true since GLib
2.76, yet our AppImage uses GLib 2.74.6. This explains why the chooser
finalization was crashing plug-ins.
The GFig plug-in assumes that there is always
a valid brush selected when creating its
dialogue. However, a NULL brush is possible,
and GFig's assumption can cause a crash
in GIMP by attempting to get a buffer from
a NULL brush.
This patch adds conditional checks for the
brush to not be NULL before using it.
Reverts dc21fb76
The CodeView format introduces some advantages to our Windows build:
- It is way smaller than DWARF, reducing the .exe installer. With
the strip of COFF symbols too, the installation is 120MB smaller.
- Can be uploaded as .appxsym to be used on demand by MSIX (in thesis)
- Works better with DIA and DbgHelp debuggers like WinDbg and DrMingW,
respectively. LLDB also works by using LLDB_USE_NATIVE_PDB_READER=1
Context: that was not working before because DrMingw and LLDB seems to
only search for the build-time .pdb path in '.buildid' section of bins.
See: https://github.com/jrfonseca/drmingw/issues/91 and
https://github.com/llvm/llvm-project/issues/125355. So, we will set
_NT_SYMBOL_PATH at least for $PREFIX/bin for now as workaround.
for generated brushes.
The maximum radius we allowed for generated brushes was not used
consistently everywhere.
In the API call we clamped it to 0.0-32767.0, while the param_spec
set min and max to 0.1 and 4000.0, and the brush editor used a
maximum of 1000.0.
Using a large value (probably anything larger than 4000) would
sooner or later lead to a crash.
Instead of manual changes everywhere, let's define a maximum and
minimum in one place and use that wherever we need the min/max values.
Use the values as set in the param_spec for the defines.
The only place we can't easily do that is in brush.pdb, so we add
a comment above our defines that the values need updating there too.
Actually we should probably use more defines for other values too,
that way there is less chance of min/max values getting out of synch
throughout our code.
… gimp_procedure_is_internal().
I realized we were already naming these "internal procedures" in the
Procedure Browser and this is in fact a better naming than "core
procedure".
Note that I don't touch the GimpFileProcedure and children because they
are special-cased anyway. As for GimpBatchProcedure, ALWAYS is a good
default too.
After discussing with NikcDC and Wormnest on IRC, we agreed that maybe a
default of being sensitive when one or more drawables are selected seems
better, since the run() signature now has an array of drawables. So most
plug-in developers will consider the case when there are several
selected drawables as an obvious possible case.
And if someone really doesn't want to handle this case, they can always
set the sensitivity mask explicitly.
