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.
- don't include <gdk-pixbuf/gdk-pixbuf.h> in headers in app/
- instead, include it in many .c files instead of <glib-object.h>,
finally acknowledging the fact that app/ depends on gdk-pixbuf almost
globally
- fix up includes as if libgimpbase depended in GIO, which it soon will
This fix is entirely sick, so is our method of serializing units,
which we write out as (unit foo bar) instead of (unit "foo bar"). The
assumption that caused this shit was that a unit's "identifier" is
really an identifier in the C-ish sense, when in fact it's just a
random user entered string.
Here, we try to parse at least the default units shipped with gimp,
and we add code to parse (unit "foo bar") in order to be compatible
with future correct unit serializing.
This only helps to maintain proper includes in app/ and shouldn't
affect plug-ins at all, because these are supposed to only include the
main headers from libgimp/ since the beginning of time.
The gimpfootypes.h files do not have these guards, so we can continue
to maintain app/'s include policy that is very likely to error out if
wrong things are included.
Michael Natterer