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.
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.
Remove all stock items added since 2.8, restore accidentially removed
ones, and rename the newly added GIMP_STOCK_* defines to GIMP_ICON_*.
(will move to having GIMP_ICON_* defines instead of magic hardcoded
strings for all icons).
and use gimp_file_new_for_config_path() and _get_config_path() when
dealing with them. We used a weird mix of config paths and plain
(filesystem encoded) paths, waiting to to break on umlauts or
whatever. The code in gimpcolorconfig.c was particularly bad.
to gimp_color_config_get_simulation_color_profile(), along with
various internal "printer" strings. Also reduce the number of
user-visible "print" stuff from the preferences color management page.
Use cmsFLAGS_NOOPTIMIZE only for actual image buffer or single color
transforms, but not for previews or the image display. Makes things a
lot more responsive again.
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.
symbolic-scalable
add 'pixel-perfect' 24px vectorial twins (as replacement for 22px)
gimp-prefs-folders-dynamics
gimp-prefs-folders-environ
gimp-prefs-folders-fonts
gimp-prefs-folders-gradients
gimp-prefs-folders-icon-themes
gimp-prefs-folders-interp
gimp-prefs-folders-modules
symbolic-scalable & color-scalable
add new icons
gimp-color-cmyk
gimp-color-water
patch
color-selector-cmyk.c
color-selector-water.c
gimpicons.c
This is the first patch to solve Bug 759904
many more have to follow
Thanks to Jehan for the assistance
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.
Its API was too limited, and adding parameters for what we need next
would be equally random. It's a rarely used and mostly internal
widget, so simply use g_object_new().
to not return a reference that has to be dropped. Also allow NULL to
be returned if the managed cannot have a profile. If it can have one,
get_color_profile() still always returns a profile (either the
assigned one, or a generated built-in one).
it used to be a typedef to gpointer and actually was a cmsHPROFILE.
Change its API to be more "standard", remove the public close()
function. The object caches both the cmsHPROFILE and the data/length
ICC blob, so conversions between the two become obsolete (simply call
get_lcms_profile() or get_icc_profile()).
Adapt everything to the new API, but port it in a naive way for now,
the code doesn't take advantage of the new possibilities yet (like
refcounting).
gimp_color_config_get_foo_profile() -> get_foo_color_profile()
because the old names clash with possible future accessors for the raw
filename properties.
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.
which always returns a profile, instead of code that uses the ICC
blob and falls back to GimpColorConfig's profile, then falls back
to the built-in profiles.
Ell