Calculate GimpCanvasPassepartout's extents using a cairo_region_xor()
of the crop rectangle and the image extents, instead of a
cairo_region_subtract(). This fixes the artifacts and has the nice
side effect that the passepartout now colors both the parts of the
image that will be removed *and* the parts of the image that will be
newly added.
- don't include <gdk-pixbuf/gdk-pixbuf.h> in headers in app/
- instead, include it in many .c files instead of <glib-object.h>,
finally acknowledging the fact that app/ depends on gdk-pixbuf almost
globally
- fix up includes as if libgimpbase depended in GIO, which it soon will
Along with this change, the snap preferences have been moved from
GimpDisplayConfig to GimpDisplayOptions, where it makes much more sense.
One of the consequences is that there is no need to duplicate these
values in GimpDisplayShell anymore to differenciate defaults and
current settings.
The main change is that even with only 1 image in single window mode,
there is now a tab.
Also whatever the number of images when you hide docks with Tab, no tabs
are shown.
Shells can now travel from one window to another. Canvas position code
should therefore not keep track of the image window for a specific shell
but must use whatever is the current window for this shell (even though
it may be a different one before and after the size-allocate).
This also partly fixes some positioning issue during mode switch.
This removes the obsolete check which makes the tool fail from
gimp_display_shell_set_mask(). Also change the foreground select tool
and the display mask from using GimpChannel to GeglBuffer, because
that's what it needs, simply buffers. Most changed files simply newly
include <gegl.h> because a GeglBuffer appeared in two headers.
Letting just tab presses bubble up when an overlay canvas child didn't
handle a key event isn't enough. Instead, let all key presses and
releases bubble up if the canvas itself doesn't have the focus.
Read: don't make assumptions.
Tab key events are not handled by the widget itself, they are supposed
to bubble up until they hit the generic keyboard navigation code
that knows about the focus chain, therefore:
gimp_display_shell_canvas_tool_events(): if an overlay widget is
focussed, don't handle Tab events and toggle dock visibility. Instead,
simply bail out with FALSE so the event reaches te keyboard navigation
code.
Also treat GDK_KEY_KP_Tab like GDK_KEY_Tab all over the place.
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.
Use "right-docks-width" and always a positive value instead of
"right-docks-position" (as opponsed to "left-docks-width", that
distinction is a GtkPaned implementation detail and does not belong
into a config file). Parse all old values too. Also fix a glitch in
the deserialization code which might fix bug #700147.
In multi-window mode, closing an image window is only meant to close
the current image (unless this is the last empty window).
In single window mode though, you are meaning to close the whole program.
Thanks to Niels Martignène for the original patch.
Don't try to switch to the move tool if the move tool is already active.
Also never bail out early from gimp_display_shell_space_pressed() so we
don't end up in an inconsistent state.
