GitLab

Julien Nabet authored Sep 05, 2015 and Michael Natterer committed Sep 06, 2015

Layer name source (id on 4 characters encoded in MacRoman).
psd from PS>5 have "luni" (Layer Unicode)

See https://bugzilla.gnome.org/show_bug.cgi?id=753986#c4 for more details

Janitorial on lyvr:
move IFDBG at the beginning of the function
+change the content of it

Fix gimp_color_profile_get_format() to return the right format for
"cairo-RGB24": simply check for the more special cairo formats first,
then check for the general RGB models. Found by Massimo.

While loading an image with color profile, gimp offers the possibility to convert it to the builtin profile. Setting the new color profile before converting, deletes the old one and results in a segmentation fault.

Let's use semantic names rather than raw meaningless values.

The "map" signal does not mean a widget is mapped. It may be emitted
before. Yet pointer and keyboard grabs won't work on non viewable
widgets and will fail with GDK_GRAB_NOT_VIEWABLE.
For some reason, a GtkWindow with type GTK_WINDOW_POPUP was always
mapped when "map" is emitted but not yet with type GTK_WINDOW_TOPLEVEL
(at least in my tests). Thus switch to "map-event" to make sure the
widget is actually mapped.

Delete the duplicated sanitized image when canceling in the gif options
dialog.

This specific crash was only occuring when GIMP_INTERACTIVE_EXPORT=1
and canceling the first dialog. So that should not happen too often,
but well, now it's fixed…

Implement color management in GimpViewRenderer: if the viewable is a
GimpColorManaged (true for images and layers), keep around a
GimpColorTransform and convert the preview image to display colors.

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).

and change GimpImage and GimpItemStack to emit the "profile-changed"
signal when the image's profile changed. Also connect GimpViewRenderer
to "profile-changed" if the viewable is a GimpColorManaged and
invalidate the preview.

This reverts commit 5c8ffdf6.

It was a bad idea, we have the GimpColorManaged interface for that.

We will need the widget for color managing previews; it's also more
consistent to pass the widget to all render_foo() functions, not only
to render_icon().

gimp_image_constructed(): connect to "notify" on GimpColorConfig
and call gimp_color_managed_profile_changed() on the image.

Remove the "notify" handler on GimpColorConfig from
gimpdisplayshell-handlers.c because it already connects to the
image's "profile-changed" signal.

Additionally, implement GimpColorManaged::profile_changed() in
GimpImage and invalidate the image and all layer previews. One step
closer to color managing image and layer previews.

It's split out of gimp_gegl_convert_color_profile(), used from there,
and will also be used to color manage image and layer previews.

so color profile transforms can write directly to cairo-RGB24 and
cairo-ARGB32 surfaces.

By default, it only saves the current file filter, but it allows a child
to implement its own state. It has been implemented by GimpSaveDialog to
save the preferred compatibility mode as well.

The code refactoring allows better readability which will allow in turn
to add more complex specific features making good use of the save/export
split concept.

Commit 0ea7d855 was misunderstanding due to foo-lang (language spoken by
Mitch and others, but not me, it would seem!). :-P

Change GimpColorManaged to GimpColorProfile.

but a bit more logical. This totally needs to change again.

which currently all end in a call to gimp_color_managed_get_color_profile()
except for channels and masks. This is currently unused infrastructure but
will be used for things like layer previews, and return NULL if called
on a mask or channel, or if color management is disabled, or whatever.

Not sure why, ask Mitch! :-)

This would typically happen if the compat mode was set earlier through
the save dialog, then later changes in the image render it inapplicable.
When this happens, we unset the compat mode, and saves without error,
but still emit a warning for the user to know the compatibility got
dropped.

If one explicitely enabled the compat mode on an image, we should assume
this mode should be reused upon following saves, even after shutdown.

Even if you saved previously in compatibility mode, you may have used
new features since, which would cancel the compat mode flag.

If one explicitly enables the compatibility mode, one expects this to
be applied on following saves of the same image as well.

Call gimp_layer_update_mode_node() also when removing a mask, and
change it to only do its magic if there actually is a mask (don't only
look at the "show_mask" boolean).

Pointed out by prokoudine on irc after it was introduced in e2bdfd41