Currently if your image history includes an
image with a long name, the Welcome
Dialog will stretch out to match its width.
If the color profile name is long, then the
color scales will also stretch out due to
the profile label.
This patch adds ellipses to the Welcome
Dialog and a scrollwindow to the
ColorScales to prevent this.
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.
This commit adds gimp_color_selector_set_format() which is meant to give
awareness of the target color format for which we are selecting colors.
Right now, I am only using this information on the Scales selection
method, which means that now colors you read and select are in the
target space. Even better, the out-of-gamut shown happens in the with
LCH scales is for the target space too. As tested, it already makes
quite a difference for an image in sRGB vs. say adobeRGB.
Note that right now, I only use the format information as a space, but
in fact, I made the API to be about a format because the actual format
can be used wisely too. First we may want to do different thing
depending on the color model itself (which the space may give away or
not, especially when using default spaces or when we'll have images
using models with no space in the future, such as CIE Lab). But also
whether the image is following the space TRC or is linear (or
perceptual) would change how we represent the data. If we were to show
non-linear values in the Colors dockable but when painting, the color
picker shows linear values for instance, it might be puzzling to people.
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.
RGB 0..255/0..100 and LCh/HSV settings are now remembered when closing
and reopening GIMP.
A few enums were explicitly cast to GimpColorSelectorChannel to clear
some compiler warnings.
… gimp_scale_entry_set_bounds().
I realized that this function may look like the set() opposite for
gimp_scale_entry_get_range(), which it is not at all. The get_range() is
for getting back the GtkRange widget packed in the GimpScaleEntry,
whereas the set_range() is to change the minimum and maximum allowed
values.
I had recently renamed the former, and could just rename it back into
gimp_scale_entry_get_scale() as it was, but since the class we rely on
is actually called GtkRange (GtkScale is a subclass), I think it could
be misleading. So in the end, let's rather rename the function setting
the widget minimum and maximum as gimp_scale_entry_set_bounds() instead.
Hopefully this is even more understandable. Naming is hard!
Former gimp_color_scale_entry_new() is finally replaced by the
GimpColorScaleEntry implementation.
Both places which used it (GimpColorScales and compose plug-in) now use
the new widget.
Also making "upper" and "lower" properties of GimpScaleEntry into
construction properties, and create the main GtkAjustment at init, so
that we are sure that lower and upper bounds are properly set before we
set the value (when setting all properties at once, we cannot ensure
that these limit properties are set before the "value" one).
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.
Add CSS names using gtk_widget_class_set_css_name(), remove styling in
code and instead do it properly in CSS, so far in the System theme.
All horribly incomplete but a start.
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 allows to have a smaller and cleaner color dock instead of just
listing all possible channels (which may only grow up as we may add more
color spaces).
The API gimp_color_scales_(set|get)_show_hsv() are removed in favor of
more generic gimp_color_selector_(set|get)_model(). I assume this is
ok since they have only been available in the dev version (commit
6258d525ae, a month ago).
This is WIP in the middle of cleaning up GimpColorSelector subclasses:
Add the possibility to switch between LCH and LSV and between 0..100
and 0..255 RGB in to GimpColorScales. Works almost fine, but needs
different UI to change the options...
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.
Last bit for now: allow GimpColorScales' spinbuttons to go further
than its color scales. Please review the new min/max values of the
individual channels.
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.
Still using perceptual TRC - making 50% middle gray. This for all of 8bit and
16bit integer, as well as for floating point precisions. Also added a decimal point, to make use of more precision for both RGB and HSV entries.
In places where the pattern
if (show)
gtk_widget_show (widget);
else
gtk_widget_hide (widget);
is used, change to
gtk_widget_set_visible (widget, show);
Also do some other minor cleanups.
2009-01-17 Michael Natterer <mitch@gimp.org>
* all files with a GPL header and all COPYING files:
Change licence to GPLv3 (and to LGPLv3 for libgimp).
Cleaned up some copyright headers and regenerated the parsers in
the ImageMap plugin.
svn path=/trunk/; revision=27913
2005-12-20 Michael Natterer <mitch@gimp.org>
* libgimp/*.c
* libgimpconfig/*.c
* libgimpmodule/*.c
* libgimpthumb/*.c
* libgimpwidgets/*.c: port to G_DEFINE_TYPE() and friends. Some
related cleanup.
2005-05-22 Michael Natterer <mitch@gimp.org>
* libgimpwidgets/Makefile.am: changed gimpwidgetsenums.c rule to
include the bits for "desc" and "help" support.
* libgimpwidgets/gimpwidgetsenums.h: added "desc" and "help"
strings for the GimpColorSelectorChannel enum.
* libgimpwidgets/gimpwidgetsenums.c: added to CVS because it
contains translatable strings now.
* libgimpwidgets/gimpcolorscales.c
* libgimpwidgets/gimpcolorselect.c: removed duplicated arrays of
strings here and get them from the type system.
2005-05-20 Sven Neumann <sven@gimp.org>
* libgimpwidgets/gimpcolorselection.c: put the hex entry above the
color history again.
* libgimpwidgets/gimpcolorscales.c: do not allocate row spacing
for the alpha row if it isn't visible.
2005-05-19 Sven Neumann <sven@gimp.org>
* libgimpwidgets/gimpcolorscales.c: removed the hex entry from the
GimpColorScales widget.
* libgimpwidgets/gimpcolorselection.c: added it here instead.
* app/widgets/gimpcoloreditor.[ch]: and here, next to the FG/BG
editor.
Alx Sa