- Fix annotations for gimp_export_options_get_image() to make it
actually introspectable with the GimpImage being both input and
output. Even though the logic doesn't change much (the input image may
be overriden or not), it doesn't matter for introspection because
images are handled centrally by libgimp and therefore must not be
freed. Actually deleting the image from the central list of images
though remains a manual action depending on code logic, not some
automatic action to be handled by binding engines.
- Add G_GNUC_WARN_UNUSED_RESULT to gimp_export_options_get_image()
because ignoring the returned value is rarely a good idea (as you
usually want to delete the image).
- Remove gimp_export_options_new(): we don't need this constructor
because at this point, the best is to tell plug-in developers to just
pass NULL everywhere. This leaves us free to create a more useful
default constructor if needed, in the future. Main description for
GimpExportOptions has also been updated to say this.
- Add a data_destroy callback for the user data passed in
gimp_export_procedure_set_capabilities().
- Fixing annotations of 'export_options' object from pdb/pdb.pl: input
args would actually be (nullable) and would not transfer ownership
(calling code must still free the object). Return value's ownership on
the other hand is fully transfered.
- Add C and Python unit testing for GimpExportOptions and
gimp_export_options_get_image() in particular.
- Fix or improve various details.
Note that I have also considered for a long time changing the signature
of gimp_export_options_get_image() to return a boolean indicating
whether `image` had been replaced (hence needed deletion) or not. This
also meant getting rid of the GimpExportReturn enum. Right now it would
work because there are no third case, but I was considering the future
possibility that for instance we got some impossible conversion for some
future capability. I'm not sure it would ever happen; and for sure, this
is not desirable because it implies an export failure a bit late in the
workflow. But just in case, let's keep the enum return value. It does
not even make the using code that much more complicated (well just a
value comparison instead of a simple boolean test).
This patch creates a GimpExportOptions class in both
libgimpbase and in libgimp. Currently it is a mostly empty
object, but it will be added to after 3.0 to allow for
additional export options (like resizing on export while
leaving the original image intact)
libgimp/gimpexport.c was removed, and most of its content
was copied into libgimp/gimpexportoptions.c. gimp_export_image ()
was replaced with gimp_export_options_get_image () in all
export plug-ins.
GimpExportProcedure has a new function to set the default
image capabilities for each plug-in on creation. It also sets up
a new callback function, which allows the options to respond to
user setting changes (such as toggling 'Save as Animation' in the
GIF or WEBP Plug-in).
This is a followup of previous commit. As well diagnosed by Anders, this
value relies on "gegl:gaussian-blur" operation's argument's range.
Also adding a comment to make it easier for future developers seeing
this value.
gimp-buffer-get-image-type returns the output of
gimp_babl_format_get_image_type (), which itself returns
a GimpImageType enum. However, the PDB claims that
it's a GimpImageBaseType enum instead. This patch fixes
the documentation to match the actual output enum type.
gimp_cairo_set_source_rgb () and
gimp_cairo_set_source_rgba () are no longer
used in the code base, so let's remove them
as part of the move to GeglColor.
Liam was hitting Backspace on "histogram" which is an action section and
would likely not return a proper GimpAction through
gimp_action_view_get_accel_action().
Therefore let's make sure we initialize properly the action to NULL.
The submenu labels for tool-options-popup were
hardcoded as English in GimpToolOptionsEditor's calls
to the Save, Restore, and Delete Tool Presets buttons.
This meant that these menus always fail when called in
non-English UIs, since we compare the path name and
submenu labels to only load the correct submenu items.
This patch attaches the English labels to the submenu
object so that we can retrieve it for comparison in
gimp_menu_model_get_submodel ().
This reverts commit f7e7f396aa.
See issue #8269.
For GIMP 2.10, I'll just revert this commit so that we get back to pre-2.10.32
situation. ~~For 3.0, we'll try to do something better.~~
-> Let's delay improving the situation even for GIMP 3.0, in which case
it's better to at least keep the same render as for the 2.10 series and
avoid confusion. I'll take more time after release to study better the
situation and see what we should actually do.
(cherry picked from commit 2fd738bb3e)
to stop for instance
When using the scale tool and the layer has a selection, then after
finishing the scaling we get a critical in the terminal like this:
(gimp-2.99.exe:31824): GLib-GObject-CRITICAL **: 18:22:05.689:
../glib-2.80.2/gobject/gsignal.c:1184: no emission of signal
"tool-changed" to stop for instance '000002e8a0f91df0'
This commit moves the call to `g_signal_stop_emission_by_name` inside
the if active_tool != tool_type.
gimp_item_mask_bounds() does not actually return if there is intersected
contents between the item and the image's selection, but whether there
is a selection. So when it returns FALSE, it will also return the full
item's dimensions.
'matrix' would save a lot of code and facilitate maintenance but,
according to my tests in a branch that I already deleted, this
doesn't work for our needs considering GitLab CI limitations.
This patch resizes the selection mode
icons based on the user's icon size
settings. It creates a new function in
gimpenumwidgets.c to update sizes,
then connects to GimpGuiConfig's icon
size update notifications in GimpSelectionOptions.
This is the only "language" from the list whose name is special and
should be localized at runtime, yet before we set any Preferences
language. It needs to be localized as the System Language itself which
will be run-dependant.
For instance, if your system is in French, it will be displayed as
"Langue système" but if you change your system to Korean, at next run,
it would show "시스템 언어". It is a per-run localization, independant
from the language selected in Preferences, and even less dependant from
build-time system language.
As reported by pippin, when gimp-data submodule is not initialized,
meson configuration fails with:
> meson.build:1830:0: ERROR: Nonexistent build file 'gimp-data/meson.build'
This does not give a lot of info, and while the solution can also be
found in INSTALL.in (INSTALL in tarballs) and on developer website, it's
nicer if the build itself could give a clearer information.
Now it will say instead:
> ERROR: Problem encountered: gimp-data submodule not present. Run: git submodule update --init
… found at build-time.
It was working on a machine with default paths and system-installed
packages (e.g. a typical Linux distributions) but needs to be manually
set up e.g. on Windows.
In particular, we don't want the build to succeed when various obvious
issues occur, which may even end up in a successful-looking build (yet
with no proper language lists), like we had in !1597.
Note that we still need the iso_639.mo files at runtime. Only the XML
files don't need to be parsed anymore at runtime (they are parsed at
build-time now).
Unlike the GimpTranslationStore which can use a list of pre-localized
languages (each language in its own name), the GimpLanguageStore must be
displayed in the currently used locale.
Our GimpTranslationStore contains self-localized names of all languages
we support.
As for GimpLanguageStore, it contains all known languages with their
name in the current locale. When moving to ISO 639-3 list, we had all
possible language, included ancient ones, extinct ones, and so on. With
the iso-codes installation on my machine, this meant a struct with 7910
languages! When showing the Text tool options for the first time, GIMP's
UI is frozen for a few seconds because of this, while it constructs the
GimpLanguageEntry making use of the GimpLanguageStore.
By only listing part 1 and part 2 languages (as well as the rare
languages which are not in these list yet which we still support, i.e.
right now only 'ckb' (Central Kurdish), see #11626), the list lowers to
189 languages, which is still good and are the main languages or
language families AFAIU. And now the Text tool options are constructed
instantly.
Note that this is in fact even less than when we were just using
iso_639.xml (I counted 487 languages stored there), but I believe it to
be enough for the usage we have in the Text tool.
Instead of always parsing the ISO-639 listing at each and every startup,
let's just generate the list of languages, their English name, and the
self-localized names as static struct.
This will just be much faster, and no worrying on the size of the XML
(or json) to parse.
Martin