freenode/#clim - IRC Chatlog
Search
12:44:47
jackdaniel
from my testing grabbing pointer was only making whole window manager unresponsive until tracking-pointer body was finished
12:46:01
jackdaniel
if we want to have tracking-pointer as a building block for event-queue processing (i.e with-input-context could be built on top of it) then it can't grab the pointer
13:03:09
scymtym
gtk apparently has two kinds of grabs. widget-level and window-level. both are apparently used to prevent undesired interaction with other widgets/windows while dragging
13:05:41
jackdaniel
I can re-add pointer-grab to the port protocol, but I have strong conviction that tracking-pointer shouldn't call it. if at all it should be drag-output-record who calls it before invoking tracking-pointer.
13:12:51
scymtym
i'm honestly not sure what the right solution is. but i would prefer keeping the machinery until we know
13:17:22
scymtym
seems like the best solution for now. but as i said, there is also the part where the port distributes events differently based on the grab. i would like to understand why they did that
13:26:50
scymtym
i think i understand the X-level grab now. consider a zoomed-in image in GIMP. if you use any tool that involves dragging, you can drag the pointer the visible region of the image and even outside the GIMP window and it will continue dragging. which is convenient since you don't have to zoom out, do the thing, zoom in again
13:27:30
scymtym
but i agree that tracking-pointer is too fundamental for hard-coding the grabbing behavior
13:28:25
jackdaniel
try draggable-graph demo: when you have the pointer pressed the focus is grabbed
13:33:25
scymtym
i'm not sure i understand. should i use the fix-drag-and-drop branch for this test? should i press and hold the left pointer button and drag the pointer outside the frame and notice how it will continue dragging?