- app: gimp_context_get_(foreground|background)() are now returning a GeglColor.
- libgimp: PDB functions named similarly in libgimp are returning a newly
allocated GeglColor too.
- A few other PDB functions (the ones using these functions) were updated and
their signature changed to use GeglColor too, when relevant. Plug-ins which
use any of the changed libgimp functions were fixed.
- GimpContext: signals "(foreground|background)-changed" are now passing a
GeglColor.
- libgimpconfig: new macro GIMP_CONFIG_PROP_COLOR using gegl_param_spec_color().
- GimpContext: properties "foreground" and "background" are now GeglParamColor
properties.
- app: All code interacting with GimpContext objects were updated to receive a
GeglColor (that they may still convert, or no, to GimpRGB for now).
- app: gimp_prop_gegl_color_button_new() was added as an alternative to
gimp_prop_color_button_new() when the property is a GeglParamColor. Eventually
the former should replace completely the latter.
- libgimpwidgets: gimp_prop_color_area_new() now works on GeglParamColor
properties only.
- libgimp: gimp_procedure_dialog_get_widget() will generate a GimpColorArea for
GeglTypeParamColor arguments.
Also the color is internally stored as GeglColor, though there are still get
APIs and signals using GimpRGB.
The equivalent PDB functions are also changed to use GeglColor, same as app/
functions.
This is a first commit to really getting rid of GimpRGB within core and
PDB/plug-in code. This will make color conversion reliability a lot better as
GeglColor will handle conversions for us. The goal is that we should keep origin
color space (for instance when picking colors in a GimpPickable, or when storing
in the FG/BG colors or in paletters) until the last second and convert at use
only.
It's still very much work-in-progress.
These 2 functions were removed in commit 89c359ce. They were in fact used and
clearly this historical API seems interesting (though we can likely do the same
thing using the drawable GeglBuffer, but this way is much easier).
This is now reimplemented using GeglColor instead of raw data.
Eventually this is meant to fully replace GimpRGB (as well as GimpHSV, GimpHSL
and GimpCMYK), both in libgimp and in core code, as part of both the space
invasion and the API rework. For this first commit, I keep this new object side
by side to GimpRGB.
This patch implements an initial form of
non-destructive editing. Filters now stay active
instead of being immediately merged down.
A new column is added to the layer tree view, which
can be clicked to show a pop-over menu.
Filters can currently be hidden/shown, edited, reordered,
deleted, and merged down from this pop-over menu.
Currently, this works on layers and layer selections only.
Plenty of room for improvement!
Resolves#10651
The "Remove All Guides" script calls
gimp-image-find-next-guide, which per
its description can take in 0. However,
the parameter sets 1 as the minimum
value.
This patch fixes the range so that it can
accept 0, which enables the Remove All
Guides script to work again.
It also updates the script to the new
multi-layer aware API.
Due to GObject Introspection we can't have the last part of an
identifier start with a digit, since that part will be used in Python
as the identifier, and Python doesn't allow that to start with a digit.
e.g. GIMP_ROTATE_90 would be used in Python as
image.rotate(Gimp.RotationType.90)
To fix this we add DEGREES in front of the number, without a '_',
even though that looks ugly.
Fixing:
> Scalar value @inargs[...] better written as $inargs[...] at pdb/lib.pl line 247.
> Scalar value @outargs[...] better written as $outargs[...] at pdb/lib.pl line 386.
Until now, it was not really possible to delete a colormap color, but since we
now use GimpPalette, people would definitely try to do so. It just makes sense
to allow doing this, but only if the color is unused.
Additionally when we do this, all the pixels refering to bigger indexes will be
edited so that they continue to refer to the same color (bigger indexes are
shifted by -1). Therefore removing an unused color does not change the image
render.
I wondered if we might want more options, e.g. the ability to delete a color
without fixing indexes (i.e. that colors over the deleted color index would
shift to the next color). This would even allow to delete used colors (though
now the last index would have to be unused one, unless we cycle colors).
Yet I don't think this should belong to this basic API. The most expected
behavior when deleting a color from an image colormap is to fix all indexes
stored in pixels so that the image still shows the same. So that's what this
function will do in this generic usage.
This is meant to replace gimp_image_get_colormap() (see also #9477).
We likely won't need a gimp_image_set_palette() because we can simply edit the
image's colormap/palette with GimpPalette API now and it is directly updated.
For instance, the following code changes the first entry in the image palette to
red, immediately:
```python
i = Gimp.list_images()[0]
p = i.get_palette()
c = Gimp.RGB()
c.r = 1.0
p.entry_set_color(0, c)
```
For this to work fine, I added a new concept to GimpData, which is that they can
be tied to a GimpImage (instead of a GFile). Image palettes are not considered
internals, they are just tied to their image, therefore they can be edited by
scripts/plug-ins.
Additionally with this commit, editing an image's colormap from libgimp API also
generates undo steps now.
It returns all the fonts (possibly more than 1) with a given name. I left the
function gimp_font_get_by_name() as a utility when one don't want to choose (or
is not able anyway, e.g. a script with minimal information), though I wondered
if we should not simplify with a single function (the new one, which is the
correct one now that it is possible to have several fonts with a given name).
It is easy to test with fonts named the same. For instance I could find 2
different fonts, both named 'Holiday'. This call in the Python console returns
both:
> Gimp.fonts_get_by_name('Holiday')
As part of this commit, I also implemented resource arrays (or subtype arrays)
as PDB arguments and return types.
… description.
- The returned value as width/height/etc. of the glyph extents (or bounding
box), not "of the font" (which doesn't mean much).
- Adding some definition for ascent and descent. This text is straight out
copied from Pango documentation comments in pango/pango-types.h.
- I don't see why we were negating the descent value. Let's keep the value sign
as defined in Pango.
- Fonctions were renamed: s/gimp_text_fontname/gimp_text_font/ and
s/gimp_text_get_extents_fontname/gimp_text_get_extents_font/
- The size_type arguments were removed. Even in 2.10, this argument was marked
as "dead" and ignored. It was only kept for API compatibility.
- The font name (string) was replaced by a GimpFont argument.
gimp_text_font() is easily tested in the Python console with:
> Gimp.text_font(Gimp.list_images()[0], None, 10, 40, "Hello World!", 1.0, True, 100, Gimp.context_get_font())
And gimp_text_get_extents_font() with:
> Gimp.text_get_extents_font("Hello World!", 100, Gimp.context_get_font())
This function is not perfect and in particular doesn't seem usable with binding
because of GimpUnit being some weird mix between an enum and some kind of class.
So this will have to be fixed too. See #8900.
… function gimp_font_get_pango_font_description().
Also updating file-pdf-save which is the only plug-in using these right now.
Note that I am not fully happy with the new function
gimp_font_get_pango_font_description() because I experienced some weird behavior
in file-pdf-save which is that some fonts were wrong if this is called after
pango_cairo_font_map_set_resolution().
But let's say this is a first step looking for improvements.
I am using the same GimpDrawableChooser with an additional drawable_type
argument to only show the appropriate tab if we want to limit what can be
chosen.
None of our plug-ins actually use a GimpLayer or GimpChannel only arg so far,
but if we have some day, or if some third-party plug-ins want to have such arg,
now they quite easily can!
This was not working properly and needed some external build script as well as
the stamp/bogus header trick like for other similar in-source generated code.
In the same time, I get rid of old meson code which was meant for when using
meson < 0.57.0 (since our requirement is now meson >= 0.59.0).
Similarly to the various GimpResource select PDB calls, this allows to call a
core dialog in order to choose a drawable which will be returned back to the
calling plug-in.
This new GimpPickableSelect dialog is a subclass of GimpPdbDialog and uses the
same GimpPickableChooser widget as GimpPickablePopup, except that since it's
inter-process window management, it is harder to make a popup positioned
accurately relatively to a parent (especially on Wayland). This is why it's a
separate widget as a simpler dialog (which we will still try to make transient
as much as possible across platforms).
Similar to the latest commits for GimpBrush:
- gimp_pattern_get_buffer() returns a GeglBuffer and allow getting a scaled
version of the pattern.
- Old gimp_pattern_get_pixels() is made private.
- Moved GimpPattern into its own file and store the buffer to avoid re-querying
it through PDB continuously.
No as for the widget to select a pattern:
- Preview frame ensured to be square.
- Default size increased.
- Drawing code using the new gimp_pattern_get_buffer().
- Cleaned up code.
… and gimp_brush_get_mask().
gimp_brush_get_pixels() was a bit crappy, returning raw data with only
dimensions and bpp to go with (no color model/space, no bit depth…). So the
assumption is that we work with 8-bit per channel data, possibly with alpha
depending of number of channels as deduced from bpp, and very likely in sRGB
color space. It might be globally ok with many of the brush formats (and
historical brushes) but won't fare well as we improve brush capabilities.
- gimp_brush_get_pixels() is in fact made private.
- The 2 new functions are using this old PDB call _gimp_brush_get_pixels() to
construct buffers. This has some limitations, in particular that it returns
only 8-bit per channel sRGB data, but at least the signature won't change when
we will improve things in the future (so if some day, we pass fancy brushes in
high-bit depth, the method will stay the same).
- This new implementation also allows scaling down the brush (keeping aspect
ratio) which is useful when you need to fit a brush preview into a drawing
widget.
- Current implementation stores the buffers at native size in the libgimp's
GimpBrush object, hence save re-querying the core every time you need an
update. This can be improved as current implementation also means that you
don't get updates if the brush changed. This should handle most common use
cases for now, though.
- Also with this change, I move GimpBrush class implementation into its own
dedicated file.
Brush, font, gradient, palette and pattern choices are currently chosen through
a dialog created by the core, which then returns the user choice to the calling
plug-in. This has the unfortunate consequence of having a pile of likely at
least 3 windows (main GIMP window by core process, plug-in window by plug-in
process, then the choice popup by the core process) shared in 2 processes, which
often end up under each other and that's messy. Even more as the choice popup is
kinda expected to be like a sub-part of the plug-in dialog.
So anyway, now the plug-in can send its window handle to the core so that the
resource choice dialog ends up always above the plug-in dialog.
Of course, it will always work only on platforms where we have working
inter-process transient support.
Having windows ID as guint32 is a mistake. Different systems have
different protocols. In Wayland in particular, Windows handles are
exchanged as strings. What this commit does is the following:
In core:
- get_window_id() virtual function in core GimpProgress is changed to
return a GBytes, as a generic "data" to represent a window differently
on different systems.
- All implementations of get_window_id() in various classes implementing
this interface are updated accordingly:
* GimpSubProgress
* GimpDisplay returns the handle of its shell.
* GimpDisplayShell now creates its window handle at construction with
libgimpwidget's gimp_widget_set_native_handle() and simply return
this handle every time it's requested.
* GimpFileDialog also creates its window handle at construction with
gimp_widget_set_native_handle().
- gimp_window_set_transient_for() in core is changed to take a
GimpProgress as argument (instead of a guint32 ID), requests and
process the ID itself, according to the running platform. In
particular, the following were improved:
* Unlike old code, it will work even if the window is not visible yet.
In such a case, the function simply adds a signal handler to set
transient at mapping. It makes it easier to use it at construction
in a reliable way.
* It now works for Wayland too, additionally to X11.
- GimpPdbProgress now exchanges a GBytes too with the command
GIMP_PROGRESS_COMMAND_GET_WINDOW.
- display_get_window_id() in gimp-gui.h also returns a GBytes now.
PDB/libgimp:
- gimp_display_get_window_handle() and gimp_progress_get_window_handle()
now return a GBytes to represent a window handle in an opaque way
(depending on the running platform).
In libgimp:
- GimpProgress's get_window() virtual function changed to return a
GBytes and renamed get_window_handle().
- In particular GimpProgressBar is the only implementation of
get_window_handle(). It creates its handle at object construction with
libgimpwidget's gimp_widget_set_native_handle() and the virtual
method's implementation simply returns the GBytes.
In libgimpUi:
- gimp_ui_get_display_window() and gimp_ui_get_progress_window() were
removed. We should not assume anymore that it is possible to create a
GdkWindow to be used. For instance this is not possible with Wayland
which has its own way to set a window transient with a string handle.
- gimp_window_set_transient_for_display() and
gimp_window_set_transient() now use an internal implementation similar
to core gimp_window_set_transient_for(), with the same improvements
(works even at construction when the window is not visible yet + works
for Wayland too).
In libgimpwidgets:
- New gimp_widget_set_native_handle() is a helper function used both in
core and libgimp* libraries for widgets which we want to be usable as
possible parents. It takes care of getting the relevant window handle
(depending on the running platform) and stores it in a given pointer,
either immediately or after a callback once the widget is mapped. So
it can be used at construction. Also it sets a handle for X11 or
Wayland.
In plug-ins:
- Screenshot uses the new gimp_progress_get_window_handle() directly now
in its X11 code path and creates out of it a GdkWindows itself with
gdk_x11_window_foreign_new_for_display().
Our inter-process transient implementation only worked for X11, and with
this commit, it works for Wayland too.
There is code for Windows but it is currently disabled as it apparently
hangs (there is a comment in-code which links to this old report:
https://bugzilla.gnome.org/show_bug.cgi?id=359538). NikcDC tested
yesterday with re-enabling the code and said they experienced a freeze.
;-(
Finally there is no infrastructure yet to make this work on macOS and
apparently there is no implementation of window handle in GDK for macOS
that I could find. I'm not sure if macOS doesn't have this concept of
setting transient on another processus's window or GDK is simply lacking
the implementation.
In GimpText, The font used to be stored as a string containing its name,
Now, it is stored as a GimpFont object, which makes more sense and makes
operations on fonts easier (such as serialization).
This finds the core resource knowing its type, name, collection and internal
state (in other words, the values returned by _gimp_resource_get_identifiers()).
Rather than reimplementing the same checks for every possible resource data
type, just do it once and redirect to the correct factory container.
For the libgimp API, we leave per-type functions `gimp_*_get_by_name()` (where *
can be brush|gradient|font|palette|pattern so far), but internally they all use
gimp_pdb_get_resource().
Note that eventually we want these functions to return a list of resources as it
should be possible to have several resources of a given type with the same name
(since they are made by third-party who might have had the same idea of a name).
Resources are stored by the plug-in infrastructure and their memory should not
be managed by plug-in code.
My commit 4f69995b46 was crappy and modified a generated function. I was just
too tired with all the heat in here, I guess!
Brushes can't be large enough to actually cause overflow here, but
since the result is gsize, it can't hurt to have the intermediate
results to gsize too.
It looks like we left out the multiplication by 3 when passing the
colormap size to get to the number of bytes in commit 89c359ce
This fixes a crash when saving an XPM file
Fixes: https://gitlab.gnome.org/GNOME/gimp/-/issues/9711
Partially resolves#7211.
plug-in-ripple is a wrapper for the GEGL ripple effect. GEGL allows for
double values for period and amplitude, while the GIMP PDB only allows
integers. This patch aligns the datatypes.
Note that Angle and Phi are still limited to the current design.
As @bootchk noted, gimp-file-load-layers does not check the result of
file_open_layers () but the final return variable
which is always NULL at this point in the function.
This patch corrects the problem so it checks the proper variable.
Much like for images and items. Change the PDB to transmit IDs
instead of names for brush, pattern etc. and refactor a whole
lot of libgimp code to deal with it.
modified: libgimp/gimpplugin-private.h
GLib has a specific type for byte arrays: `GBytes` (and it's underlying
GType `G_TYPE_BYTES`).
By using this type, we can avoid having a `GimpUint8Array` which is a
bit cumbersome to use for both the C API, as well as bindings. By using
`GBytes`, we allow other languages to pass on byte arrays 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 byte 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
- gimp_image_add_sample_point: guide is a left-over from copy-pasting and
add apostrophe
- gimp_image_get_sample_point_position: it was not clear that the
parameter was the y-offset and the return value the x-offset
- fix a typo s/Commponent/Component/.
- Add &std_pdb_compat() to the new PDB procedures (I realize that's probably
what the contributor was asking about, back in !446). Not sure if it's right
as there were none in this file, but these are clearly just wrappers around
GEGL ops, so it seems fitting.
- Some alignment fixes.
- More accurate "$since" variables.
(cherry picked from commit 66ef1ef1ef)
(cherry picked from commit dbf9f277a2)
Committer's (Jehan) updates:
- Component type is now int32 (int8 is not a PDB type available anymore).
- PDB files re-generated to handle changes in API and types.
This is not made to set the imported or exported file, but only the XCF file.
See previous commit to see what happens when this API is used to set non-XCF
file extensions (saving fails unless one edits the filename).
This commit is a fixup commit for MR !790 which had a few issues:
- The args for shadows and highlights adjustments are "shadows-ccorrect" and
"highlights-ccorrect" respectively.
- Also fixing generated code.
(cherry picked from commit e456ab019b)
… 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.
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
When the clipboard contains raw image data or single layers, it's the same as
the normal "Paste" (and "Paste In Place" respectively). These actions are useful
if you want to copy a bunch of layers and paste them "merged" into a single
layers (since now the copy-paste of multiple layers will create multiple
layers).
It is somehow similar to the "Copy Visible" action except that it works on
selected layers only and work at paste time, making the action more versatile.
When several drawables were selected, it was pasting at the top of the layer
stack. Instead, paste over the top selected layer ("top" visually in the Layers
dockable).
There was the question of: what should we do when pasting over a layer group.
Should we consistently paste the new layers above the group or inside the group?
After discussions with Aryeom, we decided to stay consistent and paste above, at
least for now.
It seems I forgot to fix some usage of core gimp_vectors_export*(),
which now take a list of paths (not a single path anymore since commit
9fc8260c7c), as these were used by PDB functions.
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.
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.
Meson is apparently able to show different warning depending on the
meson version tests we do in specific code paths.
Since our global required meson is 0.53.0 but on some code paths, we
test for 0.57.0, we must use meson.source_root() on older meson and
meson.project_source_root() on newer one.
Fixes:
> pdb/meson.build:141: WARNING: Project targets '>=0.57.0' but uses feature deprecated since '0.56.0': meson.source_root. use meson.project_source_root() or meson.global_source_root() instead.
> pdb/meson.build:141: WARNING: Project targets '>=0.57.0' but uses feature deprecated since '0.56.0': meson.build_root. use meson.project_build_root() or meson.global_build_root() instead.
> po-tips/meson.build:5: WARNING: Project targets '>=0.53.0' but uses feature introduced in '0.56.0': meson.project_source_root.
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.
gimp_procedure_set_static_help().
The indentation was wrong, probably because of changes to function
names. Fix the generation scripts and regenerate the PDB C files.
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.
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.
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
This was introducted in commit 65eff6f150, i.e. together with the
initial port. I have no idea why this is here and if it is about the
stamp-pdbgen, why would we want to remove it. The PDB is a major piece
of our codebase and the simplicity to generate new PDB procedures is a
core feature.
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
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
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.
The `env` option is new (from meson 0.57.0), yet we depend on meson
0.50.0 and bumping the meson requirement is not a possibility (we have
bad experience when we did this for babl).
Instead, implement the new option usage and a workaround which would
work also with older meson.
I could have implemented only the workaround, but it's also nice to
write down the better syntax so that when we actually bump meson
requirement, getting rid of the workaround will just be a matter of
hitting delete and done. Though it also means we must keep both if/else
blocks in sync, so it has its drawbacks.
See the discussion in !506.
Jehan