Similar to 42300d9d, we want to prevent overly long color profile
labels from stretching out dialogues with GimpColorSelect too far.
This patch adds gtk_label_set_ellipsize () to both the color profile
and simulation profile labels, and adds them to a grid instead of
letting them free-flow.
By default, the GimpColorSelect widget is set to show HSV with Hue
selected but we weren't selecting the channel which was defaulting to
"Red" of RGB. Therefore there was some inconsistency when first opening
the color selection dialog which was showing HSV colors on the left, yet
with "Red" selected on the right.
This fixes the inconsistency, which also allows parent or container code
to set the default they want (which is indeed RGB).
Do not only show the space, but also the model. For instance both RGB
and HSV can have the same profiles.
As for LCH, we must not show any space (it is based on CIELAB).
Note that I use the string "Model: %s" which is already used in
libgimpcolor, so I am not breaking string freeze. The "%s - %s" string
though is not localized, even though ideally it should be (and possibly
even be a better joining string in English), but I don't want to break
string freeze for this.
This issue is part of the fix for #10998, more as a UX issue than a bug
per-se. Depending on how you were selecting a color, now you might
select it as HSV, LCh or some other model (this was **not** the case
before, even though the GUI was similar. Yet the stored color was always
RGB. Now it's actually "whatever you choose"). As a consequence, it is
possible that choosing a color in another model may convert to slightly
different numbers, especially within decimal places. I don't think it
was the main issue, but it certainly doesn't help. Now we may be making
clearer what color model is being used in the GimpColorSelect color
areas.
Per Pippin, the only color model that can
have double precision is RGB/A.
Therefore, we need to switch all others to
use float instead. This patch converts the
HSV and HSVA double babl formats.
Mainly fixing GimpRGB comments and
parameters that are unused (or in unused
functions).
GimpCircle and GimpGradientChooser
have color conversions ported to use
GeglColor exclusively.
When changing the selected color, we have no reason to redraw the Z preview.
This preview should only be redrawn if the allocation size changed, or if we
change the previewed model or the Z component.
As for the XY preview, it should only be redrawn if the Z value is changed (and
of course, similarly, if the allocation changed or if model or Z component
changed).
No custom conversion code anymore. This also fixes some bugs in HSV when
I was wrongfully multiplying the hue by 360 when mixing babl and custom
code paths.
Until now we only had the case of the CMYK color selector using the
soft-proofing profile. Yet this is also interesting for other color
selectors, in particular to show out-of-gamut colors. Indeed if we
enable soft-proofing on the active image, it is interesting to show the
intersection of the current RGB/Grayscale space gamut with the
soft-proofing gamut.
Right now, this is only used in GimpColorSelect when showing colors in
LCh color space.
What this commit does is keep the same code logic while moving to
GeglColor. Yet it's not **really** space-invaded yet. What we need to do
now:
1. Take into account the image space, and this is what we must navigate
through, in particular for various representations of RGB or HSV.
I.e. that if the active image is in anyRGB, the RGB values shown must
be within anyRGB. Right now, everything is still shown/used as sRGB
(even though it's properly retrieved and transformed to the target
space thanks to GeglColor).
2. Show space info to make things clear and explicit, by adding some
label somewhere.
3. Allow to switch between image and softproof spaces, regarding
out-of-gamut display. I.e. that while RGB/HSV must be shown within
the image space (assuming it's anyRGB), we may want to show
out-of-gamut area (pink areas) within the softproof space. This may
mean adding a checkbox. Or maybe simply taking into account whether
we are in softproof mode or not?
4. We can likely move off gimp_widget_get_color_transform() into using
gimp_widget_get_render_space() for display drawing. We don't need any
soft-proofing or black point compensation for any of these widgets so
pure babl is fine. Indeed we want to show any in-gamut color
correctly (and not transformed according to specific intents or
through soft-proofing). We will take care of the proofing case with
out-of-gamut area showing only.
5. In the various drawing functions, we should move to
CAIRO_FORMAT_RGBA128F. The color selection area might be wide enough
that it makes sense to be more accurate, especially as we are
essentially showing color gradients in 1 or 2 directions in these
various widgets.
- 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.
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.
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.
- 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
Redo the entire thing again:
- Rename the values of enum GimpColorSelectorModel to include "MODEL"
- Change GimpColorSelector API from set_model() to set_model_visible()
so visibility of each model can be toggled individually and is not
exclusive any longer
- The GUI is back to what it was before, except that the "GIMP" page
now honors the model visibility and has a resonable minimum height
This way, we get proper CRITICAL if ever there is a logic error (or in
this case, if we add new values to enums and forget to append them to
switch cases.
This will make these bugs much easier to debug if (when!) they happen.
This patch increases the LCH Chroma slider maximum value from 100 to
200 and also makes the Chroma slider properly display out of gamut
Chroma selections for any given Hue/Lightness combinations.
The current Chroma slider only runs to 100. But quite a few sRGB
colors have LCH chroma values that are greater than 100. For example
reddest red has a chroma of 107, and bluest blue has a chroma of 131.
So it's inconvenient to have to deal with a Chroma slider limit of
100.
Also, the current Chroma slider doesn't properly show out of gamut
areas on the Chroma slider. So for example picking a given LCH Hue and
then moving the Lightness slider doesn't allow to see which Lightness
value allows for choosing the maximum in-gamut chroma for the chosen
Hue.
Add LCH to the color selectors, patch by Elle Stone and myself.
- Extend enum GimpColorSelectorChannel by LCH channels
- Support them in GimpColorScale, GimpColorScales and GimpColorSelect
- Did not yet remove the HSV channels until things are working 100% ok
- Change drawing in GimpColorSelect to be much faster, to compensate
for babl_process() making the LCH modes pretty slow
- Clean up stuff in GimpColorSelect
This is WIP and should not be considered finished, biggest TODO is
displaying out-of-gamut values in GimpColorScales' spinbuttons.
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.
Switch the axes of the GimpColorSelect color area so that on the X
axis, we always modify the first of the two channels of RGB or HSV
that are edited here, and on the Y axis the second.
Alx Sa