Based on GimpPopup as parent, this is a generic search popup widget,
which can display any list of action. The results construction logics
is not part of the widget, and is built through a callback instead,
which could allow to use it to create different dialogs.
gimp_drawable_get_sub_preview(): both the preview buffer's scale
factor and the src coordinates in the drawable were calculated
wrongly. 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.
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.
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.
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.
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.
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.
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.
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).
...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}"
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.
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.
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.
Michael Natterer