freenode/#clim - IRC Chatlog
Search
11:29:39
jackdaniel
scymtym: I've looked into the code, but the scope of it is quite big, so my remarks may be very shallow due to lack of deeper udnerstanding
11:42:13
scymtym
jackdaniel: that's probably fine. the inspector is not an integral component or anything
12:20:19
jackdaniel
scymtym: n.b with my changed without ponter grab dragging between frames *does* work
12:20:53
jackdaniel
try opening two dnd various instances and drag square between both frames, you'll be able to drop it on the square-basket
12:21:59
jackdaniel
the only difference is that while using tracking-pointer you do not hog away the pointer from other applications (i.e emacs)
12:32:19
scymtym
if i read the code correctly, pointer grabbing has to components: 1) X level via xlib:grab-pointer 2) event distribution to sheets by the port
12:33:37
scymtym
i imagine 1) was maybe intended so that e.g. your window manager with focus-follows-policy does not de-focus your CLIM frame while dragging between frames, but i don't really know
12:34:20
scymtym
2) looks like it is intended to prevent bogus enter/exit events while dragging, but i again don't really know
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?