The way we were creating a GimpData identifier was simply wrong, because it was
based on the assumption that the source file uniquely identifies a GimpData (cf.
gimp_tagged_get_identifier() which clearly says that the returned string must
uniquely identify this data). The very simple counter-examples for why this is
a mistake to consider a data file to be a good unique identifier are collection
files. For instance, TTC files (TrueType Collection) contain multiple fonts.
Instead I am adding the concept of "collection" with the assumption that
**within a given collection**, data names are unique (I do hope this to be and
stay true). So I add gimp_data_get_identifiers() and gimp_data_identify() to get
identifiers and check for identity.
The collection will use the old implementation of gimp_data_get_identifier()
because it is quite nice to have paths relative to data and config directories
(it allows some cases of data relocation without losing data identification).
The new implementation to compute a GimpTagged identifier on the other hand will
construct a string from the quality of being internal or not, the data name and
its collection.
Note that there is a `container_obsolete` too in GimpDataFactory and I don't
apply the "unique-name" property to it because I'm unsure what it is.
Furthermore, eventually we'll want all types of data to allow duplicate names
(brushes, patterns or whatnot may come from all sources and may be named the
same by different people). But for now, let's focus on fonts before breaking
other parts of the codebase which we might not look into right now.
Remap font names to unique generated names
so that pango sees them.
keep the font name for display and the internal
name for everything else.
* Fonts are still broken When exporting to pdf
* Not sure if xcf files would be usable on other systems
maybe use hash of psname internally instead
* Not sure if plug-ins using text layer work correctly
(do they use internal font name or the actual name?)
This is definitely not core type material. Also it's much better in the proper
header gimpimage-snap.h and the type name should reflect the file namespace,
especially as we make it public.
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
