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.
(cherry picked from commit 7e513faa50)
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.
(cherry picked from commit a078ca3f5f)
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.
(cherry picked from commit 6008c2019b)
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.
(cherry picked from commit 87584d2f82)
We cannot simply randomy move the focus from e.g. a text entry back to
the canvas. Instead introduce global handling of "Escape" and a
"primary_focus_widget" that is always set the the image window's
active canvas. When Escape is pressed, move the focus to that primary
focus widget, or beep if it is already there. Text widgets still get
the key events before that logic and can consume the Escape.
(cherry picked from commit 5880685472)
Simplify the loops without any significant loss in performance, separating
the positive and negative X directions to treat each correctly. Fixes this
bug. (cherry-picked from commit faf2217811)
Use a temporary that is less expensive to refer to. Don't loop more
than necessary when comparing pairs. (Cherry-picked from master's
commit c83e7790bf)
Create all display filters with "color-config" and "color-managed"
parameters set, not only the automatically added color management
display filter. This way we don't only support removing and adding the
filter again, but also support potential other color management
modules.
(cherry picked from commit bc190a6bab)
Save the "right-docks-position" as negative value in pixels from the
right window border. Change the image window restoring code to
interpret negative values like that, but keep the meaning of positive
values for compatibility with existing sessionrc files.
(cherry picked from commit 9da0f489e1)
Call gimp_dialog_factory_show_with_display() in gimp_display_new(), we
otherwise do this only when the ICONIFIED state of an image window
changes.
(cherry picked from commit 97af52c465)
Prefer text/uri-list over image/* to make dropping from file managers
always behave like opening the image directly.
(cherry picked from commit 454639f9d9)
Sync GimpDisplayShell's properties with the default values when it's
emptied and turns into the empty display, so the default values used
when filling it with an image are displayed while it's empty.
(cherry picked from commit 54cf6c6e9f)
When updating the tool cursor on BUTTON_PRESS, pass a state *without*
the newly pressed button's mask to gimp_display_shell_update_cursor(),
or it will simply never call the cursor update function. Tool cursors
don't normally change when a mouse button is down.
(cherry picked from commit 5de48ef8b5)
(cherry picked from commit 89760cf044)
This is technically a new feature because it adds new stuff to
sessionrc, but on the other hand not handling maximized state in
sessionrc is worse, therefore merged to 2.8.
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.
(cherry picked from commit e546f2b43b)
Use gimp_item_translate() not gimp_item_set_offset() to position
dropped layers, because the latter doesn't affect child layers.
(cherry picked from commit 9ab3abc98b)
Another attempt to fix paste/drop positions for good.
Paste/drop target is either the selected area of a drawable, the
drawable itself, or the image:
- if the paste is larger than the target, center on the target
- if there is a viewport, and the viewport intersects with the
target, center on the intersection
- otherwise, center on the target
Finally, if we did viewport-centered pasting, make sure the paste is
as completely within image bounds as possible.
(cherry picked from commit eda6fa1c14)
Fix this and other issues more globally by moving the logic that
formats the image's display name into the GimpImage object, and return
the properly formatted name, e.g. "Foo.xcf", or "[Foo] (imported)"
from gimp_image_get_display_name().
Also add gimp_image_get_display_path() which returns the full path
instead. Use the two functions for formatting the image title, and
apply various other fixes that make sure the UI always uses the same
string to identify the image.
Call gimp_object_name_changed() whenever the save/export status
changes, so the image's cached display name and path get cleared.
(cherry picked from commit 220b28677b)
I'm not sure if it'd be better to compress only sequence
of contiguous motion events, thinking to the case of anticipating
a motion event before a modifier key press/release.
commit 9ce8d4fae2. Fix the return_val
logic added in that commit, and make sure we always swallow arroy key
events, because we don't want focus keynav away from the canvas.
(cherry picked from commit f400bc49ca)
Regardless of the elaborate discussion in bug #599267, as soon as the
grid starts covering the image completely (when the is no more spacing
between grid lines), it is entirely useless, so skip drawing it.
Instead, either destroy the child instead of removing it, or remove
*and* destroy it in cases where the remove() api on the "parent"
doesn't match GTK+'s parent/child relation (like with all our dock
widgets). We can't rely on remove() to implicitly detstroy, because
there might be arbitrary other code holding references, such as
accessibility modules and whatnot. Most likely fixes unclear crashes
in accessibility code and other crashes we blamed GTK+ for.
