Commit 1e6acbd4e1 modified the
generated enum recipes to run gimp-mkenums from the source
directory, instead of the build directory, so that only the
basenames of the corresponding header files would appear in
the comment at the top of the generated files. This was a
mistake -- $(GIMP_MKENUMS) is expecting to be invoked from the
build directory.
Switch back to running gimp-mkenums from the build directory. To
avoid including the relative path from the build directory to the
source directory in the generated file, add a @basename@ production
variable to gimp-mkenums, which exapnds to the basename of the
input file, and use it instead of @filename@ in the recipes for the
generated enum files.
When regenerating an enum file, don't copy it back to the source
directory if it hasn't actually changed. This allows using a read-
only source directory where the enum header is newer than the
generated file, as long as they're not really out of sync.
OTOH, *do* touch the generated source-dir file even when unchanged,
in order to avoid re-running its recipe on the next build, however,
allow this to silently fail (which is harmless).
We check them into git, so this makes it easier to keep them in
sync when using a separate build directory.
Case in point -- this commit also syncs a few enum files that went
out-of-sync with their headers.
This avoids a lot of useless notifications when resetting an object,
and fixes e.g. the "reset tool options" behavior of GimpTransformTool,
which did completely reset itself instead of just behaving like all
non-default options had changed.
And probably breaks some things that were relying on these redundant
notifications.
If the enum value is not found among the nicks and names of the
GParamSpec's actual enum type, check if it has a "gimp-compat-enum"
GType attached as QData, and try the lookup there.
instead of choking and aborting parsing of the entire config file. The
negative values are still clamped away after parsing, but at least we
properly read them now.
g_value_get_object() doesn't return a new reference, so it must
not be dropped. Fixes random crashes when a profile was chosen
in a GimpTemplate (e.g. in new image or prefs). Spotted by Elle.
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.
Michael Natterer