- don't allow to create a GimpImageMap of an operation without output
- make "region", "mode" and "gamma-hack" settable on a map that
already has a graph
- don't insert a useless "over" if the operation is a source op
- do the gamma-hack always on formats with alpha, so we don't lose
intermediate alpha results on source ops
- simplify graph connection a lot
- in GimpImageMap tool, don't recreate the map when reconfiguring
"region" and "gamma-hack"
Add a combo that switches between "selection" and "entire layer".
Need to find a way to hide that thing when the setting makes no
difference. Also the combo is generally pretty much experimantal.
There is now a preference option that determines whether windows
should be opened on the same monitor as before. It should be disabled
when the machine gets monitors plugged/unplugged dynamically ("laptop")
and enabled when there is a static multi-monitor setup ("wokstation").
This is merely the current simplistic policy on top of the newly added
underlying infrastructure:
- pass integer monitor numbers around in all places where we already
pass around a GdkScreen. Pass the "current" monitor to these changed
APIs, where "current" is either the monitor where the action-triggering
widget is, or if that is unavailable the monitor where the mouse is.
- add gimp_widget_get_monitor() in order to easily get to the monitor,
just like gtk_widget_get_screen().
- add screen and monitor parameters in some places that were missed
before.
- in sessionrc, save all window positions relative to the window's
monitor, and save the monitor separately, if it's not the screen's
primary monitor.
- when restoring window positions, use the stored monitor when the new
prefs options says so (use the screen's primary monitor if there is
no stored monitor), otherwise use current monitor that is now passed
around.
On tool change, we used to simply halt tools before switching to the
new one, which meant losing ongoing live-previewed tool changes, like
transforms, warps and color corrections. This change makes them being
applied to the image instead before switching to the new tool:
Add enum value GIMP_TOOL_ACTION_COMMIT that is passed to
GimpTool::control() before tool switching. Handle the new enum value
in all tools, and actually commit the previewed stuff. This changes
the behavior of GimpCageTool, GimpImageMapTool, GimpTransformTool and
GimpWarpTool.
Also make some of GimpToolGui's memory management proper, there was
no leak but it needs to be proper in order to add runtime switching
between dialog and overlay.
so gimp_image_map_tool_color_picked() isn't called any longer on clicks.
Add a warning there in case it happens anyway because this is always a
programming error.
It was misnamed from the beginning and has no relation to GimpImageMap
except that it happens to be used by GimpImageMapTools. Now it feels
less weird to potentially use it for other settings too.
and only update the drawable in that area if it's not NULL. Useful for
expensive interactive operations like warp, where the tool exactly
knows which area has changed.
- connect to the config object's notify generically and update the preview
- allow to properly exchange the operation at runtime to remove major
uglyness from GimpOperationTool
- return undo_desc from GimpImageMapTool::get_operation() so we have
proper strings in the undo history, not always "GEGL operation"
- simplify all get_operation() implementations
Reset the tool on image changes again, but not if only the active
drawable changes, so keep bug #678890 closed:
Introduce new dirty flag GIMP_DIRTY_ACTIVE_DRAWABLE and set it on all
tools' dirty_mask except for rect select. Check the new flag when
reseting the active tool because of a drawable change.
Make sure that temporarily setting/unsetting tool->control's "preserve
tool across image changes" does not mess up the default value:
Introduce gimp_tool_control_push/pop_preserve() which restores the old
state automatically, and use it in all tools, instead of saying
set_preserve(TRUE/FALSE) around image changes.
because the tool might be cancelled from some other place opening an
undo group, so flushing the image would update menus and whatnot while
that other operation is running, with unforeseeable side
effects. Also, flusing the image here is not needed because we didn't
change anything in the image. Instead, make sure manually that the
display is updated correctly after restoring GimpImageMapTool's
temporary editing.
so they can be passed in instead of being looked up in the class
struct, which enables freely configuring the settings stuff from
subclasses, such as soon GimpOperationTool.
