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.
and simply *always* set the tool to the right state before sending it
a button_press. GimpTool's state setting functions are now smart
enough to simply ignore setting the same state again. When recieving a
FOCUS_IN, skip state setting when the pointer is grabbed, which is a
safe indicator for tool interaction going on. This hopefully fixes
states for both click-to-focus and focus-follows-mouse *and* fixes the
previously warning case where a new image was opened into an already
focussed canvas (the warning then happened on button press, and the
tool was in an inconsistent state).
- change gimp_devices_get_list() to gimp_devices_get_manager()
- remove gimp_devices_get_current()
- let GimpDeviceStatus connect to the manager's "notify::current-device"
directly and remove device status updating code from gui.c
- cleanup in gimpdevices.c
Keep the comment at the place where calling it isn't immediately
obvious, and add checks to proximity_in() and out() so they bail out
when the proximity state is already set correctly.
and use them instead of manually setting proximity. Also add comments
about why we call the proximity functions where we call them (instead
of calling them where it seems more logical).
Michael Natterer