Disable extended input events when the cursor moves to a child of
the canvas widget. Otherwise GTK will try and fail to deliver an
extended event to the child widget, and end up sending it to the
canvas instead.
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.
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.
First version of display rotation, inspired by gimp-painter.
The rotation always happens around the image's center.
The only "UI" for rotating is currently shift+middle-drag and
shift+space-drag. Control constrains the angle to 15 degrees
and is currently the only way to go back to "no rotation".
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.
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.
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.
Because it's generally the right thing to do, and server grabs broke
badly with input devices / client side windows.
gimpdisplayshell-grab.c: change logic to only server-grab if an event
is passed to the pointer grab/ungrab functions, but always use
gtk_grab_add/remove() which is sufficient in most cases.
gimpdisplayshell-tool-events.c: have the grab functions grab the
server only for space-bar scrolling and do all tool interaction,
including ruler clicks, with gtk_grab_add/remove(). Refactor things
a bit to also use the grab API for button-2 scrolling.
gimpdeviceinfo-coords.c: transform the event's coords to the canvas'
coordinate system, they might come from a ruler now.
This fixes the following bugs:
Bug 645315 - gimp_display_shell_pointer_grab: gdk_pointer_grab failed...
Bug 644351 - Gimp misses some strokes especially when drawing fast
Bug 645747 - Gimp is now unusable on xfce4
instead of checking for event->button == 3, so context menus
work correctly on the Mac. Didn't change the image menu yet
because thet requires some more refactoring.
in both multi- and single-window mode. This is useful especially in
multi-window mode because in single-window we can already cycle
through all tabs with Ctrl+PageUp/Down.
- start_stroke()/finih_stroke() -> begin_stroke()/end_stroke()
- process_event_queue() -> process_stroke()
- GimpMotionBuffer::motion() -> GimpMotionBuffer::stroke()
- add GimpMotionBuffer::hover() and process_hover()
- remove push_event_history() and pop_event_queue() from API
The thing works like this:
- Motion events are continuously fed into the buffer using motion_event()
- begin_stroke()/end_stroke() correspond to BUTTON_PRESS/BUTTON_RELEASE,
the period between them is a "stroke"
- If motion_event() returns TRUE, we request "stroke" signals by calling
process_stroke() and "hover" signals by calling process_hover()
where finish_stroke() is the former flush_event_queue() and
start_stroke() is used in BUTTON_PRESS instead of poking into the
motion buffer's internals. Also, call finish_stroke() also when the
tool is not active, so the event buffer is flushed (the "motion"
callback will ignore the events if the tool is not active).
and emit the buffer's "motion" signal when a motion is supposed
to happen. In GimpDisplayShell, connect to GimpMotionBuffer::motion()
and call the tool.
That's most likely a very old artifact that was needed not even when
we used to do XOR, and these days it's even wrong because it makes
the tools think that something about the display has changed, like
zoom or scroll.
The flashing function checks for a non-empty queue by itself. Also
remove the timeout source explicitly in flush_event_queue() because it
might be called directly, and its FALSE return value has no effect on
the timeout source in that case.
This commit only adds the class and removes the members from
GimpDisplayShell, so everything looks more ugly than before, but
I wanted the member moving separate from any refactorings.
in order to be safe against whatever windowing system / event manager
depending event order. Also properly update the tool's state after a
button reelease, and after a space release.
