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.
which is the opposite of gimp_config_path_expand() and replaces all
occurances of well-known gimprc paths with their respective
identifiers such as ${gimp_data_directory}, ${gimp_directory} etc.
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 g_file_get_parse_name() and g_file_parse_name() in order to turn
them into strings and back. Not really sure if we will end up needing
this, but I need it for current hacking. It's clean code and easy
enough to revert, so no harm done in either case.
The old GIMP_CONFIG_INSTALL_PROP_FOO() have the problem of always
passing NULL as the GParamSpec's "nick". I have no clue what we were
thinking back then, but this has always been a major design flaw
because (among other problems) it makes it impossible to fully
auto-generate GUIs based on properties.
Added GIMP_CONFIG_PROP_FOO() macros which do have a "nick" parameter,
will deprecate the old macros as soon as everything is ported.
Get rid of the "configurable RGB working space profile".
Instead, turn GimpColorConfig's "rgb-profile" property into a
"Preferred RGB profile" thing that is only a hint and never used
without explicit user interaction. Present it next to the built-in
profile in the profile combo boxes and call it "Preferred" in the
prefs dialog and its tooltip.
Most importantly, don't use it as the image's profile when the image
is not tagged with a profile. Untagged images are now always in the
sRGB or linear RGB built-in color spaces.
This commit reduces the "Apply color profile" dialog on file import to
a simple "Convert to built-in RGB", but that dialog is about to be
moved to the core and improved anyway.
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.
- use G_FILE_CREATE_NONE instead of 0
- don't put "Could not open <file> for writing: <error>" around the
returned error, the returned message is already verbose
Move all code from gimp_scanner_new_file() to gimp_scanner_new_gfile().
If the passed GFile has a path, use a GMappedFile like before, otherwise
GIO-read the entire file into an allocated buffer and parse that buffer.
instead of passing N_()-strings; and remove gettext() calls on these
strings when using them. Reduces complexitx, and fixes double- and
untranslated strings. Also enables to treat properties of GIMP and
GEGL objects the same way, which was totally broken before.
The foo_DEPENDENCIES rule replaces the default dependencies, where
EXTRA_foo_DEPENDENCIES just appends to it. This was causing libgimp
and libgimpui to build out of order.
Piotr Drąg