… don't include it from public gimpui.h.
As reviewed during !786, if this file is private, the name should show it
clearly. And of course, we must not include it from another public header, since
it won't be installed.
This also fixes building plug-ins with gimptool as reported by tmanni:
e00f2d7f50 (note_1650791)
Nothing was really clearly specified until now, which was kinda equivalent to
the string being in the OS encoding as used by GLib. Since this string will
usually be statically hardcoded in code (and not extracted from system), it's
just much easier to request UTF-8 for this specific case.
On Windows fopen () is limited to the current codepage,
GLib's g_fopen () instead accepts full UTF-8 by calling
_wfopen () internally (or a similar wide-char CRT routine).
When the core sends a NULL resource, which would be the default for object args,
hence is also what you get for the first call of a plug-in with a resource
parameter, libgimp was creating a GimpResource with NULL id, which is invalid.
It is much better to return NULL (since we made it so that NULL is a valid
value) and let the plug-in handle the NULL value as it sees fit for a given
parameter (they could just set the contextual resource for this type, or keep
NULL to mean "no resource selected").
This fixes failing to run plug-ins the first time (before any "last" values are
set). E.g. I had the issue when testing palette-sort.
Also I'm improving the error message when trying to use a non-installed resource
(it will now also print the resource ID and the error message). And the GError
was leaking in this case, so I properly free it now.
… 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.
Jehan