![]() |
Ansel 0.0
A darktable fork - bloat + design vision
|
Which mouse buttons are held, asked of the toolkit rather than remembered. More...
#include <glib.h>
Include dependency graph for input.h:
This graph shows which files directly or indirectly include this file:Go to the source code of this file.
Functions | |
| gboolean | dt_control_button_down (int which) |
Is mouse button which currently held down? | |
Which mouse buttons are held, asked of the toolkit rather than remembered.
dt_control_t used to carry ‘button_down’ and ‘button_down_which’, written by our button-press and button-release handlers and read by drag state machines in the darkroom, in crop, clipping and vignette. That is a copy of something GDK already knows: the pointer's button mask is device state, available at any moment.
A copy of live state has to be refreshed to stay true, and is wrong in between. Every reader consulted it in the middle of a drag, so a missed release – a broken grab, a window switch, a crash in a handler between press and release – left a stuck drag that nothing would clear until the next press. Asking the source cannot go stale.
views/darkroom.c already made the point on its own: at darkroom.c:2433 it calls gdk_window_get_device_position() for the pointer position and passes NULL for the fifth argument – the GdkModifierType out-param that carries exactly these bits – and then read the stored copy instead.
NOTE what is deliberately NOT here. ‘button_x’/‘button_y’ are the position at PRESS time, an anchor a drag measures against; GDK can say where the pointer is, never where it went down, so that is real remembered state and belongs to whoever is dragging (views/darkroom.c is the only user, and writes them itself). ‘button_type’ – single/double/triple click – is an event classification GDK computes when delivering the event and does not expose as device state; it had no reader at all and is gone.
Definition in file input.h.
| gboolean dt_control_button_down | ( | int | which | ) |
Is mouse button which currently held down?
| which | 1 = left, 2 = middle, 3 = right, as in GdkEventButton.button. |
This reports the DEVICE's state, not "a drag we started". A button pressed over another window and still held when the pointer enters ours reads TRUE here, where the old stored flag – set only by our own press handler – read FALSE. Every current caller pairs it with its own grab or hover test, so the distinction does not reach behaviour; a new caller that needs "did the press land on us" wants a press handler, not this.
Definition at line 563 of file control.c.
References dt_gui_center_widget(), FALSE, IS_NULL_PTR, and window.
Referenced by gui_post_expose(), mouse_leave(), mouse_moved(), and mouse_moved().