… moved to the implementation file.
When declaring with G_DECLARE_FINAL_TYPE(), the whole concept is that the struct
is made private (which also allows the type to evolve without breaking ABI if we
some day decide to make the class derivable). For this to make sense, the struct
goes in the implementation file, not the header.
For the rest, it's mostly alignment bugs and the like.
Fixes:
> libgimp/gimpresourceselectbutton.c:510:9: error: a label can only be part of a statement and a declaration is not a statement
> 510 | GimpResource *specific_value;
As well as some coding style bug (space after '*').
This fixes the VAPI build. I am actually astonished the lib build seem to have
passed and that we didn't get double definition clashes.
The build error was:
[750/2424] Generating libgimp/gimp-ui-3.0.vapi with a custom command
FAILED: libgimp/gimp-ui-3.0.vapi
/usr/bin/vapigen --quiet --library=gimp-ui-3.0 --directory=/builds/GNOME/gimp/_build/libgimp --pkg=babl-0.1 --pkg=cairo-1.0 --pkg=gdk-pixbuf-2.0 --pkg=gegl-0.4 --pkg=gio-2.0 --pkg=glib-2.0 --pkg=gobject-2.0 --pkg=gtk+-3.0 --vapidir=/builds/GNOME/gimp/_build/libgimp --girdir=/builds/GNOME/gimp/_build/libgimp --pkg=gimp-3.0 --metadatadir=/builds/GNOME/gimp/libgimp /builds/GNOME/gimp/_build/libgimp/GimpUi-3.0.gir
GimpUi-3.0.gir:22111.7-22111.33: warning: Virtual method `GimpUi.ResourceSelectButton.draw_interior' conflicts with method of the same name
GimpUi-3.0.gir:26688.73-26688.73: error: The type name `ResourceSelectButtonClass' could not be found
GimpUi-3.0.gir:26695.73-26695.73: error: The type name `ResourceSelectButtonClass' could not be found
GimpUi-3.0.gir:26704.73-26704.73: error: The type name `ResourceSelectButtonClass' could not be found
GimpUi-3.0.gir:26712.73-26712.73: error: The type name `ResourceSelectButtonClass' could not be found
GimpUi-3.0.gir:26720.73-26720.73: error: The type name `ResourceSelectButtonClass' could not be found
Simplifies chooser widgets (e.g. GimpBrushSelect) by eliminating attributes (e.g. opacity) of chosen resource.
See #8745, but this commit fixes that by first refactoring the code.
Refactors GUI widgets (e.g. GimpBrushSelectButton and GimpBrushSelect etc.)
Refactor by "Extract class" GimpResourceSelectButton from GimpBrushSelectButton etc.
This moves common code into an inherited class (formerly called GimpSelectButton)
but the subclasses still exist.
The subclasses mainly just do drawing now.
Refactor by "Extract module" GimpResourceSelect from GimpBrushSelect etc.
Moves common code into one file, generic at runtime on type of GimpResource,
that is, the new code dispatches on type i.e. switch statements.
In the future, when core is changed some of that can be deleted.
The files gimpbrushselect.[c,h] etc. are deleted.
The module adapts the API from core to the API of callbacks to libgimp.
Note that core is running the resource chooser (select) widgets remotely.
Core is still calling back over the wire via PDB with more attributes
than necessary.
The new design gets the attributes from the resource themselves,
instead of receiving them from core callback.
The libgimp side adapts by discarding unneeded attributes.
In the future, core (running choosers for plugins) can be simplified also.
Fix gimp_prop_chooser_brush_new same as other resources.
Finish changes, and clean style.
Annotations
So procedures can declare args and GimpProcedureDialog show chooser
widgets
Fix so is no error dialog on id_is_valid for resources
Palette.pdb changes and testing
Memory mgt changes
Gradient pdb
Font and Pattern tests
Test brush, palette
Cleanup, remove generator
Rebase, edit docs, install test-dialog.py
Whitespace, and fix failed distcheck
Fix some clang-format, fix fail distcheck
Fix distcheck
Cleanup from review Jehan
Only libgimpui depends on GTK+, display servers and other GUI-related
dependencies. There was a problematic include added in commit 0b56aa0d13 for
macOS, but the needed code (testing the macro GDK_WINDOWING_QUARTZ to use some
[NSApp activateIgnoringOtherApps:YES] API) doesn't seem to be present anymore in
there, so I think that removing this include (replace by including GLib for
other calls) should work fine. Of course, we'll know it when the separate CI
will test a macOS build as we still don't have in-Gitlab macOS jobs. :-/
This was the last remaining bit in #8124. Basically I needed to check how
localization of menu paths worked. I was thinking of maybe have 2 arguments to
gimp_procedure_add_menu_path(), one non-localized (for default menu paths) and
one localized by the plug-in (for custom menus). That would break all plug-ins,
but also looking at our code, it's complicated to do right.
Instead let's just keep current API and add an example in function docs. We'll
see how we can improve the API if the very hypothetical problem I am foreseeing
actually happens some day: say a word in English translates to e.g. "Filters" in
some other language, whereas English "Filters" translates to yet another term;
in such case, this new menu would still merge with the default /Filters/ menu
when localized in this language, so we'd have the weird situation where the
custom menu label would have passed through 2 translations somehow.
But let's see how it goes. If we really need, in the future, we can deprecate
gimp_procedure_add_menu_path() and add a gimp_procedure_add_menu_paths() with a
base_path and a custom_path, while the custom_path would be expected to be
already translated.
Missing functions were:
* gimp_image_get_selected_channels()
* gimp_image_get_selected_vectors()
* gimp_image_list_selected_channels()
* gimp_image_list_selected_vectors()
* gimp_image_set_selected_channels()
* gimp_image_set_selected_vectors()
* gimp_image_take_selected_channels()
* gimp_image_take_selected_vectors()
There are discussions of renaming GimpVectors to GimpPath, which would
also be consistent with the GUI and make the always-plural less akward
in API. We'll see. For now keeping named like this.
Now text layers are proper types, which means that the binding API will also be
nicer (e.g. `txt_layer.set_text('hello world')` in Python).
This commit also adds the param specs allowing to create plug-in procedures with
text layer parameters.
Finally it fixes the few calls in file-pdf-save (apparently the only plug-in
using specific text layer API right now) with explicit type conversion.
After re-reading #534, I realized I missed the discussion about unsupported
markup by the tool. Then I tested and confirmed what Ian Munsie initially said
in a comment: unsupported markups are properly rendered in the text layer, yet
are simply dropped when editing with the text tool.
This is actually the ideal behavior as it means that with the API, you can even
go further than what is currently possible with the GUI. So it gives nice powers
to people who can script GIMP. We still need some warning in the function
documentation to tell developers about this weakness in the tool GUI.
This complements the existing text_layer_get_markup function and allows
scripts to create and modify complex text layers.
It adds the <markup> root tag if it was not supplied and will run the
markup through pango_parse_markup() to check for errors.
Reviewer's (Jehan) note: this is a mostly untouched patch contributed in #534,
except that code moved around. I also fixed the header set in the .pdb, a link
to pango markup docs and added the meson changes.
Fixes:
> /usr/bin/ld: ../libgimp/.libs/libgimpui-3.0.so: undefined reference to `gimp_check_custom_color2'
I am actually unsure this fix is fine. It doesn't look like it should
work. And worse, I can't reproduce the fix by reverting it after.
The only other person who reported it was akk, with exactly the same
symptoms.
As diagnosed in #8649, using a guint32 for windows identifier may have been
right long ago (was it?), but is definitely not anymore. I can see that a XID is
an unsigned long nowadays (usually 64-bit on 64-bit Linux).
As far as I can see, on Windows, it would be a void* behind (which also
corresponds to the error message in #8649 description):
> typedef void *PVOID;
> typedef PVOID HANDLE;
> typedef HANDLE HWND;
Cf. https://learn.microsoft.com/en-us/windows/win32/winprog/windows-data-types
I *think* that pointers would be 64-bit on Windows 64-bit, though I'm unsure
(after all, this is an OS with 32-bit long int on 64-bit arch!).
Anyway, it's just better to move to 64-bit window identifiers.
Since Clang 15.0.0:
> The -Wint-conversion warning diagnostic for implicit int <-> pointer
> conversions now defaults to an error in all C language modes. It may be
> downgraded to a warning with -Wno-error=int-conversion, or disabled entirely
> with -Wno-int-conversion.
… gimp_procedure_config_save_metadata().
If you use gimp_procedure_config_save_metadata() or
gimp_procedure_config_end_export(), you don't really control the flags
and let the GimpProcedure API make somes choices for you, based on
various assumptions. One of them is that the procedure has specific
properties (named "save-*", either created manually or with the various
gimp_save_procedure_set_support_*() functions). So if you don't have
them, we should assume this format doesn't handle a given metadata
format and deactivate it.
For plug-ins with a different/specific logic, they are expected not to
use these helper functions. They would likely call lower level functions
such as gimp_image_metadata_save_finish() or the newer
gimp_image_metadata_save_filter(), where you control the metadata flags.
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
Adds a simulation_bpc and simulation_intent to GimpImage to allow
plug-ins to access it
for CMYK import/export.
Four pdb functions were added to enable this access:
image_get_simulation_bpc (), image_set_simulation_bpc (),
image_get_simulation_intent (), and image_set_simulation_intent ().
Next, it updates menu options and code to support GimpImage's
internal simulation intent and bpc.
New 'simulation-intent-changed' and 'simulation-bpc-changed signal
are emitted via
GimpColorManagedInterface so that relevant tools
(such as the
CYMK color picker, GimpColorFrame, and future pop-overs)
are aware of these changes.
Ironically, it is a test for the Windows platform but it cannot run on
Windows. First, because it expects a .so (which could be easily fixed),
but even more because from web search, it looks like the nm tool may not
exist on Windows (though I haven't checked).
Anyway we only ever ran it from Linux machines and up to now, it worked
just fine and was useful anyway. So let's go with it.
Also clean a bit remnants from older attempts to run this script.
Our meson build system was not properly building the enums.c file,
because they are versionned.
I did a similar trick as what I did for the pdbgen, which is that I used
a wrapper script around the existing perl script, which sets proper
options and generate a stamp file in the end (which is considered by
meson as the actual custom target, not the C file since it is generated
in the source dir).
The most important part is that the stamp file is a generated header
source (not just a random text file) which is **included** by the
generated C file. This is what will force meson to regenerate the C file
if the header is updated, **then** build using this new version, not use
an outdated versionned version (which would make for hard to diagnose
bugs), through the indirection of the intermediate stamp header.
See #4201.
See also: https://github.com/mesonbuild/meson/issues/10196#issuecomment-1080742592
The check script now takes into account both the autotools and meson
file hierarchy (in autotools, built libs are in .libs/ subdirs).
Also it now properly fails on missing lib.
Continuing the changes in #8124, let's have properties labels and blurbs
both localized on plug-in code, i.e. with gettext calls directly in
GIMP_PROC_ARG_*() calls.
Note that it was already the case for blurbs (longer description,
tooltip) as I couldn't find code where we'd localize it further down the
line. But we were running gettext on nicks (shorter description, label)
inside GimpProcedureDialog code. Let's not do this anymore.
This will make the whole localization much more clear and obvious. There
is no "later localized" case anymore. Now let's localize everything
directly when the arguments are created.
Plug-in localization was always partially plug-in side, especially for
things like custom GUI. But labels or blurb in GIMP (such as in menus or
action search) were localizing GIMP side.
It had many drawbacks:
- To get menu localization, a plug-in had to set up gettext, even though
they might want to use something else for their GUI (after all, giving
facilities for gettext is a good idea, but there is no reason to force
using this system).
- There was a complex internal system passing the localization domain
name, as well as the catalog file system path to core, then through
various classes which we can now get rid of.
- There could be domain name clashes, if 2 plug-ins were to use the same
i18n domain name. This was handled in now removed functions
gimp_plug_in_manager_get_locale_domains() by simply keeping a unique
one (and gimp_plug_in_manager_bind_text_domains() would just bind the
domain to the kept directory). In other words, one of the duplicate
plug-ins would use the wrong catalog. We could try to make the whole
thing more complicated or try to forbid plug-ins to use any random
name (in particular made easier with the new extension wrapper). But
anyway this whole issue doesn't happen anymore if localization is
fully made plug-in side, so why bother?
I tried to evaluate the advantages of the core-side localization of
plug-in labels/blurbs and could only find one theoretical: if we wanted
to keep access to the original English text. This could be useful
(theoretically) if we wanted to search (e.g. in the action search) in
both localized and English text; or if we wanted to be able to swap
easily en/l10n text in a UI without reload. But even if we were to ever
do this, it would only be possible for plug-ins (GEGL operations in
particular are localized GEGL-side), so it lacks consistency. And it's
unsure why special-casing English should really make sense for other
language natives who want text in their lang, and search in their lang.
They don't necessarily care about original.
So in the end, I decided to simplify the whole thing, make localization
of plug-ins a plug-in side thing. Core will only receive translated text
and that's it. It cuts a lot of code out of the core, simplify runtime
processing and make plug-in creation simpler to understand.
The only think I still want to look at is how exactly menu paths are
translated right now. Note that it still works, but it's possible that
some things may be worth improving/simplifying on this side too.
Adds a simulation_profile to GimpImage to allow plug-ins to access it
for CMYK import/export.
Two pdb functions were added to enable this access:
image_get_simulation_profile () and image_set_simulation_profile()
Next, it updates menu options and code to support GimpImage's
internal simulation profile. Menu items are moved from View to Image's
Color Management section.
New 'simulation-profile-changed' signal is emitted via
GimpColorManagedInterface so that relevant tools (such as the
CYMK color picker, GimpColorFrame, and future dockable
dialogue) are aware of these changes.
The get() API are sometimes nicer in C code because it's just simpler to
loop through C arrays, but they end up with similar API to the list()
variants for binding, or with a useless size return value (since most
higher level languages have length-aware array types, which is what
GList are transformed into).
So let's use the list() variants as the main ones and skip the get()
variants. I hesitated to rename the list() variants to get() with
`(rename-to)` annotations but since I am unsure if the get() bindings
are absolutely useless, I don't think it's the best idea. Maybe on some
other language usable as GI binding, the get() variant might be
different again and nicer to use. So if we shadowed these by renaming
list() ones, the day we change our mind, we'd have to rename get() ones
too (which would be very confusing), or else break bindings' API. To
avoid this, I just skip the get() ones altogether in bindings but leave
their name available in the bindings.
… GimpIntStore for value filling.
GimpIntComboBox was not taking ownership of the value store whereas the
newer GimpIntRadioFrame was taking ownership. As a more common practice,
I decided to leave ownership to the caller (which will therefore have
the responsibility to free the data) in the main class and property
widget APIs.
On the other hand, let's steal ownership of the store objects in the
gimp_procedure_dialog_get_int_*() functions as these are really used for
very quick and easy creation of dialogs by script writers. It would even
allow to create a GimpIntStore inline within the widget creation
function, if one wanted to.
… GimpProcedureDialog.
- gimp_prop_file_chooser_button_new() now works also with properties
G_PARAM_SPEC_OBJECT having a value_type == G_TYPE_FILE (additionally
to GIMP_PARAM_SPEC_CONFIG_PATH properties).
- gimp_procedure_dialog_get_widget() will now create a
GtkFileChooserButton in open mode for such a GFile property.
- New gimp_procedure_dialog_get_file_chooser() API to create
GtkFileChooserButton for GFile properties in other modes.
Current limitation: GtkFileChooserButton doesn't have a label. This
should be fixed, probably by creating another custom widget with would
be a labelized file chooser button.
GIMP was saving the last changed/saved date to IPTC tag DateCreated,
which should only be used for the original creating date of the image
and thus should not be changed by GIMP.
After discussion in the cited issue, there is no tag in IPTC that we can
use, so we remove saving modified date from the IPTC metadata.
Instead we add two XMP tags, one for modified date and the other for the
date that metadata was changed. Since we do both when exporting, both are
saved with the same date/time in ISO 8601 format.
This also fixes another issue where we were not storing the timezone offset
for Xmp.tiff.DateTime. Since this has the same format as the other
XMP tags, we fix this together with this issue.
I hesitated a lot whether we should just drop the whole localization of
plug-ins' label and description (blurb) within the core. Actually the
commit messages I wrote a few days ago were moving towards this logic.
It really looks to me like plug-in localization can happen fully within
plug-in themselves. As far as I can see, the only advantage which the
current logic has theoretically is that if we needed, we have access to
both the original strings and their translations (e.g. it could be
useful for text search). Nevertheless I am not sure if we will ever make
use of this, and this is limited cases as all filters turned GEGL ops
don't have such ability anyway.
Nevertheless since previous contributors clearly put quite a lot of work
on this code of localizing the plug-in's label and description within
the main binary, I want to give myself a little more time to think and
study the whole thing because doing anything rash.
In the meantime, what changes is that by default now, a plug-in without
a local gettext catalog is simply not localized. In particular, the core
process doesn't try to localize it using the default catalog, a.k.a.
GETTEXT_PACKAGE"-std-plug-ins" ("gimp30-std-plug-ins"). It just doesn't
make sense and the worst which could happen would be to get unexpected
and wrong translations.
Now by default, plug-ins will try to find a catalog in their main
folder, named as this folder. If it fails to find it, a message is
printed to stderr and localization is disabled (rather than falling back
to a default catalog). It is up to plug-in developers to either install
a catalog, or implement set_i18n() to give the right catalog, folder, or
disable localization with gettext, as handled by libgimp.
We changed the logic of _gimp_plug_in_domain_register() which is now
only called when a domain is explicitly registered (which is not the
case by default anymore). Let's update the function documentation and
also make it clear that third-party developers in particular should not
play with it if they want their plug-ins to be properly localized.
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.
Clearly the old logic for localizing plug-ins was "core plug-ins first":
* In particular, we were defaulting to the "gimp*-std-plugins" domain,
asking plug-ins to override it with libgimp function
gimp_plug_in_set_translation_domain(). Obviously any third-party
plug-in would have to call this function since their strings are most
likely not the same as GIMP core plug-ins.
* Moreover this was only for the localization of menu items, which means
we had to duplicate work anyway (simplified for core C plug-ins only
with the INIT_I18N macro).
* Also plug-ins had to manage the location of the Gettext catalogs,
which is simpler for core plug-ins with gimp_locale_directory(), but
more annoying for third-party plug-ins which can be installed
basically anywhere (assuming their message catalogs are in their
directory, not centrally installed on the system, especially for
non-UNIX-like packages, with relocatable GIMP, no central package
system and so on).
* Finally in this logic of centrally installed catalogs, we were
requesting that the domain name is unique, which makes sense in a
Linux world with well maintained packages to avoid name clashes, not
in a world with people making plug-ins without knowing too much what's
done by their neighbour.
So now the new logic is:
- By default, GIMP will search for a folder called locale/ on the same
level as the plug-in executable. The Gettext domain will be the name
of the executable folder (and it doesn't matter too much if it's not
unique in such configuration).
- This can be disabled by overriding set_i18n() to NULL or
reimplementing it. All our core plug-ins will do this since they will
continue to use the centrally installed "gimp*-std-plugins" domain (or
"gimp*-python" for Python plug-ins).
- When not disabled while the folder is not available, warning messages
will be outputted to stderr, so that plug-in developers can easily
detect what is missing and how to handle it (and how to easily support
internationalization of their plug-in).
- gimp_plug_in_set_translation_domain() is removed and a future commit
is going to get rid of _gimp_plug_in_domain_register() because we are
going to get rid of the core-side localization of menu items (with
logic explained in the upcoming commit).
When overwriting the same file when exporting, we didn't check if the
image previously had a thumbnail. If the default setting in Preferences
is to add a thumbnail, then it would add one where it shouldn't.
Since thumbnails get saves as part of the EXIF metadata, we need to check
that to see if there was a thumbnail in the original image.
However, we were always removing the thumbnail from the metadata on import.
Let's delay removing this metadata until we need to, which has the
advantage that the metadata in our viewer is more complete.
When exporting starts, we add a check in gimp_image_metadata_save_prepare
to see if there was a thumbnail in the EXIF metadata. If not, then we
disable the thumbnail flag.
In gimp_image_metadata_save_filter we remove the thumbnail metadata when
the user doesn't want to save a thumbnail, or when the image format
does not support EXIF.
- Some coding style fixes (alignment, etc.).
- Adding missing "Since: 3.0" annotations. We are still wondering
whether this should go in 2.10, in which case, it would become
"Since: 2.10.32" annotations. See discussion in !274.
- Changing gimp_checks_get_colors() signature: merge the 4 color
arguments into 2 (inout) arguments which seems a bit nicer in C,
whereas binding handles such arguments correctly. The other
alternative would have been to at least change the order to have out
arguments in the end.
I also hesitated to get another API in libgimp, which would have been
config-aware (just returning the 2 check colors, depending on user-set
Preferences), then having GimpPreviewArea handling 2 colors (without a
GimpCheckType input). But actually, doing this, we'd remove the nice
menu popup where one could choose a generic check type (not everyone
wants to play with specific non-gray colors) in Gimp*Preview widgets.
So in the end, I left this whole thing as-is.
Instead I document the function with code sample to initialize
properly the GimpPreviewArea (since libgimpwidgets/ are independent
with no knowledge of the core config) in order to respect user
preferences.
- Hide the color properties in gimp_preview_area_menu_new() because
anyway gimp_preview_area_menu_new() does not support GimpRGB
properties right now (so all we get are warnings). It's still possible
to select custom colors on GimpPreviewArea, simply we are stuck at the
ones set in Preferences globally for now (unless a plug-in creates
custom GUI to set these).
Fixed Conflicts from !274:
libgimp/gimp.h
libgimpwidgets/gimppreviewarea.c
Reviewer (Jehan) note: cherry picked from MR !274. Still deciding
whether this will be pushed to gimp-2-10 branch too.
Fixed Conflicts from !274:
app/dialogs/preferences-dialog.c
app/display/gimpdisplayshell-draw.c
app/plug-in/gimppluginmanager-call.c
libgimp/gimp.c
libgimp/gimp.h
libgimpwidgets/gimppreviewarea.c
libgimpwidgets/gimppreviewarea.h
libgimpwidgets/gimpscrolledpreview.c
The CLI options now know which procedures are batch procedures or not.
First it means that it won't just randomly try any procedure name one
may pass and will properly output an error if you pass a non-existing
interpreter procedure.
Secondly, there is no default interpreter anymore (unless only one
interpreter exists). If you don't set an interpreter procedure with
--batch-interpreter or if you pass a wrong one, it will output the list
of available batch procedure, thus helping you understanding how to use
the --batch option.
Fixes:
> [33/48] Generating Gimp-3.0.gir with a custom command
> ../../../../../../../dev/src/gimp/libgimp/gimpimageprocedure.c:228: Warning: Gimp: missing ":" at column 41:
> * @run_func: (closure run_data) the run function for the new procedure.
> ^
On Windows our Lua goat extension crashed when run. After some digging
it appeared that incorrect annotations were the cause.
The destroy annotation was clearly an error when loking at the gir API
documentation. However, it also crashed on `(closure run_func)`, which
seemed to be as it should.
After comparing what other libraries do and testing, it seems that the
documentation for (closure CLOSURE) is incorrect. See the discussion
in the above mentioned issue.
The correct use here seems to be to use it as annotation of the run_func
where CLOSURE points to the user data. So, that's what we implement here.
Fix the dependency by making the stamp an actual (yet empty/no-op)
header file which is included by all generated source file. This way, we
ensure that meson rebuild .o files when the .pdb sources are changed.
This is the second solution proposed by eli-schwartz here:
https://github.com/mesonbuild/meson/issues/10196#issuecomment-1080053413
The build now successfully build the PDB files into the source folder
itself. Unfortunately it seems I can't get meson dependencies to work
properly, once more! I added a "sources" argument to the relevant
library() or static_library() but it still uses old versions to build
these. E.g. if I add an error on purpose to a pdb file, the next build
still passes, yet the second-next fails (as it should have before).
Note that I even tested a declare_dependency() with just the "sources"
arguments, because it says "sources to add to targets (or generated
header files that should be built before sources including them are
built)" (so I assume it means that it should be trigger a rebuild,
otherwise it's useless) but it's just not working. I'll investigate
more.
Still going with this for now, because at least generating the PDB
source was a big miss until now. But we should
The initial attempt of this commit was to remove the `GtkAction` usage,
but grew a bit wider than that. The following happened:
* The dialog became a proper GObject, rather than being a big chunk of
static variables that were hopefully initialized before you used them.
* The dialog now uses `GAction`s to implement actions, and converted
some signal handlers to actions as well.
* The plug-in run procedure now uses `GtkApplication`. This is one hand
necessary to be able to set accelerators for actions, but on the other
hand is more future-proof, as GTK4 removes `gtk_main()`
This new function is an alternative to existing
gimp_image_metadata_save_finish, when you want to save metadata
yourself and you need only filtering processing.
It returns filtered metadata allowing the caller
to save the finalized metadata via other means
(via native format’s library for example)
This API can be used to support metadata saving of image formats
not directly supported by gexiv2/exiv2.
… %GIMP_TYPE_SPIN_SCALE in gimp_procedure_dialog_get_widget().
The dedicated function is for when a plug-in wants to use a scale range
multiplied by a factor. Otherwise using the generic function is fine.
Now the warning is:
WARNING: Invalid fragment for 'Gimp.Config': it should be struct
It implements the [iface@Config] interface and therefore has all its
^~~~~~~~~~~~~~
This warning feels wrong as we use GimpConfig for the name of the
interface, yet in the .gir file, I see `<record name="Config" …>` yet
`<interface name="ConfigInterface" …>`.
I suppose gi-docgen would want us to use [iface@ConfigInterface] if we
want to link the interface. But looking at the gir file, all interesting
interface methods are associated to the Config record. So let's just go
with the [struct@Config] proposed by the warning.
In any case, something feels wrong or broken here, but we need to fix
this for the CI. I hope Niels can look at it at some point.
Fixing these 2 warnings in the CI which end up fatal:
WARNING: Invalid fragment for 'Gimp.Parasite': it should be struct
Serializes the object properties of @config to a [class@Parasite].
^~~~~~~~~~~~~~~~
WARNING: Invalid fragment for 'GLib.MainLoop': it should be struct
it has a GUI and is hanging around in a [class@GLib.MainLoop], it must call
^~~~~~~~~~~~~~~~~~~~~
Now using the new GimpLabelColor as new default for RGB properties. It
makes more sense that the default is editable widgets. Also it has a
label, which is better default widget.
Also gimp_procedure_dialog_get_color_widget() now only returns
GimpLabelColor widgets.
As Massimo notes, the issue is not about the callback being broken in
bindings, but simply that bindings fail to handle random data without an
associated size. So let's just add the size. I confirmed testing API in
the Python binding that it now works fine.
GLib has a specific type of NULL-terminated string arrays:
`G_TYPE_STRV`, which is the `GType` of `char**` aka `GStrv`.
By using this type, we can avoid having a `GimpStringArray` which is a
bit cumbersome to use for both the C API, as well as bindings. By using
`GStrv`, we allow other languages to pass on string lists as they are
used to, while the bindings will make sure to do the right thing.
In the end, it makes the API a little bit simpler for everyone, and
reduces confusion for people who are used to working with string arrays
in other C/GLib based code (and not having 2 different types to denote
the same thing).
Related: https://gitlab.gnome.org/GNOME/gimp/-/issues/5919
While we do have quite a few gimp_pdb_run_procedure*() functions now, I
always felt that one based on a config file was missing, even more as we
are getting further and further into using config objects in plug-ins.
In C, the gimp_pdb_run_procedure() function is without a doubt the
easiest one. But such variable arg functions are not available on
bindings, and having to deal with GValue and GimpValueArray is a real
pain.
Also using a config file has the very great advantage that we don't need
to care about order. For instance, if I need to set the 10th argument of
a PDB call (and leave the rest to default values), I don't have to set
all 9 previous arguments. I can set only this one if I want. This
advantage is useful also for C code by the way.
For the record, here is how you could load then export an image with the
"file-png-*" PDB procedures in Python:
> c = Gimp.get_pdb().lookup_procedure('file-png-load').create_config()
> c.set_property('file', Gio.file_new_for_path('/path/sample.png'))
> r = Gimp.get_pdb().run_procedure_config('file-png-load', c)
> d = Gimp.Display.new(r.index(1)) # Give it a display to work on it.
Now exporting:
> img = r.index(1)
> c = Gimp.get_pdb().lookup_procedure('file-png-save').create_config()
> c.set_property('image', img)
> c.set_property('file', Gio.file_new_for_path('/path/exported.png'))
> layers = img.get_layers()
> c.set_property('drawables', Gimp.ObjectArray.new(Gimp.Drawable, layers, False))
> c.set_property('num-drawables', len(layers))
> r = Gimp.get_pdb().run_procedure_config('file-png-save', c)
… assert the existence of GError.
This is even worse as deserialize() method does not even take a GError
parameter anyway so this assert will always go off when a
deserialization failed (which happened in my case as I was working on a
plug-in API, hence gimp_procedure_config_load_last() actually failed to
load a previous version of the plug-in-settings when I changed a
procedure arg's type).
Just fail the deserialization normally and let the calling code handling
this case. Nevertheless it is kind of useful to bubble-up the error to
calling code, so I add a TODO in the interface header (hopefully to see
and improve this before we release GIMP 3.0).
Last deprecated usages in this file. Actually there are a few other
calls but deprecated on GExiv2 0.14.0, hence over our current
requirement. So we'll have to handle these later.
Replace functions gexiv2_metadata_set_xmp_tag_struct() and
gexiv2_metadata_get_tag_type() with their _try_ variants.
Note that I print to stderr rather than raising a warning here as I am
quite unsure where the list of XMP metadata we are gathering comes from.
Is it fully validated by GExiv2, and therefore no errors are ever
supposed to happen? (in such case, we should raise a warning if it does)
Or is it user-provided data (e.g. from a file loaded in GIMP which can
contain broken metadata)? In such a case, we should probably handle the
error slightly differently to warn for non-processable data (hence
possibly metadata loss at export time).
For the time being, then go with this weak handling and take care of
this better when we can look further into this.
… gexiv2_metadata_try_set_tag_string().
These are usage where we have full control over tag names and values so
no error is supposed to happen. This is why we use them as code warnings
and not returned error (because if an error did happen, this would be a
bug rather than a user error or a system error).
Here are the changes:
- Separate the check for comment contents and the one of whether or not
it starts with "charset=Ascii ". Indeed in my tests, we still want to
handle the empty string case or the "binary comment" case even without
the charset prefix (currently it was both or none, so I encountered
cases with a broken "binary comment" comment because the charset
prefix was absent).
- Add some #warning in order not to forget to remove the bogus "binary
comment" test. Indeed after some digging in Exiv2 code, I could
confirm this return value got removed in commit 9b510858 of Exiv2
repository, i.e. since Exiv2 0.27.4. Now in my test case where I had a
tag containing only 0s, Exiv2 returns an empty string, which is
perfectly fine (and it's up to us to keep or ignore it).
- Use gexiv2_metadata_try_get_tag_interpreted_string() instead of their
deprecate non-try counterparses. Right now, I am just outputting any
error message to stderr, as I'm not sure if this is the kind of errors
we want to warn people about. I guess it would depend on which type of
errors exactly are returned, so let's see if we encounter some case in
the future. For now stderr is fine to detect these.
yocto/oe is capable of building gobject introspection despite cross-compiling.
add an option to enable gir build even if cross-compiling
Signed-off-by: Markus Volk <f_l_k@t-online.de>
Reviewer note (Jehan): this whole stuff is a mess. Actually I'd like to
simply get rid of the whole no-gir-when-cross-compiling logics but I
still can't figure out how to cross-build generically with GIR.
Yet since some manage it with yocto, let's unblock them.
See #7208.
gtk-doc has been slowly dying for the past few years; with gi-docgen we
have a nice successor.
This also makes sure the C documentation also uses the GIR file, which
in turn means faster build times (since all the C code doesn't have to
be parsed and recompiled again), and has a clear dependency graph.
See the [gi-docgen tutorial] for more info on how the system works.
[gi-docgen tutorial]: https://gnome.pages.gitlab.gnome.org/gi-docgen/tutorial.html
I cleaned many remaining places where the concept of linked item still
survived.
On loading an XCF file with linked items, we are now going to create a
named sets for the linked items, allowing people to easily select these
back if the relation was still needed.
We don't remove gimp_item_get_linked() yet and in particular, we don't
save stored items into XCF files. This will come in an upcoming change.
When running tests, the data are not meant to be necessarily installed.
Therefore icons won't be found when calling gimp_widgets_init().
Add some special-casing to find them relatively to the install
directory.
Fixes the patch from !470 which is mostly right, except that
g_param_spec_sink() may possibly lead to finalizing the GParamSpec
(typically if it was a just-created floating spec). We don't want to
return pointer to freed data. Let's return NULL instead.
Also looking closer at the memory handling here, it looks the right
annotation for @pspec is (transfer floating). Basically we are sinking a
floating object into a full object and taking ownership of this sunk
object. But if the object was already sunk, we are reffing it and
keeping this additional reference, not the passed argument's. Hopefully
it's right since the annotation and handling of floating object with
GObject Introspection seems very unclear to me (even in core GObject
code, I see what looks like contradictory annotations).
In the normal flow, pspec is persisted in the arguments array, and is
g_param_spec_ref_sink()'d in order to sink a possible floating ref. To
avoid a leak in the error case, we need to add some g_param_spec_sink().
Saving a thumbnail is closely related to the other metadata preferences,
but so far this was the only one that didn't have a preference for a
default user value.
This commit adds a preference in the metadata section where a user can
select whether thumbnail saving is enabled by default or not.
Since it appeared with GLib 2.68.0, we could not change this until we
bumped the dependency which has only become possible a few days ago
(since Debian testing is our baseline for dependency bumps). Cf.
previous commit.
As this is a drop-in replacement (just a guint parameter changed to
gsize to avoid integer overflow), search-and-replace with:
> sed -i 's/g_memdup\>/g_memdup2/g' `grep -rIl 'g_memdup\>' *`
… followed by a few manual alignment tweaks when necessary.
This gets rid of the many deprecation warnings which we had lately when
building with a recent GLib version.
It is now discouraged to create constructor-type _new() functions with
custom code, which would make them behave differently that simply
calling g_object_new() with the GType and relevant properties. The main
reason is that some bindings would create objects with g_object_new() so
it should create expected code too.
See: https://gi.readthedocs.io/en/latest/writingbindableapis.html#custom-code-in-constructors
Here it was complicated for a few reasons:
- We hack "title" property to use the procedure's menu label by default
(without the mnemonic). For this, I overrode the GtkWindow property.
- We want "use-header-bar" to follow the application general settings by
default. Since it is a CONSTRUCT_ONLY property, g_object_set() is not
possible in _init() and _constructed(). Instead I had to override the
constructor() method to set this at construction time (yet still allow
API users to override this with the property at creation).
- Similarly, "help-func" is a CONSTRUCT_ONLY property, so I used the
same trick.
- As for "help-id", I now just set it in _constructed(). This was the
easy one.
All objects of subclass GtkWindow are special as they are actually owned
by GTK which keeps a list of all top-level windows. So we cannot
actually give ownership to the caller. With GObject Introspection in
particular, it will mean a double-free of the dialog object (by GTK,
then by the GI layer).
See also gobject-introspection#394.
As explained in GtkSizeGroup docs, all objects inside a size group holds
a reference to it. So once we destroy the last object inside these, it
will be freed too and we should drop the initial reference after adding
the objects.
Only the main size group reference is kept until the end, because we are
adding and removing objects from it regularly, so it is possible that it
is empty again at some intermediary states. Yet we don't want to free it
when this happens.
All the widgets with label inside GimpProcedureDialog have same
GtkSizeGroup (dialog->priv->label_group), which result in wrong sizes of
widget if any of the label is long. In this commit, a new GtkSizeGroup
is made for each of the container, so that labels are aligned but size
of widget in one container do not affect size of widgets in other
containers.
For the widget not belonging to any of the container, default
GtkSizeGroup (dialog->priv->label_group) is used.
Added an option for exporting thumbnail in WebP Export dialogbox.
Additionally, introduced a function gimp_procedure_dialog_fill_expander.
The function is similar to gimp_procedure_dialog_fill_frame but allows
adding GtkExpander instead of GtkFrame.
When GIMP_PROCEDURE_SENSITIVE_NO_IMAGE is set on a GimpImageProcedure,
add GIMP_PARAM_NO_VALIDATE to the param spec flags, allowing to pass a
NULL image.
Somehow the callback doesn't work for bindings (at least Python binding,
python plug-ins crash when the callback is called), so we'll still want
to have a closer look at this.
When a selection exists, we are copying then pasting the selection
contents. In particular, with multi-layer selection, it means pasting a
merged result of the selected layers (like a sample merged but limited
to selected layers).
Yet when no selection exists, with a single layer selected, a cut in
particular would remove the layer fully, then a paste would copy it
elsewhere (in the same image or even on a different image). This was
still working, but not with multiple layers. This is now fixed and we
can now copy/cut then paste several layers (without merge), which is
sometimes a very practical way to move layers (sometimes simpler than
drag'n drop, especially between images).
As a consequence, the PDB function gimp_edit_paste() now also returns an
array of layers (not a single layer).
Though the previous implementation worked fine on C plug-ins, I realized
it was problematic on bindings. In particular, the Python binding at
least was somehow freeing returned floating objects, unless assigned to
a variable.
For instance, the widget returned by the following code:
> dialog.get_color_widget('color', True, GimpUi.ColorAreaType.FLAT)
… was freed by the PyGObject binding when it was floating, even though
(transfer none) was set (hence telling the binding it should not free
the returned object). The workaround was to assign it to some variable,
even though I was not planning to use it.
Making sure all references are full fixes it.
GObject docs also notes:
> **Note**: Floating references are a C convenience API and should not
> be used in modern GObject code. Language bindings in particular find
> the concept highly problematic, as floating references are not
> identifiable through annotations, and neither are deviations from the
> floating reference behavior, like types that inherit from
> GInitiallyUnowned and still return a full reference from
> g_object_new().
… GimpProcedureDialog.
Technically I added:
- New gimp_prop_color_select_new() property widget to create a
GimpColorButton for a given GimpRGB property.
- gimp_procedure_dialog_get_widget() now supports a GimpRGB property and
will create a GimpColorArea by default.
- When the default doesn't suit you, a new function
gimp_procedure_dialog_get_color_widget() allows to create either a
GimpColorArea or a GimpColorButton (editable = TRUE), as well as
choose the area type (small or large checks, as well as flat area,
i.e. no alpha support).
Still the same problem as ever with the Python binding where we have a
hard time creating GParamSpec, hence we make them from object
properties.
See: https://gitlab.gnome.org/GNOME/pygobject/-/issues/227#note_570031
But then again, the Python binding way to create GObject properties does
not seem to give us a way to use our custom param types (or I didn't
find how). So when I create a property with Gimp.RGB type in Python, it
doesn't appear as a GIMP_PARAM_SPEC_RGB to our C code, but as a
G_PARAM_SPEC_BOXED. So my trick is to check the value type instead.
Note that I check the default value, but in reality it doesn't seem to
work much either. Better than no support at all anyway.
… with the updated API with one more argument (n_drawables + drawables
instead of single drawable).
This went unnoticed as most plug-ins use a config with named properties
instead of ordered GimpValueArray now.
New function to set some procedure dialog's widget sensitive, either
with a constant value, or by binding it to a boolean property (or its
inverse) of a config object.
The gimp_drawable_type() is an issue though as gimp_drawable_get_type()
is already defined as a common GObject API.
Though I'm actually wondering if GimpImageType is well called. Rather
than Type, shouldn't we go with ColorModel?
sed -i 's/\<gimp_drawable_bpp\>/gimp_drawable_get_bpp/g' "$@"
sed -i 's/\<gimp_drawable_width\>/gimp_drawable_get_width/g' "$@"
sed -i 's/\<gimp_drawable_height\>/gimp_drawable_get_height/g' "$@"
sed -i 's/\<gimp_drawable_offsets\>/gimp_drawable_get_offsets/g' "$@"
… the public API.
This was initially proposed by Niels De Graef in !101, and though I
still think this is much less practical for day-to-day development, it
is actually much nicer for the public part of the API. So let's use
these only in public libgimp* API only, not in core.
I actually already started to use these for some of the libgimpwidgets
classes and am now moving libgimp main classes to these macros.
* It doesn't expose the priv member (which is completely useless for
plug-in developers, only to be used for core development).
* It forces us to never have any variable members in the public API
(which we were doing fine so far in newest API, but it's nice to be
enforced with these macros).
* When using G_DECLARE_FINAL_TYPE in particular, it adds flexibility as
we can change the structure size and the members order as these are
not exposed. And if some day, we make the class derivable with some
signals to handle, only then will we expose the class with some
_gimp_reserved* padding (instead of from the start when none is
needed). Therefore we will allow for further extension far in the
future.
Moreover most of these libgimp classes were so far not using any private
values, so we were declaring a `priv` member with a bogus contents just
"in case we needed it in future" (as we couldn't change the struct
size). So even the easiness of having a priv member was very relative
for this public API so far (unlike in core code where we actually have
much more complex interactions and using priv data all the time).
s/gimp_image_base_type/gimp_image_get_base_type/
s/gimp_image_width/gimp_image_get_width/
s/gimp_image_height/gimp_image_get_height/
Sorry plug-in developers, more porting work! But really this seems like
the right thing to do in order not to get stuck with inconsistent naming
for many more years to come.
As the docs says, this was always allowed and would just imply we want a
dialog with all properties in order of declaration.
Yet this usage would output this warning:
> plug-ins/file-fli/fli-gimp.c:976:3: warning: not enough variable arguments to fit a sentinel [-Wformat=]
This commit take care of this warning.
There was at least a case when gimp_procedure_create_config() was called
twice, hence so was gimp_save_procedure_add_metadata() when a plug-in
was run.
It was happening when calling a procedure with less arguments than the
procedure had. In such case, gimp_procedure_run() would create a config
to fill it with defaults.
Fixes warnings such as:
> LibGimp-WARNING **: 01:29:57.044: Auxiliary argument with name 'save-exif' already exists on procedure 'file-png-save'
I always found the docs misleading because when it says "Returns the
list of layers contained in the specified image", I really read "all the
layers, at any level", except it doesn't. It only returns the root
layers and it is up to the plug-in developer to loop through these if
one needs to go deeper.
So let's make the function docs clearer.
We heavily rely on GError in libgimp to retrieve plug-in error messages.
In a lot of our code, we just use domain=0 for g_set_error*() functions
and alike, but this is actually forbidden and results in GLib warnings.
Some plug-ins instead create their own domain, other use G_FILE_ERROR
nearly everywhere, even in some cases where the choice is really
questionable. Since anyway this is mostly useful for passing the error
message through, it is much nicer to provide a generic domain
GIMP_PLUG_IN_ERROR, which can be used by all plug-ins when they don't
want to bother with the error domain.
… drawable array instead of a single drawable.
Instead of expecting a single drawable, GimpImageProcedure's run()
function will now have an array of drawable as parameter.
As a consequence, all existing plug-ins are broken again. I am going to
fix them in the next commit so that this change can be easily reviewed
and examined if needed later.
I only fix the Vala demo plug-in now (or rather, I just use the first
layer in the array for now) because otherwise the build fails.
The new function gimp_procedure_set_sensitivity_mask() allows plug-ins
to tell when a procedure should be marked as sensitive or not.
gimp_procedure_get_sensitivity_mask() retrieves this information.
Currently plug-ins are automatically marked as sensitive when an image
is present and a single drawable is selected. Nowadays, we can have
multiple selected layers so we should allow plug-ins to tell us if they
support working on multiple drawables. Actually we could even imagine
new plug-ins which would be made to work only on multiple drawables.
Oppositely, there are a lot of plug-ins which don't care at all if any
drawable is selected at all (so we should allow no drawable selected).
Finally why not even imagine plug-ins which don't care if no image is
shown? E.g. plug-ins to create new images or whatnot. This new API
allows our core to know all this and show procedure sensitivity
accordingly. By default, when the function is not called, the 1 image
with 1 drawable selected case is the default, allowing existing plug-ins
easier update.
Note: this only handles the sensitivity part right now. A plug-in which
would advertize working on several layer would still not work, because
the core won't allow sending several layers. It's coming in further
commits.
Since version 0.27.3 exiv2 has changed how it returns
comments for Exif.Photo.UserComment. We now get
the comment including the charset=Ascii value.
Let's remove anything that's not part of the actual
comment. To not complicate things we will only
handle charset=Ascii for now since I've never seen
any other charset used.
1. Convert xmp /Iptc4xmpExt tag parts to /iptcExt because
exiv2 fails when we try to use the default namespace.
2. Don't only set structs from a fixed list but find all
xmp array elements and check what the best struct
type is: bag or seq.
3. Work around a sorting issue in (g)exiv2 by using a natural
sorting algorithm ourselves.
4. Added some g_debug statements to make it easier to
determine the cause of issues.
This fixes the following warning (and 4 similar others):
> libgimp/gimpimagecombobox.c:133: Warning: GimpUi: "destroy" annotation needs one option, none given
Brought by commit df766d5443. It's my fault for not properly reviewing
the patch as I failed to notice the new warnings.
Similar to gimp_image_set_selected_layers() except that it takes a GList
(instead of a C array) and also it takes ownership of the list pointer.
This makes it much easier to use in some specific situations.
It isn't being used by any plug-in or any code in GIMP at all even.
Let's get rid of it while we can still break API, so we can cut down on
all the complexity of the gimp-param stuff a bit.
- Do not only check the step width, but also the time interval between 2
progress calls. No need to run a PDB call, then update the GUI every
millisecond or so. This would just unecessarily slow down the plug-in
for updates which the user won't ever see. From my tests, 20 updates
per second is plenty enough to have the progression look fluid. No
need for much more.
- Do not warn anymore on stderr when we drop progress updates. Even if
just on the unstable builds, such warning is wrong. First because it
depends on files and machines. Typically a lot of processing could set
their progress updates relatively to layers. Yet we currently consider
that 1/256 steps are too small. So what if you have more than 256
layers? This would make the same code print a warning on big files,
and none on small files.
The second reason is that we should not encourage plug-in developers
to have limited progression updates, but the opposite (progression
info makes for good feedback), neither should we expect them to
compute the step size or the time between updates. It's a much saner
approach to have them only take care about computing relevant update
steps while our API focuses on filtering these in order to avoid
overloading the GUI.
It makes for good progression feedback, sharp GUI while not taking all
CPU time on it, all this while making it easy on plug-in developers.
… but only when a menu label was set with
gimp_procedure_set_menu_label(). In such case, this menu label is used
as dialog title (with mnemonic underscore removed).
The `precision` parameter in particular had no min/max, which meant we
could provide a forbidden parameter (e.g. a negative precision) which
would cause a core CRITICAL. We must forbid illegal values from PDB side
(hence outputting a normal plug-in error message, not a core bug).
Also improving a bit the description of this parameter as I was
wondering what precision was needed exactly to get a stroke length. This
is the precision for determining whether a portion of the stroke is
"straight enough" or if we want to break it into smaller pieces until we
get a straight portion.
The term "Defaults" is not clear enough and looks like it may be
redundant with the "Factory Defaults" button. Let's try an alternative
"Save Settings" and "Load Saved Settings".
Also adding some tooltips.
And finally making the "Load Saved Settings" only sensitive if the "Save
Settings" button had been used at least once.
This is what the GNOME's HIG calls a "button menu" apparently. Adding
this arrow makes it clearer that it is not a finale action but an
intermediate one allowing you to see more choices.
See also report #6145 where this was raised among other things.
`g_object_notify()` actually takes a global lock to look up the property
by its name, which means there is a performance hit (albeit tiny) every
time this function is called. So let's encourage using
`g_object_notify_by_pspec()` instead.
Another nice advantage is that it's a bit safer at compile-time, since
now typos will at least be caught by the compiler (as the enum value has
to match).
I was trying to avoid too large dialogs as this `metadata` frame can
hold random plug-in settings. But let's go for always the same number as
columns as the max number of common settings (i.e. most often 3
columns).
Use gtk_widget_list_mnemonic_labels() to look for mnemonic of common GTK
widgets. Also warn when several mnemonic were set on a given widget
("wasting" keys when it seems we are always looking for available
mnemonics).
Also warn with core action IDs too when they miss a mnemonic.
Update `gimp_window_get_native_id()` a little to be more correct
(although it still won't work on Wayland).
Most important of all, we shouldn't assume that if a given GDK backend
is enabled at compile time, that this is also the one that is being
used. For example, on Linux, both `GDK_WINDOWING_X11` and
`GDK_WINDOWING_WAYLAND` can be set, but you still need to do a runtime
check if you're running under one WM or the the other.
A small cleanup is that we immediately check if a widget is realized by
checking if it's `GdkWindow` is NULL or not and return immediately
(since we need to check its type later on anyway).
Finally, we can remove `GDK_NATIVE_WINDOW_POINTER` as that is a GTK+ 2.0
construct, so it's dead code anyway.
This issue is happening on all 4 plug-ins using the new API, it would
seem, but only on Windows.
Looking at stack trace, I believe we might simply be freeing a mutex
twice because dispose() is allowed to be called several times. Let's
make this finalize() code instead (the data freeing we do there looks
much more adapted for finalize() anyway).
… GimpSaveProcedureDialog.
See issue #6092 and the discussion with Jacob. Basically we are trying
to improve the metadata situation with more edit abilities and
awareness, while in the same time having the export dialogs less of a
mess (the "Comment" input in particular will most likely move to the
metadata editor itself; I left it for now, until the move is done).
The "(edit)" link will basically just run "plug-in-metadata-editor".
Also as a side note: I realized that gimp_pdb_run_procedure() runs
procedures synchronously and wait for a result, which is fine for quick
non-interactive plug-ins, but freezes the calling process otherwise.
Actually even when we want synchronous result, we should allow for GUI
events to be processed (otherwise the OS just thinks the calling export
plug-in is a zombie and proposes to kill it). This API should probably
be improved (and an alternative async version added as well).
It is a bit more flexible. Also this fixes the ugly focus issue we had
on the comment text input (which might disappear soon anyway, but since
this frame is meant to also display user-created widgets, better to not
have a container breaking text widgets).
I am not 100% happy for the generated layout, but this is meant to
evolve anyway.
This format name is a public facing name for a file format, such as
"PNG", "JPEG", or "C-source". Since it is public facing, the function
recommends to localize it too.
This is an optional name, yet is made mandatory if you want to use
GimpSaveProcedureDialog because it will be used for the dialog title
(ensuring that all support format have a similar export dialog title).
Following this change, gimp_save_procedure_dialog_new() does not ask for
a title anymore (if anyone absolutely wants to set a custom title,
setting the "title" property on the dialog is always possible anyway,
but a generic and consistent title should be set as a default).
Also updating the 3 plug-ins which were already using the now-changed
API.
Make sure that the OK button ("Export", etc.) is always the default
action in a GimpProcedureDialog. This allows to quickly validate the
default settings.
The various generic metadata options did not have mnemonic in the base
language (US English).
Also add or fix metadata in file-png|jpeg|tiff so that every option has
a unique mnemonic.
Though a GimpScaleEntry could already be created with
gimp_procedure_dialog_get_widget(), this specific function allows to add
a factor to the property range.
Similar code was used in 2 places basically (GimpLabelSpin and
GimpProcedureDialog) so just make it an utils function. It's good anyway
to have a generic function to estimate suitable increments and decimal
places depending on a range.
As a consequence also gimp_label_spin_new() now takes a gint digits
(instead of guint), with -1 meaning we want digits computed from the
range.
Similarly gimp_prop_scale_entry_new() docs adds the -1 meaning too.
- New gimp_procedure_dialog_fill_box(_list)() functions to create a
GtkBox in the layout.
- Generating widgets for parameters of type double (and computing
appropriate "ok defaults" digits for these, depending on the min-max
range of the property).
Similar to the message present in file-jpeg. The latter will anyway
disappear when we will have finally ported file-jpeg to newer
GimpSaveProcedure API, and it's better to have it outputted here so that
it will work for every export formats.
… class GimpSaveProcedureDialog.
The idea is that we have basically the same code in most file format
plug-ins to handle various generic metadata, yet usually with slight
differences here and there. Even behavior is sometimes a bit different
even though there is no reason for the logics to be different from one
format to another.
So I move the metadata support logics into GimpSaveProcedure (and
GimpProcedureConfig still keeps the main export logics). The GUI logics
is now in a new GimpSaveProcedureDialog. So export plug-ins will now get
the creation of generic metadata nearly for free. All they have to do is
to tell what kind of metadata the GimpSaveProcedure supports with the
gimp_save_procedure_set_support_*() functions.
Then consistency will apply:
- If a format supports a given metadata, they will always have an
auxiliary argument with the same name across plug-ins.
- The label and tooltips will also be always the same in the GUI.
- Order of metadata widgets will also stay consistent.
- The widgets will work the same (no more "Comment" text view missing in
one plug-in but present in another, or with an entry here, and a text
view there, and so on).
Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins
to "declare" one of their options as a metadata option, and therefore
have it packed within the "Metadata" block which is now created (for
instance for PNG/TIFF/JPEG specific metadata). This allows a nicer
organization of dialogs.
A very common issue we have with dialog creation is good mnemonics. In
particular, we want to:
* Keep consistent mnemonics for common features (basically the core
buttons) common to all plug-in dialogs.
* Have mnemonics for all options.
* Avoid duplicate mnemonics if possible.
Mnemonics are a usability/accessibility feature which can be important
for people using the keyboard a lot (not necessarily only because they
prefer keyboard, but also possibly because of various disorders).
This code will check at runtime that there are no missing or duplicate
mnemonics and simply print to stderr. We don't want to bother overly the
users about these, but we want developers and translators to be aware
about these so that they can easily spot and fix them.
Existing implementation was repeating the hours and minutes. This was
obviously not what the format asked. The last hour and minutes are the
ones from the timezone offset. Also rather than playing with snprintf()
and various calls to get each component, let's use g_date_time_format()
which is done exactly for such use case.
It is to be noted that there seems to be a bug in Exiv2 such that the
date and time set through Exiv2 return an error when read back, still
with Exiv2. Read and write use different format. I have reported this
issue, together with a patch (hopefully a good one).
https://dev.exiv2.org/issues/1380
So once this patch (or another) gets merged upstream, the following
warnings (e.g. when reopening a PNG created by GIMP) should disappear:
> ** (file-png:176245): WARNING **: 02:43:25.204: Unsupported date format
> ** (file-png:176245): WARNING **: 02:43:25.204: Unsupported time format
gimp_procedure_dialog_fill_frame() allows creating a GtkFrame, in
particular with a boolean widget which can therefore control
sensitivity of the frame contents.
gimp_procedure_dialog_get_label() creates a simple text label.
- New GimpLabelIntWidget which is a label associated to any widget with
an integer "value" property.
- New gimp_procedure_dialog_get_int_combo() which creates a labeled
combo box from an integer property of the GimpProcedureConfig.
- Renamed gimp_procedure_dialog_populate*() with
gimp_procedure_dialog_fill*(). Naming is hard! I hesitated using
_pack() as well (similarly to GtkBox API).
- New gimp_procedure_dialog_fill_flowbox*() functions to create a
GtkFlowBox filled with property widgets (or other container widgets as
we can pack them one in another). This is an alternative way to build
your GUI with sane defaults, with list of property names.
- Add some border width on the main dialog box.
- Remove the additional border width on the button box but add some
padding instead to separate it a bit from the specific plug-in
widgets.
- Add GimpLabelSpin as one of the possible property widgets to represent
an integer property and make it the default.
- Put labels of GimpLabeled widgets into a common GtkSizeGroup so that
labels and entry widgets are aligned, hence much faster to parse with
the eyes.
This is still a very early baseline for a more extended API. This first
version is not able to capture the complexity of most existing plug-in
dialogs.
It is more accurate to say it returns a list of parasite names rather
than a list of parasites (as we could take it as meaning a list of
GimpParasite). Of course, we would soon see the actual element contents
(if not for the introspection metadata (element-type gchar*)), but
better being accurate in textual docs too.
Commit d3139e0f7c added suuporting for saving/exporting with
muti-selection, but forgot to added the necessary GObject Introspection
annotation for the callback's `drawables` argument, which confused
bindings.
https://gitlab.gnome.org/GNOME/gimp/-/issues/5312
There were still a few references to functions which have been removed
from GIMP 3 (because they were deprecated in previous versions), which I
found as I was doing an inventory of removed functions.
Saving metadata was added inside the loop where the flags for
the differen types of metadata etc. to be saved were updated.
This caused multiple calls to save metadata with inconsistent
settings.
Though GObject Introspection is normally not an option, the only case we
don't build it yet is when cross-compiling (as we haven't found the
right way to do it). So let's not build the Goat Exercise plug-in in
Vala in such case as we needed the introspected libgimp.
Since meson 0.43.0 (below our current requirement), 'symbol_prefix'
argument of gnome.generate_gir() allows an ordered list. If I prepend
'gimp_ui', it makes any gimp_ui_*() function to not start with 'ui_'.
In particular, GimpUi.ui_init() becomes GimpUi.init() which is much less
redundant.
Jehan