Ansel 0.0
A darktable fork - bloat + design vision
Loading...
Searching...
No Matches
input.h File Reference

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?
 

Detailed Description

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.

Function Documentation

◆ dt_control_button_down()

gboolean dt_control_button_down ( int  which)

Is mouse button which currently held down?

Parameters
which1 = left, 2 = middle, 3 = right, as in GdkEventButton.button.
Returns
TRUE while the button is physically down. Asked of GDK on every call, so it cannot be stale; FALSE when there is no display, no seat or no pointer (headless included).

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().