[ Return to Bugs & Features | Post Text | Post File | Prev | Next ]
|Status:||5 - New|
|Priority:||4 - High, e.g. key functionality not working|
|Scope:||2 - Specific to an operating system|
|Summary:||X11 Drag and drop issue when displaying popup on recept of payload|
Trouble Report Files:
[ Post File ]
Trouble Report Comments:
[ Post Text ]
09:03 Sep 09, 2017
|As requested, opening a STR from the discussion "Drag and drop issue - [General Use]" on fltkgeneral: |
The OP (Nimday Satria) tried to display a message in the handle() routine of the "howto-drag-and-drop" example when the FL_PASTE event was delivered. This resulted in a deadlock.
I found a patch for that, which is attached as "dnd_internal.txt".
First resume from Albrecht Schlosser on the patch was (citing from thread):
"I think this solution is correct and that there are no side effects to
be expected. Basically the *only* thing that is changed is that the
fl_local_grab = 0;
is executed right before calling Fl::paste() instead of (or, to be
precise: additional to) right after Fl::paste(). This enables normal
event processing during FL_PASTE whereas the code as it is now would
ignore all events during FL_PASTE processing.
AFAICT this is what happens:
During DND operations fl_local_grab, which is used only under X,
contains a function pointer to the static function grabfunc() which
makes the event delivery *ignore* all events except mouse button release
(FL_RELEASE) . If grabfunc() is called with a FL_RELEASE event it
sets Fl::pushed(0), which in turn makes the DND loop terminate and
deliver the payload with Fl::paste() -- after asking the target
window/widget if it accepts it with FL_DND_RELEASE -- otherwise the
payload is ignored.
Since we are here at the point where Fl::paste() is called we know that
the mouse button has already been released and we can safely clear
fl_local_grab to enable normal event processing during delivery of the
DND payload with the FL_PASTE event."
Later Albrecht discovered, that dragging from some external applications (CodeLite in this case) into the example program led to hanging key and mouse in the external application after the example popped up the message.
I found a patch for this too, which I attach as "dnd_external.txt".
Citing my resume on this patch:
"I found out, that the drop from CodeLite (or any other external source)
runs through Fl_x.cxx line 1413:
int retval = fl_selection_requestor->handle(Fl::e_number = FL_PASTE);
Immediately after is a code section flagged by a comment about sending
the XdndFinished message here or maybe earlier.
I assume, that CodeLite is duly confirming to the protocol and waits for
the finished message to arrive, before declaring the drop event done.
But if FLTK pops up a message it will reach the code that sends this
message only *after* the popup is dismissed and then it may be already
too late for CodeLite. Other applications perhaps are more tolerant
about the arrival of the XdndFinished event. However these are just
But they lead to the thought, that maybe FLTK could send the
XdndFinished message *before* doing the paste (just in case the
application pops up a message)."
[ Return to Bugs & Features | Post Text | Post File ]