We had the following warning:
In function 'make_remap_table',
inlined from 'gimp_image_convert_indexed' at
../../gimp/app/core/gimpimage-convert-indexed.c:1057:7:
D:/msys64/mingw64/include/glib-2.0/glib/gmem.h:261:19: warning: argument 1
range [18446744071562067968, 18446744073709551615] exceeds maximum object
size 9223372036854775807 [-Walloc-size-larger-than=]
This is apparently caused by inlining in combination with using a signed
int.
See also: https://gcc.gnu.org/bugzilla//show_bug.cgi?id=85783
Casting to (guint) silences the warning here.
Resolves issue with #8461.
This provides a conditional value for the fill options to only show
a color and pattern, rather than fore/background colors.
Currently only used for the text editor.
Since MR !706, (style solid) doesn't exist anymore which makes gimprc parsing
fails (hence losing configuration).
This fixes:
> Gimp-Config-Message: 21:20:21.018: Error while parsing '/home/jehan/.config/GIMP/2.99/gimprc' in line 18: invalid value 'solid' for token style
> Gimp-Config-Message: 21:20:21.018: There was an error parsing your 'gimprc' file. Default values will be used. A backup of your configuration has been created at '/home/jehan/.config/GIMP/2.99/gimprc~'.
Replaces "Solid Colors" option in Fill Path with Foreground/Background
Colors options. This allows users to fill with either, rather than
having to switch the foreground color each time.
GIMP_CONTEXT_PROP_MASK_BACKGROUND was added to the fill and stroke
contexts to allow the background color to be recognized.
In places where Solid Color was used as a default, Foreground Color is
now used instead.
It does absolutely nothing except sitting there, providing an is-a
relation (both ways because GimpData is its only subclass). This will
simplify having more libgimp API on GimpResource, without having to
add different PDB code for app and libgimp.
This replaces the various GimpHSV/GimpCMYK .aco palette conversions with
Babl.
As a result, it now possible to support importing CIE Lab palettes
(colorspace 7)
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
Currently, patterns are loaded as-is - if the full pattern is larger
than the preview, its cut off and you only see the left corner.
In those cases, the pattern is scaled using gegl_buffer_get ()'s scale
parameter.
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
This commit converts `GimpModuleDB` into a `GListModel`. This allows us
to drop quite a bit of custom code to have an adaptive list of modules
by just becoming a `GListModel` implementation.
Next to that, this commit also rewrites `GimpModule` to use the `notify`
signal for its 2 new properties: "auto-load" and "on-disk", rather than
trying to define a custom signal for that. This in turn allows us to use
basic methods like `g_object_bind_property()`.
Finally, the module manager dialog now uses `GtkListBox`, which can
easily bind to that new `GListModel` infrastructure.
Replaces GimpPickableInterface's pixel_to_srgb () functions with
pixel_to_rgb(). Now GimpRGB's values should be in the correct
image color space from the beginning of the process.
This fixes:
> app/core/gimpitemlist.c:632:7: warning: ‘g_pattern_match_string’ is deprecated: Use 'g_pattern_spec_match_string' instead [-Wdeprecated-declarations]
The new function appeared in GLib 2.70 which is our current minimum GLib
requirement, so the replacement is fine.
Since we now generate actions for GEGL ops, we might as well generate menu items
for these too.
What I did:
- Move the "GEGL Operation…" tool (generic dialog with a drop-down list of all
non-ignored GEGL ops) to Tools menu.
- Create a "GEGL Operations" submenu in Filters > Generic.
- Move "GEGL Graph" to the top of this new submenu.
- Generate a new menu item for each generated action tied to a GEGL plug-in,
alphabetically sorted.
Also get rid of various old references to menurc and don't install it anymore to
etc/ (neither the new shortcutsrc as it doesn't look like it brings much value
to do so).
Right now, our actions are added both in the GActionMap (a.k.a. as
GApplication|GtkApplication) and with the old GtkActionGroup API. The later code
is meant to be removed soon.
A major difference with the old implementation is that we don't add the actions
in separate action groups. Even though GLib has a GActionGroup concept, these
don't seem to be used at all when adding actions on the GtkApplication level.
It might mean that eventually we will even remove the GimpActionGroup code and
move everything up one level.
Of course, I am still evaluating if we really want an action group concept, in
which case, we could simply recreate it, but I'm actually unsure how useful it
is. The only place where I see a use to this is in the shortcut settings (to
organize actions by groups), but even there, it was rarely useful to me. I
usually rather search for actions by text search anyway.
GIMP expects CSS palettes to end with a ";" when importing. However,
GIMP exports CSS lines without ";". This means GIMP can't reopen its
own exported CSS palettes.
The ";" was removed from the regex since CSS2 does not require
the last line to end with a ";". However, CSS3 and above
require ending all lines with a ";", so it is added to the
export script.
gimp_display_shell_render() writes to a GeglBuffer backed by allocated memory
(shell->profile_data). Unfortunately while converting prevision in
gimp_image_convert_precision(), we change the "precision" property (hence the
source format) first, hence end up trying to write data in a too small buffer.
This crash was hard to find as it was not showing up on my machine (though it
did produce rendering artifacts!), unless I built both GIMP and babl with
`b_sanitize=address`.
Note that an alternate fix was to make sure that the profile_data buffer is big
enough (by calling gimp_display_shell_profile_update() before rendering), but
anyway the image is in an inconsistent state while conversion is in progress:
whereas the `src_format` is the new one, the `src_profile` is still the old one
(and cannot be changed before we finish converting).
Moreover the render happen regularly on progress signals, once after each
converted drawable. So each of these rendering step happens in an inconsistent
state, with the wrong profile set, some of the drawables converted and others
not yet.
We could still render properly if each drawable's buffer used space-aware format
(thus allowing different drawables to use different profiles/spaces), but it
feels over-engineering the problem. It might be much better to ignore rendering
steps while converting the image precision. Moreover it would obviously make a
faster conversion.
See discussions in #9136 for this crash, which didn't have dedicated report
AFAIK.
(cherry picked from commit de25be9210)
Note: on the `master` branch, even with sanitized code, I don't get the crash.
Yet this change seems relevant enough that I'm adding it.
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
These are not used anymore anywhere in our codebase! I'm sure some issues still
exist in various places, yet we can now consider that the multi-item awareness
project is finally over! Wouhou! 🥳
One big question which remains is whether I want to get back to the old naming
of "active" items, rather than "selected" items. The main reason to change the
wording globally was to be able to easily find remnants of non-multi-item aware
code. Now that it's all gone, I could very simply revert to the old naming.
This is in particular a big question for the public API for plug-ins, as the
"active" wording has been used for decades litterally. The only difference now
with how it used to be is that we could have several active items at once.
This is because gimp_drawable_edit_clear() would also clear the full drawable in
the special case when there is no selection at all. So as we were inverting the
"all" selection, we were ending up in this special-case.
This second GIMP_IS_ITEM() test was obviously for the iter2->data item. This
fixes handling cases when aligning/distributing a mix of GimpItem-s and guides.
I'm not sure if there are a lot of cases where we might want to use the layer
extents for items to align while using the contents extents for the reference
(or the other way around). It looks to me you either want one of the other for
all the items in the most common case.
So for now, let's apply this option to both the items to align and the reference
item. We'll see if anyone wants a separate option some day and has a good use
case to submit for this.
Trying to arranging both doesn't make sense and only end up in weird result. If
both the parent (layer group) and one or several child items are selected, just
arrange the parent.
These are typically debug outputs and we don't want them to appear on stderr of
release builds. They confuse people (some tester would report these on IRC when
we last release GIMP 2.99.14).
So let's not show these debug text on release versions.
