We were already considering the plugins under /common but
not the plug-ins that have their own subdirectories. So,
plugin_executables did not match custom_plugin_targets and
the build started to fail on macOS where install_name_tool
neeeds to process the plugins setting the right LC_RPATH.
This commit changes the metadata viewer to use `GtkListBox`es instead of
`GtkTreeView`s for displaying the tags and their values. The main
advantages is that the latter isn't available in GTK4 (making the
eventual port to it smaller), that they have a11y problems, and that
list boxes allow more advanced UIs than just showing a simple string.
One thing for example that this commit introduces, is to make the labels
selectable, so they can be easily copy-pasted for lookup.
Since we wanted to use `GListModel`, this commit also introduces a
helper object `GimpMetadataTagObject` which holds both a tag's name and
its value. In the future, we could use this to move the string
formatting logic to that helper object, which we could then in turn use
for more advanced UIs.
Use the opportunity also to rename the plug-in to a more
self-explanatory `GimpMetadataViewer` (rather than a `Metadata` struct
which can be easily confused with `GimpMetadata`).
A lot of the custom brand makernote tags have interpreted strings
available, even though their type is set to Byte.
Since having those interpreted doesn't have any negative side effects
(real Byte values are correctly converted) let's not exclude these
tags for interpreted string conversion.
This is a followup of previous commit. We must set the win_subsystem
option on executable() so that the result binary is compiled as a GUI
application (and doesn't output a console every time).
The previous commit is still needed and is what allows us to control
when to actually display a console.
The IPTC TimeCreated tag does not allow fractions of a second, while
Xmp.Photoshop.DateCreated (which includes the time) does allow this.
In our metadata editor we base our date/time on the last value and then
synchronize it with the IPTC date and time values.
While doing that, we did not check if the seconds had a fractional part.
To fix this we first check for the presence of a fraction by checking
for a dot in the time string.
Complicating factor is that a timezone difference may follow that,
which we want to keep if present. So we check for that too and
concatenate the parts we want.
On Linux the string for GPS coordinates was broken when the
string it was strtok:d from was freed. Move the free until we
have finished using the resulting string.
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.
These were using gimp_procedure_new, which was causing warnings like
LibGimpConfig-WARNING **: 13:56:33.270: couldn't serialize property
GimpProcedureConfig-plug-in-metadata-editor::image of type GimpImage,
and
gimp_plug_in_destroy_proxies: ERROR: GimpImage proxy with ID 1 was
refed by plug-in, it MUST NOT do that!
This also saves us from having to define image and run-mode parameters
ourselves.
If we leave a space between the macro name and opening parenthese for argument
lists, the args are not considered macro args (which will be discovered when
using it). I experienced this issue while testing code on some plug-in
yesterday, so thought I might as well fix all these broken macros for casting to
the specific GimpPlugIn subclass, so that we won't have a next time.
Exif tags Exif.Image.Artist, Exif.Image.ImageDescription, and
Exif.Image.Copyright were not being synchronized with their Xmp and
Iptc.IIM equivalents in the metadata-editor.
This commit adds synchronization of reading and writing of the metadata.
We adjust the struct for equivalent_metadata_tags by removing unused
fields and adding a field that points to the equivalent Exif tag in
a new struct called exif_tag_info.
On loading of the metadata tags we now also check a limited set of
Exif tags. If no value was set yet, we use the Exif value, or else
we check to make sure both had the same value. If not, print a
warning in the terminal.
On saving of metadata, we now also save to the marked Exif tags, or
if the value is NULL, we remove the tag.
In passing, we also fix two memory leaks by freeing with g_strfreev
temporary string lists.
Dates in Xmp include a time and timezone, so add a default time when
selecting a date since we can't edit time and timezone yet.
So far, we didn't take into account that IPTC-IIM has separate date
and time+timezone values instead of the combined value in XMP for
DateCreated.
When loading DateCreated check if it has the same value as IPTC
values DateCreated and TimeCreated combined. If not, we show a
terminal error and ignore the IPTC values.
If neither Xmp nor Iptc has a DateCreated, then use Exif.Photo.
DateTimeOriginal combined with OffsetTimeOriginal to set an initial
value.
When saving, synchronize with IPTC-IIM by splitting the DateCreated
value in date and time+timezone and save each to the appropriate tag.
Also make sure that for IPTC-IIM the date separator is a '-'.
Adds a bottom margin to the grids because the horizontal scrollbar
was overlapping the bottom-most row of the grid.
Adds wordwrap and left/right margins to multiline text widgets,
mainly to make the text not start right at the edge of the widget.
We were using a string for the metadata mode, meaning we had to compare
string values in a lot of places.
We simplify and probably speed-up comparisons here by replacing the
mode string by an enum value.
The only place still needing the string values sometimes is
metadata-impexp.[ch] where we added a conversion table to convert
the mode to a string.
- Missed a necessary autotools change: forgot to remove ui/Makefile
from configure.ac
- Not all compilers allow declaring variables in a case statement without
putting them in a block, so we add a block now.
Instead of loading the GtkBuilder .ui file we now create all widgets in
code.
Added several support functions to reduce code copy/pasting and making
additional widgets and supporting more metadata easier.
The overall layout should still look the same, with a few exceptions:
- Each notebook page only uses one grid. This makes it possible to align
all data entry widgets.
- Featured Organization and it's code were two treeviews next to each
other. These are now organized below each other to make automatic code
generation easier.
- Since we needed to touch this code anyway, I also fixed Xmp.dc.creator
and Xmp.iptcExt.ModelAge to be multiline. This closes#7286.
- The old icons used for the date button, add, and remove row buttons
were replaced by gimp-grid, list-add and list-remove.
Since this was the last .ui file used in GIMP plug-ins, we remove all
files from the .ui subdirectory and references to that.
Note that there are several more places where GtkBuilder is used, but
those cases uses strings defined in code instead of .ui files.
We had a lot of duplicate code using gexiv2_metadata_try_set_tag_string
and then checking for errors.
Simplify this by re-using the existing set_tag_string function by
introducing an extra parameter that tells us whether or not to clear
the tag first.
In the master branch we depend on gexiv2 0.14, so we can remove the
deprecated functions and replace them with the "try_" versions.
We can't backport this, since our stable branch has a lower dependency
for gexiv2.
The metadata-viewer uses a GtkBuilder .ui file to create the interface.
In GIMP we prefer our interfaces to be created in code and these builder
files are also not available anymore in GTK4.
This commit removes the .ui file and support code, and creates the
interface from code in our plug-in.
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.