Fails if drop widget is on a notebook page
Brought to you by:
petasis
Menu
▾
▴
#27 Fails if drop widget is on a notebook page
For instance if I go...
% package require tkdnd 2.6
2.6
% pack [::ttk::notebook .n]
% .n add [text .n.t] -text "Target area"
% tkdnd::drop_target register .n.t DND_Text
...I do not see the "copy" cursor come up when I drag into the text widget, as I would if it was packed in the top level window. And of course the bindings do not get executed.
Just found that it _does_ work if the target widget is a sibling of the notebook rather than a child!
In fact it appears that it does not work on any widget except children of a top-level window -- so if you have a frame with a text widget inside, you cannot register the text widget for drops. Have raised priority accordingly.
This bug seems to be exclusive to the x11 display type -- it all works OK in Windows
That's worth one less priority point!
I confirm the problem of no drops on non-root widgets on unix. Here is my patch, which I think may be getting some coordinates wrong but it's certainly better than not having any support for child widgets:
--- trunk/library/tkdnd_unix.tcl (revision 95)
+++ trunk/library/tkdnd_unix.tcl (working copy)
@@ -82,6 +83,15 @@
return default
};# xdnd::_HandleXdndEnter
+
+proc xdnd::_pointWithinWindow {win rootX rootY} {
+ set x [winfo rootx $win]
+ set y [winfo rooty $win]
+ set w [winfo width $win]
+ set h [winfo height $win]
+ return [expr "$rootX >= $x && $rootX < $x+$w && $rootY >= $y && $rootY < $y+$w"]
+}
+
# ----------------------------------------------------------------------------
# Command xdnd::_HandleXdndPosition
# ----------------------------------------------------------------------------
@@ -102,9 +112,19 @@
# debug "xdnd::_HandleXdndPosition: drop_target=$drop_target,\ # _drop_target=$_drop_target, rootX=$rootX, rootY=$rootY"
+ # drop_target may be a parent of the real target.
+
+ # this is all a workaround for 'winfo containing' never returning anything
+ set children [winfo children $drop_target]
+ foreach child $children {
+ if {[_pointWithinWindow $child $rootX $rootY]} {
+ return [_HandleXdndPosition $child $rootX $rootY $drag_source]
+ }
+ }
+
if {![info exists _drag_source] && ![string length $_drag_source]} {
@@ -179,15 +200,16 @@
set _action [uplevel \#0 $cmd]
}
}
set _drop_target $drop_target
}
set _action refuse_drop
- set _drop_target {}
if {[info exists common_drag_source_types]} {
set _action copy
set _common_drag_source_types $common_drag_source_types
set _common_drop_target_types $common_drop_target_types
set _drop_target $drop_target
## Drop target supports at least one type. Send a <<DropPosition>>.
set cmd [bind $drop_target <<DropPosition>>]
@@ -206,6 +228,10 @@
] $cmd]
set _action [uplevel \#0 $cmd]
}
+ } else {
+ # logic wasn't clear; i'm just guessing this should be the else-clause
+ set _drop_target {}
}
# Return values: copy, move, link, ask, private, refuse_drop, default
# debug "xdnd::_HandleXdndPosition: ACTION: $_action"
Shows text getting put into wrong entry widget
Sorry to say the server appears to have mangled the patch code with lots of line breaks, and I cannot apply it. Can you attach it as a file instead?
Have applied it manually, but still having problems. The attached short script creates a couple of entry widgets and enables drops into them, but the text always ends up in the top one even if dropped into the bottom one. Curiously, if the pack orientation of the test widgets is anything other than "top" it works OK.
Think I've solved it -- look closely at the lastr line of proc xdnd::_pointWithinWindow and you will discover a typo
Haha- I see it. I guess my widgets were a little more square-shaped than yours. Any idea how to make 'winfo containing' work? That seemed like a better solution, but it was never returning children.
'winfo containing' works just fine here. I'm using TclTk 8.5.9. Just confirmed it is OK with 8.5.11 and 8.5.13.
Think I've found the problem with using 'winfo containing'. This will return an empty string if another window is covering the point that you are testing. When you drag some text out of a browser, the text appears in a sort of transparent popup window and follows the cursor, thus covering the relevant bit of the drop target and preventing 'winfo containing' from working. I was dragging from links in order to drop URLs so I didn't have this problem. Looks like your recursive child selection method is best!
BTW how can we get the fix into the .deb for Ubuntu Raring?