Even though many documentations will tell of $XDG_DATA_HOME/color/icc/,
some programs actually store color profiles in $XDG_DATA_HOME/icc/.
This is at least the case for GNOME color management.
Test it after $XDG_DATA_HOME/color/icc/ but before $HOME/.color/icc/.
add
gimp-justify-block
gimp-justify-center
gimp-justify-left
gimp-justify-right
patch
gimpicons.c
gimpicons.h
to get active and replace gtk-justify-*
'gimp/app/tools/gimptextoptions.c: box = gimp_prop_enum_icon_box_new (config, "justify", "gtk-justify", 0, 0);
must be patched
Honor them in gimp_widget_get_color_transform() and make them
configurable in prefs. The code and GUI avoid the negation in
the lcms "NOOPTIMIZE" flag.
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.
Rather than just discovering them by chance, a simple grep and some
search and replace are much more efficient! :-)
Cleaning only done on C and automake files.
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 installs a callback that behaves as if GtkWidget had a
"monitor-changed" signal. Additionally, moving widgets around between
windows is handled automatically.
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
Now that more and more widgets are color managed, we need transforms
for all of them. Creating them is very expensive.
The new cache returns the same transform for a combination of (config,
src_profile, src_format, dest_format) and invalidates itself
automatically on config changes. The number of transforms goes down
from potentially hundreds to a handful, and the cost of a config
change from many seconds to virtually instant.
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.
If a config is set, apply its settings when drawing the preview's
pixels. This is preparation for fixing:
Bug 467930 - color selectors are not color managed
Bug 556608 - Monitor color profile is not applied to filter preview
... when the button is clicked
Previously, the old color retained its previous value, so when the color
selection dialog was canceled, the button's color would go back to a
potentially outdated value, instead of the color it had when it was
clicked (for continuously-updated color buttons, at least.)
Add the right action buttons, enable overwrite confirmation, and add
user-writable folders to the shortcuts pane. Also use the right API on
OS X instead of hardcoding /Library and ~/Library.
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().
