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.
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
2007-10-16 Sven Neumann <sven@gimp.org>
* libgimp/gimppatternselectbutton.c
* libgimp/gimpbrushselectbutton.c
* libgimpwidgets/gimpcolorarea.c
* app/widgets/gimpdnd.c
* app/widgets/gimpdockbook.c: set GDK_WINDOW_TYPE_HINT_DND on
popup windows used to implement a DND cursor.
svn path=/trunk/; revision=23841
2006-04-27 Sven Neumann <sven@gimp.org>
* libgimpcolor/gimprgb.[ch]: added "has_alpha" to GimpParamSpecRGB.
Made the GimpParamSpecRGB struct public. When validating a color,
only look at the alpha channel if has_alpha is set.
* libgimpconfig/gimpconfig-params.h: added "has_alpha" to
GIMP_CONFIG_INSTALL_PROP_RGB macro definition.
* libgimpconfig/gimpconfig-serialize.c: serialize color values as
"(rgb r g b)" if the param-spec indicates that the alpha channel
is meaningless.
* app/config/gimpconfig-dump.c: take "has_alpha" into account when
documenting color properties.
* app/core/gimpcontext.c
* app/core/gimpgrid.c
* app/display/gimpdisplayoptions.c
* app/text/gimptext.c
* app/widgets/gimpaction.c
* app/widgets/gimpcolorbar.c
* libgimpwidgets/gimpcolorarea.c
* libgimpwidgets/gimpcolorbutton.c: specify whether color properties
have an alpha channel.
* tools/pdbgen/app.pl: handle "has_alpha" for color paramaters.
* tools/pdbgen/pdb/channel.pdb
* tools/pdbgen/pdb/context.pdb
* tools/pdbgen/pdb/grid.pdb
* tools/pdbgen/pdb/image.pdb: set the "has_alpha" flag where
appropriate.
* app/pdb/gimp-pdb-compat.c (gimp_pdb_compat_param_spec): set
"has_alpha" to TRUE for GIMP_PDB_COLOR.
* app/pdb/channel_cmds.c
* app/pdb/context_cmds.c
* app/pdb/gradient_cmds.c
* app/pdb/grid_cmds.c
* app/pdb/image_cmds.c
* app/pdb/palette_cmds.c
* app/pdb/palettes_cmds.c
* app/pdb/selection_tools_cmds.c: regenerated.
* app/config/gimpdisplayconfig.c (gimp_display_config_class_init):
removed unused code.
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-06-04 Sven Neumann <sven@gimp.org>
* libgimpwidgets/gimpcolorarea.[ch]: invalidate the buffer when
the widget's sensitivity changes. Draw a stipple pattern on the
insensitive color area.
* libgimpwidgets/gimpcellrenderercolor.c: follow internal API change.
* libgimpwidgets/gimpcolorbutton.c: pass GDK_BUTTON1_MASK as
drag-mask. Doesn't work for whatever reason but it didn't work
with GDK_BUTTON2_MASK either.
2005-06-04 Sven Neumann <sven@gimp.org>
* app/widgets/gimpdnd.c (gimp_dnd_get_viewable_icon): reduced the
number of characters to show before ellipsizing the label.
* libgimpwidgets/gimpcolorarea.c: added a "draw-border" property.
* app/widgets/gimpcolorframe.c: draw a border around the color area.
