A crash could happen when a duplicate nick was found due to incorrectly
freeing the content of 'choice->keys' which holds the nicks and not
GimpChoiceDesc. Instead, the nick needs to be simply freed.
Adds a GimpCurve object and functions in libgimp.
Rather than creating a GimpCurve object in core and
passing it back and forth, we just pass the attributes
and reconstruct it across.
In the future, we may combine this with the app/core one
and put it in libgimpbase.
See: #15547
This needs approval from Cannonical and allows migrating app data from
older versions as well writting current app data outside the sandbox.
Commit e735054347 clearly shows that gimp_range_estimate_settings() can
be improved, but it would not be possible unless we added some argument
to know if the increments are meant for an integer widget.
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.
This really feels like internal API which we'd want to keep private (and
used by core plug-ins only).
Also as Jacob noticed, it's not even included in libgimpbase/gimpbase.h
so plug-ins wishing to use this API need to include this file
specifically anyway (but the header is still installed and the API is
introspected).
Since we cannot remove these functions now that GIMP 3 was published,
for API stability, I am only deprecating them both in the C API with
macros and in the bindings with GObject Introspection annotations.
Therefore any third-party plug-in developer trying to use these
functions in a plug-in will get build-time or run-time warnings.
Then when we'll move on to GIMP 4 development, we can remove the
deprecation and simply make this file private-only use instead.
This patch fixes a few (mostly Windows-specific) warnings on build.
* Hides functions like gimp_get_foreign_window () and variables
like transient_set that aren't used in Windows.
* Changes hollow_g_shell_quote () to not return a const gchar *,
since the value it returns is actually not const.
* Cast update_interval to double to remove warning about mixing
enums and doubles in division.
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.
This commit changes the following:
- It's now possible to set whether to store an absolute or relative path
when editing link layer properties.
- New layer dialog doesn't propose an "Image link" fill type anymore.
Link layers won't be created this way (see in a future commit).
These are layers who content depends on another source (right now only
an external image). This can be useful when for instance working at
several people on a single artwork, hence being able to load new
versions of an image without even touching anything in the XCF (for
instance, say you draw an animated character while someone else is
taking care of the background).
Similarly to what we do for text layers, once you start modifying the
contents, it turns into a "normal" layer. The link information is still
available though, so it is possible to revert to the monitoring state
with the menu item "Monitor Linked Image" which appear when a link layer
became a normal layer.
This is not finale as I'm still experimenting. In particular, I have not
implemented XCF saving/loading yet for this new layer type.
In 6b10cce6 I introduced setting created date/time metadata for new
images. However, I made a mistake there by using : instead of - between
year, month and day for the XMP metadata tags.
This commit fixes that.
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.
This reverts commit 06cd254954.
GObject Introspection tools somehow fail to introspect some macros in a
very bizarre way. See issue #14668.
I thought #pragma once was somewhat standard, but it turns out it's not.
And Wikipedia even stays about this:
> While #pragma once is available in most modern compilers, its
> implementation is tricky and might not always be reliable.
Anyway clearly it's not reliable at least regarding GIR tools. I believe
we should hold up on using #pragma once at the very least within our
libgimp* libraries. It is probably fine for app/ or plug-ins/ where we
don't need to introspect anything (and so far we haven't had any
compilation mishap because of this preprocessing directive).
The name GIMP_METADATA_SAVE_UPDATE does feel a bit ugly but we need to
keep the GIMP_METADATA_SAVE_ prefix, otherwise we would break the GIR
bindings. cf. commit 27fead082a.
Make a warning for ourselves to happen when we are closing onto GIMP 4.
Then we can make a decision whether or not we want to rename this enum
value.
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.).
This a bandaid for an issue on MacOS:
an IO event is received that says a read pipe from a plugin has data,
but the pipe is actually empty and reads hang, and hang the app.
Possibly this is an issue with GLib and could be fixed there,
to not send such a spurious IO event.
Possibly an alternative fix is to determine whether the app side of the
plugin protocol is in a state where no messages from the plugin
are expected. In that case, the read pipe should be flushed
i.e. data discarded, with non-blocking reads, until a read returns nothing.
New libgimpbase functions:
- gimp_param_spec_choice_get_choice
- gimp_param_spec_choice_get_default
Now the only GParamSpec in libgimpbase whose struct is visible is
GimpParamSpecObject. This can't change since it is derived into param
specs defined in libgimp and therefore needs to be visible.
As a consequence, here are needed new functions:
* libgimp:
- gimp_param_spec_resource_defaults_to_context()
- gimp_param_spec_resource_none_allowed()
* libgimpbase:
- gimp_param_spec_file_get_action()
- gimp_param_spec_file_none_allowed()
- gimp_param_spec_unit_percent_allowed()
- gimp_param_spec_unit_pixel_allowed()
… GimpParamSpecUnit's default value.
When I reparented GimpParamSpecUnit to GimpParamSpecObject in commit
ba3da3d338, I clearly forgot to get rid of the redundant default value.
Without a proper way to compare GFile, gimp_config_reset_properties()
does not reset the config argument to default. This breaks the "Reset to
Factory Defaults" feature in particular.
Now that GimpParamSpecFile makes file validation depending on the action
set in the param spec, when trying to open a non-existing file (which
can happen through GUI, for instance when opening through the Document
History dockable or Open Recent menu), we had a quite obscure error
about a value "out of range" used "for argument 'file' (#2, type
GFile)", which is because core tried to set the GFile for a non-existing
file into the second parameter of the plug-in PDB. This is not a very
nice error for end-users.
The old error was much nicer as it used to say things like:
> Could not open '/path/not/existing.png' for reading: No such file or directory
But in fact, this string came from the plug-in, which means:
* first that the error can be different depending on the format
(inconsistency of error message);
* depending on bugs in plug-ins, it may just crash or return no error
messages;
* finally we were making a useless call to a load plug-in while we
should already know from core that it won't work.
The new message is something like:
> Error when getting information for file "/path/not/existing.png: No such file or directory
This error is generated by core, so it will always be consistently the
same, is understandable too and the plug-in won't even be called.
As a side related fix, I updated the GimpParamSpecFile validation to
only validate local files, just like we do in core. Remote files can
always be set (and we let plug-ins handle them), at least for the time
being.
I forgot to set meta.m_file.action into the GPParamDef! 🤦
As a side update, let's store the action as gint32 in GPParamDefFile. I
realized that otherwise, depending on the actual size of an enum type,
when casting to a (guint32 *), we crop the value! This works out in
Little Endian because we are only in small number territory, but in Big
Endian, we would always crop any action value to 0!
This was not the bug in this specific case, but it could become the
exact same bug (always passing action 0, i.e. OPEN, through the wire) on
Big Endian hardware.
libgimpbase:
- Mew GimpFileChooserAction enum type: basically a near-mapping of
GtkFileChooserAction (GTK is not accessible from libgimpbase) with
an added GIMP_FILE_CHOOSER_ACTION_ANY.
- New GimpParamSpecFile param spec type: based off
GimpParamSpecObject, it has a default value, but also a none_ok and
action argument. This way, we can also know from the argument type
if this is a file argument meant for selecting a normal file or a
folder, or for saving into a file, or for creating a directory.
libgimp, plug-ins:
- All existing file arguments (until now using a standard
GParamSpecObject param with GFile value type) were moved to the new
GimpParamSpecFile.
- Script-Fu in particular will now generate the appropriate param type
depending on whether it is an SF-FILENAME or SF-DIRNAME.
- File arguments are now stored between runs as a URI rather than as a
path. As far as I can tell, a GFile always has a URI, but not always
a path (in particular remote file won't have a path).
when creating a new image.
We add a new function `gimp_metadata_set_creation_date` to
`libgimpbase/gimpmetadata` to handle setting all relevant
metadata tags.
We add a local function `gimp_image_new_add_creation_metadata` to
add the creation date metadata to relevant functions that create
new images.
We write tags for both the creation date and several modified dates
for IPTC, XMP and Exif metadata. All these use different ways to
express date/time and timezones and I can already see we need to have
another look at other places where we handle modified dates.
This solves the second part of #7287, adding metadata about the
date/time a new image was created.
This reverts commit 9b94e347bc.
I leave a comment though, because we are not 100% sure that the issue is
gone. In fact, the upstream report is still opened.
The good point is that on stable code, we only debug crashes by default,
while the specific hang we had was happening with debugging metadata
warnings. So hopefully we won't have random people reporting GIMP
hanging (only people explicitly trying to help debugging GIMP).
It is now possible to sync the GimpDrawableFilterConfig with core.
Another (simpler on usage) possibility could have been to sync
automatically when a property is updated. But considering that some
filters can be quite slow to render (especially in real-life usage when
working on possibly very big files), and especially that on bindings
with no variable args, scripts will likely have to edit properties one
by one, it could make editing multiple properties very slow. Therefore
the chosen solution is that editing properties stay local on libgimp and
all changed properties are synced with core at once (with a frozen
render until the end for single computation) when calling
gimp_drawable_filter_update().
It was possible to set a GimpChoice property to a value out of the
allowed list. This got very likely broken when I re-parented
GimpParamSpecChoice to GParamSpecString which had a value_is_valid()
implementation, which was shadowing our custom value_validate().
This is fixed by now also implementing value_is_valid() for this param
spec type.
Closes#12518
Certain Sony camera's have MakerNote tags in the Exif.SonyMisc3c range.
When exporting with EXIF metadata included this causes a failure saving
the metadata, which means that no metadata at all is saved to the image.
For now, let's exclude these tags, so that all other metadata tags at
least will be saved.
We will keep an eye on exiv2 issue
https://github.com/Exiv2/exiv2/issues/2670
to see if the actual cause will be solved.
in gimp:offset filter.
Since gimp:offset is now an NDE filter,
always loading the background color from
context causes the color to change each
time the filter is redrawn. This is inconsistent
behavior.
This patch replaces the GimpContext
parameter with GeglColor, and updates
gimp_drawable_offset and related functions
to set the color directly. The libgimp version
loads the background color from context
and passes it on since the API is now
frozen.
