Since we don't necessarily re-render the color area when the color
change, let's store the actually rendered color, additionally to the
supposedly rendered color. Otherwise when changing the color by very
small increments, small enough that the color is always perceptually
identical to the previous color, we never re-render the widget, even
when the rendered color is now quite different. Indeed the "identical
color" algorithm, based on CIE2000 distance, is not transitive.
Additionally I do not check for perceptual identity in
GimpColorSelection anymore, because we also check for this in the
GimpColorArea. Better always having the right color set in the area.
This was raised in #11339 (even though the initial issue was about the
hexadecimal field).
This is the recommended fix from Gtk to use our own mime type rather than depend on a mimetype
that has a different expectation of payload.
This means drag and drop of colors uses `application/x-geglcolor` rather than `application/x-color` which expects an RGBA color rather than a structure.
Always update stored colors. When colors are perceptually identical, we
only bypass color rendering code, but not the color value update (even
small value updates need to be echoed across the code, so that what is
shown is always what is set).
This is meant to obsolete GeglParamColor with at least an additional argument
has_alpha which we need in GIMP. It allows to advertize when a parameter wants
an opaque color, which in particular means we know when displaying a GUI to pick
colors with alpha or not.
Resolves#11146
As Idriss Fekir and I noted, 5ce128a9 added support for
receiving GeglColor data to GimpColorAreas, but
retrieving it still resulted in RGBA application/x-color
values being stored when dragged.
This patch updates gimp_color_area_drag_data_get () to
give the format and profile information along with the
pixel values.
This includes improvements on the out-of-gamut colored corner being shown for
unbounded component types out of the [0; 1] range (with some small margin of
error to avoid e.g. a -0.0000001 value to show as out-of-gamut).
There are still improvements to be made on the color rendering. In particular,
it still draws as CAIRO_FORMAT_RGB24 cairo surface. We should probably move to
draw as CAIRO_FORMAT_RGBA128F eventually (more precision and even allowing to
draw unbounded colors with a possible option, instead of always clipping).
Also adding the libgimpwidgets API gimp_widget_get_render_space().
- New function gimp_cairo_set_source_color() which is meant to replace
gimp_cairo_set_source_rgb(a?)() eventually. This new function sets the Cairo
source color, using the target monitor's profile of the widget where the Cairo
surface is meant to be drawn on. It also uses the color management settings
(such as whether a custom profile was set, instead of using system profile, or
also simply whether color management was disabled at all). It doesn't
soft-proof the color yet.
- Padding and out-of-gamut colors drawing now use the new
gimp_cairo_set_source_color(). These don't need any soft-proofing anyway.
- Out-of-gamut color property in GimpColorConfig is now a GeglColor property.
We use US English which uses behavior. So we replace all occurrences of
behaviour.
Most notable is File Open behavior in preferences. Besides that several
mentions in function documentation and a few in comments.
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.
I tried to have a not too overwhelming API, so we just ask for the label
and initial color at construction. We keep sane defaults for the rest
and let people tweak the result by getting the color area widgets
themselves (if they need to force-showing flat colors or change the drag
buttons in particular).
Another thing I wondered about was the initial size of the color area.
Without a size request or being in some container expanding its
children (which may also be ugly), it ends up too small. I can imagine
such widget being used especially when you want to display several
color rectangles next to each other with a label each. So I just set it
this way. Anyone is free to request a resize after constructing the
object.
Last but not least, the position of the label was especially of interest
here. For my idea of a list of colors, I could definitely imagine color
blocks aligned with vertically-oriented labels above or below. It might
be worth adding an API for this later on.
This would allow to enable, configure or disable drag ability of a
GimpColorArea ater its creation.
I tested that it works correctly in binding. For instance in Python:
> area.enable_drag(0)
> area.enable_drag(Gdk.ModifierType.BUTTON1_MASK |
> Gdk.ModifierType.BUTTON2_MASK)
… correctly disable then reanable the drag with buttons 1 and 2 (in
particular, I wanted to verify there was any reason why the property was
G_PARAM_CONSTRUCT_ONLY. Turns out there was no good reason).
I was interested by such API because having long list of parameters in
various APIs is very annoying. It is much nicer to have simple
constructors with decent defaults and proper API to modify a widget
afterwards in order to cater to special needs.
* 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.
This allows to force a GimpColorArea to display as out-of-gamut color.
Current code was only considering the generic RGB case (outside of [0-1]
range), and in particular not grayscale or indexed images.
Ideally the GimpColorArea widget could be (optionally) made to follow a
context, so that for instance it could update its representation when
the context image changes, or when this image's type changes. Yet since
it is a libgimpwidgets widget, it cannot get such update. Instead I add
a new API function to display the color box with the out-of-gamut
triangle. The decision code for this will have to be done elsewhere.
Use this new API for GimpColorHistory to display non-gray colors in the
history as out-of-gamut on grayscale images, or colors absent of the
palette on indexed images.
...palette views despite selected color being in the currently
selected pallette
As suggested by Massimo, changing the color comparison EPSILON in
gimppalette.c from 1e-10 to 1e-6 fixes this, and is really small
enough.
Also, generally clean up color comparison epsilons:
- use a #define, not hardcoded values for all uses of
gimp_rgb[a]_distance()
- call the #defines RGB_EPSILON and RGBA_EPSILON
- make them all 1e-6 or larger
... 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.
by simply drawing the buffer with cairo_mask() and a stipple pattern
so we get the same effect as before, but without rendering the
widget's background color into the buffer ourselves.
even if we don't have private members (yet). Also make class padding 8
pointers in all headers. This commit moves nothing to private, it just
makes all headers consistent and adjusts .c files accordigly.
and update their color transforms with the new monitor's color
profile. A widget is considered changing monitors when its toplevel
window's center crosses, in order to let widgets within one window
have consistent colors.
which encapsulates a cmsHTRANSFORM and does all the pixel format
conversion magic. It has API to create transforms and proofing
transforms, and to convert pixels arrays and GeglBuffers.
Before, each place which has a transform had to keep around the
transform and its input and output Babl formats, and had to implement
lots of stuff itself. Now all that lives in GimpColorTransform,
removing lots of logic from many places, and pretty much removing lcms
from the public API entirely.
This removes including <lcms2.h>, LCMS_LIBS and LCMS_CFLAGS from
almost all directories and potentially allows to replace lcms by
something else.
because it confuses gtk-doc and breaks some links. Also change the
"Index of new symbols in GIMP 2.x" sections to be what seems to be the
modern standard (looked at the GLib and GTK+ docs), and update some
other stuff.
