MINGW64
- uses 0x601 as value for _WIN32_WINNT. No need for us to define
it to that value or even lower values in some places.
This also gets rid of: warning: "_WIN32_WINNT" redefined
- has 0x0502 for WINVER, so get rid of us setting it to 0x0500 in
gimp-app-test-utils.h. It also seems that the need to use G_OS_WIN32
has disappeared here.
- DIRECTINPUT_VERSION is 0x0800, no need for us to set it to that value.
- AI_ADDRCONFIG was apparently missing from the MINGW headers in the
past, but not anymore.
This explains such WARNING over a previous installation on Windows:
> (gimp-2.99.exe:11524): GLib-GObject-WARNING **: 21:36:36.664: Two different plugins tried to register 'ControllerDXDInput'.
The previous install was autotools-built, so it didn't have the typo.
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.
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.
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.
Jacob Boerema