This allows us to simplify some of the logic, and get rid of a
`gdk_seat_grab()` which might trigger unwanted popups. It's also a bit
more future-proof, as it uses the same mechanism to what is used in
GTK4 for event handling.
While we're at it, stop storing a separate `priv` pointer, which would
allow us to use `G_DECLARE_FINAL_TYPE()` in the future.
Renaming the temporary function gimp_scale_entry_new2() into
gimp_scale_entry_new() now that the original code is entirely gone. This
is now a fully-fledged widget with a nice and proper introspectable API.
The GIR parser is giving warnings because both e.g. a signal, a
corresponding vfunc and a method emitting it are named
"channel_changed", which can and will give issues in some bindings.
The easiest option is to follow the general convention of starting the
signal emitters with `emit_`, which also makes clear the intention of
the method.
* Don't generate our own marshallers if they are available in GLib
already
* Don't set the c_marshaller parameter in `g_signal_new()` if it's a
default marshaller provided by GLib. See commit message of commit
39e4aa3c57 on why this is the case.
which means that it's now included normally via gimpbase.h
and not any longer via gimpbasetypes.h which we only did out
of lazyness. A *lot* of files in libgimp* and app/ now need to
... and G_TYPE_INSTANCE_GET_PRIVATE()
g_type_class_add_private() and G_TYPE_INSTANCE_GET_PRIVATE() were
deprecated in GLib 2.58. Instead, use
G_DEFINE_[ABSTRACT_]TYPE_WITH_PRIVATE(), and
G_ADD_PRIVATE[_DYNAMIC](), and the implictly-defined
foo_get_instance_private() functions, all of which are available in
the GLib versions we depend on.
This commit only covers types registered using one of the
G_DEFINE_FOO() macros (i.e., most types), but not types with a
custom registration function, of which we still have a few -- GLib
currently only provides a (non-deprecated) public API for adding a
private struct using the G_DEFINE_FOO() macros.
Note that this commit was 99% auto-generated (because I'm not
*that* crazy :), so if there are any style mismatches... we'll have
to live with them for now.
Even though the ACES RRT is a filmic mapping, and the current code is only an
approximation of the luminance aspects (ignoring saturation and hue sweeteners)
the intent of this display filter will be to implement a non-LUT based close to
standard conformant parametric ACES RRT in C for use in ACES workflows.
Add a display filter that can be used in scene-referred imaging workflows,
this is using a luminance-only approximation of the ACES filmic HDR to SDR
proofing mapping - see link in source comment for details.
- remove redundant frames, 3d-frames are gone anyway, so no need to
keep double out/in frames around
- give all color selector classes CSS names
- add/fix some theme CSS styles
With the new propgui UI, the property nick is used as the combo's
label; since the descriptions of the corresponding enum values are
quite long, using "deficiency" as a label for the prop is
problematics, especially for some translations.
Change the property name and nick to "type", and align the code
with the change.
Also, change the property's blurb from "color deficiency type" to
"color vision deficiency type".
Replace "Show NaN" option with "Show bogus". Bogus values include
infinities, in addition to NaN.
Don't blend the bogus warning color with other warning colors, when
a pixel has both a bogus component, and a shadow/highlight
component. The bogus warning always takes precedence.
Rename "Include alpha" option to "Include alpha component".
Remove "Opaque" option. Warnings are now always opaue, even for
non-opaque pixels.
Add "Include transparent pixels" option, which controls whether
fully-transparent pixels are included in the warning. A fully
transparent pixel is a pixel whose alpha component is less-than or
equal-to zero (note that this doesn't include a NaN alpha
component.)
The labels used in the old display filters ui were more descriptive
than the corresponding property nicks; modify the nicks/blurbs with
similar text.
... Plus random cleanup in clip-warning.
Try to sort all GIMP_ICON_* defines into FDO categories like in
https://specifications.freedesktop.org/icon-naming-spec/latest/ar01s04.html
Add defines for all icons we override, rename some icons to their FDO
standard names, and mark the ones we duplicate with a comment so we
don't forget to rename those to standard names in 3.0.
Remove all stock items added since 2.8, restore accidentially removed
ones, and rename the newly added GIMP_STOCK_* defines to GIMP_ICON_*.
(will move to having GIMP_ICON_* defines instead of magic hardcoded
strings for all icons).
and use gimp_file_new_for_config_path() and _get_config_path() when
dealing with them. We used a weird mix of config paths and plain
(filesystem encoded) paths, waiting to to break on umlauts or
whatever. The code in gimpcolorconfig.c was particularly bad.
to gimp_color_config_get_simulation_color_profile(), along with
various internal "printer" strings. Also reduce the number of
user-visible "print" stuff from the preferences color management page.
Jehan