...in initially active tab
We intend reuse the dialog across displays, so don't destroy the
dialog in GIMP_TOOL_CONTROL_HALT, only hide it. This way the dialog
keeps its detached state.
Don't hardcode modifier masks in the wheel and keyboard input
controllers. Instead, hardcode accelerator strings and get the right
modifier mask from gtk_accelerator_parse() at runtime.
This turns e.g. "<Shift><Primary>" into Shift+Cmd on OS X and into
Shift+Ctrl on X11 and Windows.
Also rename the events accordingly and change the event names in the
default controllerrc.
Unrelated: reorder the actions so the ones with less modifiers are
listed first, and change the order of action matching to match the
actions with most modifiers (the last ones) first.
...in initially active tab
gimp_tool_gui_update_shell(): implement the "overlay" case and hide the
gui on the previous shell, then show it on the new one.
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.
Add gimp_image_import_color_profile(), a GUI vtable entry
query_profile_policy() and a new dialog which returns the profile
policy and the profile to convert to. Get rid of the wrapper that
calls the lcms plug-in for that dialog, the plug-in is now completely
unused.
This commit doesn't add any new features, it's just the former lcms
plug-in dialog implemented in app/ (except the little fix that it is
now aware of linear vs. gamma images).
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.
not only as parasite. This way we avoid having to create the profile
in each call to gimp_image_get_color_profile(). Also keep the built-in
profiles around in gimp_image_get_builtin_color_profile(). Add/remove
refs and unrefs as needed in all users of these functions.
also add "GType old_type" to GimpItem::convert() so implementations
can do things depending on the type of the original item.
In gimp_layer_convert(), if the original item is also a layer, and
color management is not off (with a FIXME because this is the wrong
check), pass convert_profile = TRUE to gimp_drawable_convert_type().
There is no color profile conversion anywhere behind this, this is
just an API change commit.
which converts a buffer with a profile into another one with another
profile. The function tries to avoid the lcms transform by checking if
a simple gegl_buffer_copy() has the same result.
gimp_layer_new_convert_profile(): if there is a profile, always use
lcms to copy between the buffers, to avoid the additional gamma
conversion gegl_buffer_copy/get() would do in some cases. This should
fix copying between linear and gamma images.
In gimplayer-new.c, convert new layers to the image's profile if color
management is not disabled in prefs. This should convert pixels from
whatever source if they have a profile attached. If they don't have a
profile, no conversion is done. I'm not entirely sure if this
automatic conversion is always the right thing to do, please test.
Uncomment and implement the menu items and actions to invoke the
dialog. This new code also does the (alomst) right thing to linear
images, unlike the lcms plug-in.
Ref/unref the dialog around saving the image insatead of connecting to
"destroy" and NULLifying the local dialog variable on destruction,
which has caused weird crashes on fedora.
- gimp-image-set-filename PDB wrapper: implement the same there in
a few lines
- xcf-load.c: use gimp_image_set_file() instead, and get rid of the
last use of filename in xcf/ in favor of GFile
The possible failure of `g_file_replace()` was overlooked, as well as
the error which may have been created and could be useful information
for the developers.
The "filename" parameter must be in UTF-8 and in URI format (for
instance file://path for local files, and not just a path).
Cf. `g_file_new_for_uri()` documentation:
@uri: a UTF-8 string containing a URI
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).
The object offset is calculated correctly for channels in the
GIMP_IS_ITEM() case using gimp_item_bounds().
Also did some general formatting cleanup in the entire file.
Which returns a boolean indicating if there is content at all, and the
bounds as double x, y, width, height because for most use cases that's
better than x1, y1, x2, y2. Wrap the method with two functions
gimp_item_bounds() which returns integer bounds and
gimp_item_bounds_f() which returns the original double bounds.
...but they aren't clipped
gimp_display_shell_profile_can_convert_to_u8(): allow the shortcut of
converting directly to 8-bit for display only for GIMP_COMPONENT_TYPE_U8.
This might be an lcms bug, the code can be enabled again for U16 and
U32 if it's indeed an lcms bug and it gets fixed.
...certain sets of linked layers
Fix the move tool (GimpEditSelectionTool) using the same principle
as the other "linked item" features, just a bit more complicated...
Never translate the active item and its linked items separately,
always translate the entire list at once.
The linked logic was distributed across the entire file. Changed the
code to prepare lists of items that are translated live (layers and
vectors), and items that are translated at the end (channels, masks
and the selection). In the motion and button release functions, simply
use the prepared lists without any further duplicated checking.
Also clean up the stuff a bit, there is more cleanup needed but first
the fix...
...certain sets of linked layers
Fix for translating layers from the PDB, and with the cursor keys
for gimpeditselectiontool. Moving layers with the mouse is still broken.
The approach is exactly the same as in 25a696c7.
...certain sets of linked layers
Fix this bug for flip, rotate and general transforms (not for move yet):
gimp_item_linked_flip,rotate,transform(): always transform the passed
item too (do not filter it out of the list of items), so these functions
do the entire job of transforming a linked group now. Transforming the
active item separately didn't work (and is not implementable) if both
a layer and its parent layer group were linked.
flip tool, transform tool, layer->transform callbacks: don't call
gimp_item_foo() *and* (if the item is linked) gimp_item_linked_foo().
Instead call gimp_item_linked_foo() if the item is linked, and
gimp_item_foo() otherwise.
This commit also kills the mis-feature of transforming the selected
pixels of the active layer, and then the linked items completely. We
now either only transform the selected area *or* the linked group.
In gimp_group_layer_update_size(), when the new size happens to be the
same as the old size, we need to call gimp_pickable_flush() on the
group projection so it is ready to be used for rendering the image,
just like in gimp_group_layer_stack_update().
Michael Natterer