GitLab

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

...in the Levels dialog explain the difference between them

Improve the tooltips of the pick buttons to say

"Pick FOO point for {all channels|the selected channel}"

script_fu_load_directory(): load scripts recursively.

Hartmut Kuhse authored Aug 30, 2015 and Michael Natterer committed Aug 30, 2015

...one green

Don't write the TIFF thumbnail using metadata functions, instead write
it as a TIFF sub-image.

gimp_image_duplicate(): set the new image's color profile *before*
copying layers to it, or the new layers will be automatically
converted to "no color profile aka sRGB", but then tagged with the
original profile anyway.

either linkers got smarter or our structure got better, or this breaks
on whatever other linkers again...

When calculating the color of a pixel, we want to calculate the color
at its center, not at its top-left corner. Found by Raymond Jennings.

and call it when an "icc-profile" parssite is attached or detached.
This removes code duplication and creates a place to conveniently
update more cached profiles and transforms, such as from/to sRGB for
color picking and applying.

Add gimp_gegl_index_to_mask() and gimp_channel_select_by_index() and
around it actions, callbacks and GUI in the colormap dialog.

which I forgot in yesterday's color picking refactoring.

...until dialog window is resized

Immediate eye cancer guaranteed when looking at this patch.

if the same name is set via gimp_object_set_static_name() or
gimp_object_take_name() (gimp_object_set_name() and
gimp_object_set_name_safe() already had the check).

Since this is a slight behavior change it might have subtle side
effects; it definitely fixes GimpThumbBox thumbnail state to not
always re-create the thumbnail on click, which was happening since
porting to GFile (which switched from gimp_object_set_name() to
gimp_object_take_name()).

...when a color profile is active

This commit doesn't fix anything, but it prepares the code to do the
right thing:

It passes the actual raw image pixels through the entire color picking
mechanism to the widgets which display colors, particularly
GimpColorFrame.

This is needed for GimpColorFrame's "Pixel" mode (as opposed to its
RGB, HSV etc. modes) which is supposed to show the raw pixel values
from the image.

Before this commit, it was recreating the raw pixel values from the
GimpRGB value it knows, which will become impossible when we correctly
pick color managed GimpRGB values soon.