Now that we bumped our meson requirement, meson is complaining about
several features now deprecated even in the minimum required meson
version:
s/meson.source_root/meson.project_source_root/ to fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.source_root. use meson.project_source_root() or meson.global_source_root() instead.
s/meson.build_root/meson.project_build_root/ to fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.build_root. use meson.project_build_root() or meson.global_build_root() instead.
Fixing using path() on xdg_email and python ExternalProgram variables:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.55.0': ExternalProgram.path. use ExternalProgram.full_path() instead
s/get_pkgconfig_variable *(\([^)]*\))/get_variable(pkgconfig: \1)/ to
fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': dependency.get_pkgconfig_variable. use dependency.get_variable(pkgconfig : ...) instead
This is the consequence of previous commit. Plug-ins' label and
documentation are now localized before sending these data to GIMP core.
In other words, we replace N_() macros with basic gettext calls.
Hence avoiding the stderr messages. These are going to be localized with
centrally installed catalogs "gimp*-std-plugins", "gimp*-script-fu" and
"gimp*-python".
We now handle core plug-in localizations differently and in particular,
with kind of a reverse logic:
- We don't consider "gimp*-std-plugins" to be the default catalog
anymore. It made sense in the old world where we would consider the
core plug-ins to be the most important and numerous ones. But we want
to push a world where people are even more encouraged to develop their
own plug-ins. These won't use the standard catalog anymore (because
there are nearly no reasons that the strings are the same, it's only a
confusing logic). So let's explicitly set the standard catalogs with
DEFINE_STD_SET_I18N macro (which maps to a different catalog for
script-fu plug-ins).
- Doing something similar for Python plug-ins which have again their own
catalog.
- Getting rid of the INIT_I18N macro since now all the locale domain
binding is done automatically by libgimp when using the set_i18n()
method infrastructure.
We were using parameter iter in metadata_dialog_add_tag and
metadata_dialog_add_translated_tag.
However, iter is only ever set inside metadata_dialog_add_tag by calling
gtk_list_store_append. So, there is no need to pass this parameter around.
For this reason, let's remove parameter iter from the above two functions
and replace with a local variable.
Since we increased our minimum version of gexiv2 to 0.12.3, several
functions used in the metadata-viewer plug-in have been deprecated.
Replace these functions with the "try_" versions, which include an
error parameter. If this returns non NULL then we print the error
message to the console.
Detected issues fixed here:
- Use GString and g_string_append since otherwise we need to add g_free
after every g_strconcat.
- No error checking.
- We need to g_free value_utf.
Not detected by coverity:
- Wrong quotes around utf-8.
- Remove unused includes.
Several resource leaks here were detected by coverity:
- Not freeing value_utf.
- Strings returned by g_strconcat should be g_free'd. To handle the string
concatenations easier we use GString and g_string_append instead.
Also introduce function get_list_elements to reduce the number of
repetetive elements.
While we were at it, also remove unused includes.
When writing metadata in the metadata-editor it did not check for empty
values. In combination with gexiv2 0.14.0 (which doesn't check in this
specific case for an empty list of gchar **) and trying to set a non
repeatable Iptc tag (Iptc.Application2.Headline) using
gexiv2_metadata_set_tag_multiple we get a crash.
This fix checks first for a non empty value before trying to save the
metadata tag.
Since the code is very similar also implemented this check for the Xmp
tags in addition to the Iptc and simplified some duplicate code.
See issue #7408 where this is causing a crash when using gexiv 0.14.0
in combination with trying to save it as a multiple tag with an empty list.
According to https://exiv2.org/iptc.html the tag Iptc.Application2.Headline
is not repeatable so we will set mode to "single.
In addition to that I added comments to explain the differences in the
meaning of "single" and "multi" between the list of Xmp tags and Iptc tags.
This is untested on my side, because the bug only happens on native
builds with meson (our CI has cross-builds with meson and native builds
with autotools and I only do cross-builds locally) but I think/hope it
will work.
Basically we were using .full_path() because these rc files were also
used as input of some configure_file() calls which doesn't like custom
target objects as input (it wants strings or file objects). Yet a bug
in meson didn't like the colon used in native Windows full paths ('C:'
and such) when used in windows.compile_resources(). This has been fixed
by Luca Bacci in: https://github.com/mesonbuild/meson/pull/9368
Yet we just cannot depend on very early meson (or worse dev meson code).
On the other hand, if the input is a custom_tgt object, it uses the
object ID which we give as first parameter of custom_target() so we know
it's appropriately named without colons (such as 'gimp_plugins_rc').
Thus we should not bump into this issue again.
For the few usage in configure_file(), I just add a .full_path() only
when needed at call time.
Last but not least, I replace the bogus `meson --version` call by a
`python3 -c 'exit()'` as advised by Eli Schwartz:
2afa019c70 (note_1284951)
The reason is that it is apparently possible (or will be when some
reimplementation of meson will be done) that the `meson` executable
itself does not exist. On the other hand, `python3` should always be
there, as a mandatory dependency of the build tool.
In order to use an appropriate `python3`, I made the
pythonmod.find_installation() check required in our build (which should
not be a problem since it's a meson requirement as well), even when the
-Dpython option is false (this one depends on other requirements too
anyway, such as version and pygobject). This way I can call this meson
variable of discovered python in my bogus call, instead of calling a
(potentially different) python from PATH environment.
XMP array tags of type BAG and SEQ can have multiple values, each of
which is on a separate line. However, we were reading and saving it as
just one value.
We change this by setting each line as a separate value with
gexiv2_metadata_set_tag_multiple.
In addition to that we found that setting the type of tag struct with
gexiv2_metadata_set_xmp_tag_struct caused arrays of multiple values per
tag to be set incorrectly: the last value in the list got added multiple
times. I'm not sure if we are using this function incorrectly, or that
there is a bug in gexiv2 or exiv2. Anyway, since it seems that all tags
and values I tested work without calling this function, let's just omit
this call.
XMP array tags of type BAG and SEQ can have multiple values, each of these
values needs to be on a separate line to be correctly recognized as a
different value in the tag array. We were incorrectly loading all values
on one line separated by a comma.
For those tags that have equivalent IPTC tags we were also comparing just
the one XMP value with the whole, possibly multiple lines, of the same
IPTC, which could cause a failure to recognize identical tags.
We changed this to now have each value in a tag array on a separate line
by adding \n between values.
Each IPTC equivalent tag value is now compared to each value in the XMP
tag array and only added when a different value is found.
XMP tags that have multiple values (usually of type XMpBag or XmpSeq) were
shown on one line. Which, especially for long text values, could make it
difficult to see the separate values for that tag.
Let's do the same as we do for IPTC tags that can occur multiple times and
show each value on a separate line.
In the metadata-viewer refactor the code that adds multiple values per tag
to the list store into a separate function.
Currently used for IPTC tags only but the intention is to reuse it for
XMP tags with multiple values.
Let's increase the default size of the metadata viewer a bit.
Ideally we would add some logic to determine the width of
the first column since that one currently depends on the
length of the longest tag. However for now this change
will be enough for most cases.
The saved value for Iptc.Application2.Caption is copied from Xmp.dc.description.
However the last one is multiline but the former should be single line. This
caused only the first line to be saved instead of all lines.
To fix this we set Iptc.Application2.Caption to single and use a different
conversion based on whether the tags from Xmp and Iptc are both
multiline or whether Iptc is single line.
While testing the metadata-editor I noticed that certain values for
ModelReleaseStatus and PropertyReleaseStatus were incorrectly
read back.
Apparently while copy pasting some values were forgotten to be
updated which caused incorrect values to be saved.
There probably are not many users of these metadata tags
since in all these years there hasn't been a bug report about this.
The metadata-editor allowed Iptc tags to be set if an empty string was
used contrary to Xmp tags. In the case of DateCreated this cause an
invalid date "0-00-00" to be written.
We added a check to only write text Iptc metadata if the value is
not empty.
Fixes issue #3656 Empty metadata tags are written to XCF at least.
Xmp.plus.ModelReleaseStatus and Xmp.iptcExt.DigitalSourceType are
defined as combo boxes with a fixed number of possible values.
However there was no option to leave it empty so there always was
a value written when saving metadata in the metadata-editor.
We added a "select value" as default option and only write
metadata if a different value was chosen.
As a bonus we replaced the fixed loop numbers with
the current actual number of defined choices.
We need to work around an issue in Exiv2 that saving to /Iptc4xmpExt bag
records fails which seems related to it registering /iptcExt. Unregistering
that and registering the first one doesn't work.
See: https://gitlab.gnome.org/GNOME/gexiv2/-/issues/24
So let's use /iptcExt for saving even though it's the less common form
for now. When loading metadata we try to load the most common
form first and if that fails we will load /iptcExt.
Set Xmp.iptc.CreatorContactInfo/Iptc4xmpCore:* last since the short
form Xmp.iptc.Ci* could have been used to set this information too.
Becausethe first (longer) form is the most common let that override the
shorter form in the (unlikely) case that both are present and also have
different values.
Due to a bug in the metadata-editor previously only the short form
was saved.
Reordered the strings in artworkorobject to be in the same
order as the columns.
Add write_metadata_tag_multiple function that handles most
of the previously duplicated code and check for special
handling of phonetype when necessary by adding
an enum and a get_phonetype function.
Use a separate function that can be reused and also get rid of
the large output_data array and strcat without length
checking. We will use GString instead.
There was a lot of duplicate code based on
whether or not value was NULL with for
some tags partially unreachable code.
We combine the parts and only test
value for NULL where needed.
Also rename the typos in enum
COL_REGSITRY_* to
COL_REGISTRY_*
There's a lot of duplicate code for adding string values
to the gui (liststore). This is another part of trying
to reduce that.
Besides that the copying code uses fixed size arrays
without length checking as pointed out by flawfinder.
We will instead use a function add_to_store to add a
comma or semicolon separated list of values stored in
value to add rows with values to the gui.
By using a logging domain we can filter the messages and can choose to
only see them when needed. They seem to be leftovers from coding or
debugging but I don't wanna invest too much time into this.
metadata-editor and metadata-viewer did return GIMP_PDB_SUCCESS when
loading the dialog ui failed, we changed this to GIMP_PDB_EXECUTION_ERROR
and now use a GError to report it back to GIMP.
In metadata-editor also improve the error handling when loading the calendar
dialog fails.
The error also only showed in the console so change that to show a dialog
or the error console.
The string parsing for gps longitude/latitude was not taking all
possible values into account and also the seconds part was
not saved with enough detail.
For altitude lets also increase the detail a bit from .1m to
.10m.
By using g_log with G_LOG_LEVEL_MESSAGE and empty domain
name we make sure the failure to write a tag will be seen by
the user in GIMP's user interface (error console or error
dialog).
Adding metadata-tags to meson.build and Makefile.am for
the metadata-viewer since until now it was only used in
the metadata-editor.
The Exif gps metadata tags for longitude, latitude and
altitude get special handling to show them with more
precision and let the string parts be translated.
The abbreviations M for meter and FT for foot/feet were written in uppercase.
However the offical abbreviations are lowercase so let's just follow that and
make them lowercase here too.
Above and Below Sea Level were using camel case with every word starting
with an uppercase letter and were used on the label of a combobox option
for gps altitude reference. Using standard casing with only the first word
using a capital seems better in this case.
a capital
Saving of longitude and latitude was duplicating the same code,
except that in latitude it forgot to free some strings.
Let's move this code into it's own function to make it easier to
improve it.
The values of Description tab - Copyright Status and IPTC tab - Urgency were not saved.
We are fixing that with this commit. Urgency is also saved to Iptc.Application2.Urgency.
Iptc equivalent tags of Xmp tags were only read if the Xmp tag had no value
which doesn't make sense since there is no guarantee that they are the same.
We changed this to always read the Iptc tags too and if the value differs
from the Xmp tag we add both values. That way the user can decide
which values are relevant.
This is one of the problems mentioned in issue #5863. This commit fixes
this problem in the metadata-editor by using gexiv2_metadata_get_tag_multiple.
Empty string values will be skipped.
