* Sam Bromley <s.@sb.com>
| (Tcl 8.6.10 on Ubuntu.)
--<snip-snip>--
| #!/usr/bin/env wish
| package require tkdnd
| button .b1 -text b1
| frame .f
| button .f.b2 -text b2
| pack .b1 -side top
| pack .f.b2 -side top
| pack .f -side top
| tkdnd::drop_target register .b1 *
| tkdnd::drop_target register .f.b2 *
| bind .b1 <<DropEnter>> {puts stderr "%W received DropEnter"}
| bind .f.b2 <<DropEnter>> {puts stderr "%W never receives DropEnter"}
How are the Drop Events initiated/generated?
Inside the same application (how)?
External source (which)?
R'
Hi everyone.I wonder if this is a stacking order issue because you're packing .f.b2 before you pack .f? Have you tried reversing these, or [raise]ing .f.b2, to see if this makes a difference?
I'm having difficulty using tkdnd with nested widgets, and I'm wondering if someone would have some kind insight to share.
Below is a minimal example where button .b1 will receive Drop events, but button .f.b2 will not. I'm wondering (1) why not? and (2) can I change the bindtags, or something else, to get nested widgets to work with tkdnd?
(Tcl 8.6.10 on Ubuntu.)
Thanks!
Sam
#!/usr/bin/env wish
package require tkdnd
button .b1 -text b1
frame .f
button .f.b2 -text b2
pack .b1 -side top
pack .f.b2 -side top
pack .f -side top
tkdnd::drop_target register .b1 *
tkdnd::drop_target register .f.b2 *
bind .b1 <<DropEnter>> {puts stderr "%W received DropEnter"}
bind .f.b2 <<DropEnter>> {puts stderr "%W never receives DropEnter"}
On Sunday, 4 December 2022 at 23:52:09 UTC, sbr...@sb.com wrote:
Hi everyone.
I'm having difficulty using tkdnd with nested widgets, and I'm wondering if someone would have some kind insight to share.
Below is a minimal example where button .b1 will receive Drop events, but button .f.b2 will not. I'm wondering (1) why not? and (2) can I change the bindtags, or something else, to get nested widgets to work with tkdnd?
(Tcl 8.6.10 on Ubuntu.)
Thanks!
Sam
#!/usr/bin/env wishI wonder if this is a stacking order issue because you're packing .f.b2 before you pack .f? Have you tried reversing these, or [raise]ing .f.b2, to see if this makes a difference?
package require tkdnd
button .b1 -text b1
frame .f
button .f.b2 -text b2
pack .b1 -side top
pack .f.b2 -side top
pack .f -side top
tkdnd::drop_target register .b1 *
tkdnd::drop_target register .f.b2 *
bind .b1 <<DropEnter>> {puts stderr "%W received DropEnter"}
bind .f.b2 <<DropEnter>> {puts stderr "%W never receives DropEnter"}
On Monday, December 5, 2022 at 7:47:59 PM UTC-3:30, Mike Griffiths wrote:
On Sunday, 4 December 2022 at 23:52:09 UTC, sbr...@sb.com wrote:
Hi everyone.
I'm having difficulty using tkdnd with nested widgets, and I'm wondering if someone would have some kind insight to share.
Below is a minimal example where button .b1 will receive Drop events, but button .f.b2 will not. I'm wondering (1) why not? and (2) can I change the bindtags, or something else, to get nested widgets to work with tkdnd?
(Tcl 8.6.10 on Ubuntu.)
Thanks!
Sam
Hi Mike,#!/usr/bin/env wishI wonder if this is a stacking order issue because you're packing .f.b2 before you pack .f? Have you tried reversing these, or [raise]ing .f.b2, to see if this makes a difference?
package require tkdnd
button .b1 -text b1
frame .f
button .f.b2 -text b2
pack .b1 -side top
pack .f.b2 -side top
pack .f -side top
tkdnd::drop_target register .b1 *
tkdnd::drop_target register .f.b2 *
bind .b1 <<DropEnter>> {puts stderr "%W received DropEnter"}
bind .f.b2 <<DropEnter>> {puts stderr "%W never receives DropEnter"}
I've tested the permutations of the packing order. The same behaviour persists, independent of packing order, that is, only the immediate children of the toplevel "." receive <<Drop>>-related events.
Georgios Petasis, if you are monitoring this list, would you happen to know whether there is a work-around to ensure that external <<Drop>> events can propagate to nested widgets?
I suspect it might have something to do with these events not propagating to or through the frame widget?
Note, that if I create another button .b3, directly parented in ".", but pack it into .f, then this button WILL receive events. So it has something do to with the widget path name, rather than the packing.
The following example, including the original pattern and extended with .b3, is shown for completeness:
#!/usr/bin/env wish
package require tkdnd
button .b1 -text b1;
frame .f;
button .f.b2 -text b2;
button .b3 -text b3;
pack .b1 -side top;
pack .f -side top
pack .f.b2 -side top;
pack .b3 -in .f -side top;
tkdnd::drop_target register .b1 *
tkdnd::drop_target register .f.b2 *
tkdnd::drop_target register .b3 *
bind .b1 <<DropEnter>> {puts stderr "%W received DropEnter"}
bind .f.b2 <<DropEnter>> {puts stderr "%W never receives DropEnter"}
bind .b3 <<DropEnter>> {puts stderr "%W receives DropEnter"}
Kindest regards,
Sam
On Monday, December 5, 2022 at 7:47:59 PM UTC-3:30, Mike Griffiths wrote:
On Sunday, 4 December 2022 at 23:52:09 UTC, sbr...@sb.com wrote:
Hi everyone.I wonder if this is a stacking order issue because you're packing .f.b2 before you pack .f? Have you tried reversing these, or [raise]ing .f.b2, to see if this makes a difference?
I'm having difficulty using tkdnd with nested widgets, and I'm wondering if someone would have some kind insight to share.
Below is a minimal example where button .b1 will receive Drop events, but button .f.b2 will not. I'm wondering (1) why not? and (2) can I change the bindtags, or something else, to get nested widgets to work with tkdnd?
(Tcl 8.6.10 on Ubuntu.)
Thanks!
Sam
#!/usr/bin/env wish
package require tkdnd
button .b1 -text b1
frame .f
button .f.b2 -text b2
pack .b1 -side top
pack .f.b2 -side top
pack .f -side top
tkdnd::drop_target register .b1 *
tkdnd::drop_target register .f.b2 *
bind .b1 <<DropEnter>> {puts stderr "%W received DropEnter"}
bind .f.b2 <<DropEnter>> {puts stderr "%W never receives DropEnter"}
Hi Mike,
I've tested the permutations of the packing order. The same behaviour persists, independent of packing order, that is, only the immediate children of the toplevel "." receive <<Drop>>-related events.
Georgios Petasis, if you are monitoring this list, would you happen to know whether there is a work-around to ensure that external <<Drop>> events can propagate to nested widgets?
I suspect it might have something to do with these events not propagating to or through the frame widget?
Note, that if I create another button .b3, directly parented in ".", but pack it into .f, then this button WILL receive events. So it has something do to with the widget path name, rather than the packing.
The following example, including the original pattern and extended with .b3, is shown for completeness:
#!/usr/bin/env wish
package require tkdnd
button .b1 -text b1;
frame .f;
button .f.b2 -text b2;
button .b3 -text b3;
pack .b1 -side top;
pack .f -side top
pack .f.b2 -side top;
pack .b3 -in .f -side top;
tkdnd::drop_target register .b1 *
tkdnd::drop_target register .f.b2 *
tkdnd::drop_target register .b3 *
bind .b1 <<DropEnter>> {puts stderr "%W received DropEnter"}
bind .f.b2 <<DropEnter>> {puts stderr "%W never receives DropEnter"}
bind .b3 <<DropEnter>> {puts stderr "%W receives DropEnter"}
Kindest regards,
Sam
On Monday, December 5, 2022 at 9:50:08 PM UTC-3:30, Sam Bromley wrote:on the toplevel further down, in a cal to XChangeProperty. Perhaps this is the reason why only direct children of the window receive the Xdnd events? I'm not very familiar with Xlib programming. Does anyone here know whether it is ok to call
On Monday, December 5, 2022 at 7:47:59 PM UTC-3:30, Mike Griffiths wrote: >>> On Sunday, 4 December 2022 at 23:52:09 UTC, sbr...@sb.com wrote:
Hi Mike,Hi everyone.I wonder if this is a stacking order issue because you're packing .f.b2 before you pack .f? Have you tried reversing these, or [raise]ing .f.b2, to see if this makes a difference?
I'm having difficulty using tkdnd with nested widgets, and I'm wondering if someone would have some kind insight to share.
Below is a minimal example where button .b1 will receive Drop events, but button .f.b2 will not. I'm wondering (1) why not? and (2) can I change the bindtags, or something else, to get nested widgets to work with tkdnd?
(Tcl 8.6.10 on Ubuntu.)
Thanks!
Sam
#!/usr/bin/env wish
package require tkdnd
button .b1 -text b1
frame .f
button .f.b2 -text b2
pack .b1 -side top
pack .f.b2 -side top
pack .f -side top
tkdnd::drop_target register .b1 *
tkdnd::drop_target register .f.b2 *
bind .b1 <<DropEnter>> {puts stderr "%W received DropEnter"}
bind .f.b2 <<DropEnter>> {puts stderr "%W never receives DropEnter"}
I've tested the permutations of the packing order. The same behaviour persists, independent of packing order, that is, only the immediate children of the toplevel "." receive <<Drop>>-related events.
Georgios Petasis, if you are monitoring this list, would you happen to know whether there is a work-around to ensure that external <<Drop>> events can propagate to nested widgets?
I suspect it might have something to do with these events not propagating to or through the frame widget?
Note, that if I create another button .b3, directly parented in ".", but pack it into .f, then this button WILL receive events. So it has something do to with the widget path name, rather than the packing.
The following example, including the original pattern and extended with .b3, is shown for completeness:
#!/usr/bin/env wish
package require tkdnd
button .b1 -text b1;
frame .f;
button .f.b2 -text b2;
button .b3 -text b3;
pack .b1 -side top;
pack .f -side top
pack .f.b2 -side top;
pack .b3 -in .f -side top;
tkdnd::drop_target register .b1 *
tkdnd::drop_target register .f.b2 *
tkdnd::drop_target register .b3 *
bind .b1 <<DropEnter>> {puts stderr "%W received DropEnter"}
bind .f.b2 <<DropEnter>> {puts stderr "%W never receives DropEnter"}
bind .b3 <<DropEnter>> {puts stderr "%W receives DropEnter"}
Kindest regards,
Sam
Hi folks,
I've been looking into the TkDND source code on github. In the "unix/TkDND_XDND.c" file, I see that "TKDND_SET_XDND_PROPERTY_ON_TOPLEVEL" is defined, but "TKDND_SET_XDND_PROPERTY_ON_TARGET" is not. This causes the "XdndAware" property to be set solely
Thanks in advance for any insight you can share.
Sam
Dear Sam,
If you use as a source a Tk app, is it working?
Regards,
Georgios
On Tuesday, December 6, 2022 at 10:57:41 AM UTC-3:30, Georgios Petasis wrote:<<Drop>> event is observed by the Source process, but not by the Target process. This happens whenever I release the mouse button, wherever the pointer is located, as expected I suppose.
Dear Sam,
If you use as a source a Tk app, is it working?
Regards,
Georgios
Hi Georgios,
Thanks so much for reaching out. To answer your question, I made use of the examples at https://wiki.tcl-lang.org/page/TkDND+Tutorial
and modified the "Destination/Target" example to pack the "target button" into a frame, rather than have it packed directly into the toplevel. I then used the "Source" example to initiate a drag event to that target button.
The behaviour was identical to that of when I drag from the external (file manager) source. That is, the Drop events no longer appear to be received by the target button, nor reported. I do note, however, that when I release the button here, the single
For completeness, if I use the original "Target" example, and leave the "target button" packed directly into ".", and then drag from, say, the "Drop_Source_Files" button of the "Source" wish process, the <<Drop::DND_Files>> event does get recognized/triggered. Not so once the target button is packed one layer down through an intermediate frame widget.
I hope this helps!
Thanks so much for your time thinking on this.
Sam
Hi George,single <<Drop>> event is observed by the Source process, but not by the Target process. This happens whenever I release the mouse button, wherever the pointer is located, as expected I suppose.
Thank you for looking further into this.
As per your suggestion, I downloaded and built the latest version of tkdnd from github (tkdnd2.9.3).
This version works perfectly. Thank you. And I do apologize for not having pulled the most recent version sooner.
I was using the version that ships with Ubuntu 20.04.3, which is tkdnd 2.6.1.
I'd like to extend a huge thank you again to you and to the wonderful kindness of the Tcl Community.
Kindest regards,
Sam
On Saturday, December 10, 2022 at 2:56:16 PM UTC-3:30, Georgios Petasis wrote:
Dear Sam,
I am afraid I cannot reproduce the issue. If you look at the image, I
have added a frame around the drop target, and I am able to drop things from both the tkdnd source and the gnome file explorer.
https://www.dropbox.com/s/lpomeu5pb0y5pz3/vncviewer_2022-12-10_20-12-48.png?dl=0
Can you please check your tkdnd version?
If you compile from the latest sources, does it work?
I have committed the changes to demos/simple_target.tcl.
I think it is better to open a ticket at github: https://github.com/petasis/tkdnd
Best regards,
George
Στις 6/12/2022 23:24, ο/η Sam Bromley έγραψε:
On Tuesday, December 6, 2022 at 10:57:41 AM UTC-3:30, Georgios Petasis wrote:
Dear Sam,
If you use as a source a Tk app, is it working?
Regards,
Georgios
Hi Georgios,
Thanks so much for reaching out. To answer your question, I made use of the examples at https://wiki.tcl-lang.org/page/TkDND+Tutorial
and modified the "Destination/Target" example to pack the "target button" into a frame, rather than have it packed directly into the toplevel. I then used the "Source" example to initiate a drag event to that target button.
The behaviour was identical to that of when I drag from the external (file manager) source. That is, the Drop events no longer appear to be received by the target button, nor reported. I do note, however, that when I release the button here, the
recognized/triggered. Not so once the target button is packed one layer down through an intermediate frame widget.For completeness, if I use the original "Target" example, and leave the "target button" packed directly into ".", and then drag from, say, the "Drop_Source_Files" button of the "Source" wish process, the <<Drop::DND_Files>> event does get
I hope this helps!
Thanks so much for your time thinking on this.
Sam
Dear Sam,single <<Drop>> event is observed by the Source process, but not by the Target process. This happens whenever I release the mouse button, wherever the pointer is located, as expected I suppose.
I am afraid I cannot reproduce the issue. If you look at the image, I
have added a frame around the drop target, and I am able to drop things
from both the tkdnd source and the gnome file explorer.
https://www.dropbox.com/s/lpomeu5pb0y5pz3/vncviewer_2022-12-10_20-12-48.png?dl=0
Can you please check your tkdnd version?
If you compile from the latest sources, does it work?
I have committed the changes to demos/simple_target.tcl.
I think it is better to open a ticket at github: https://github.com/petasis/tkdnd
Best regards,
George
Στις 6/12/2022 23:24, ο/η Sam Bromley έγραψε:
On Tuesday, December 6, 2022 at 10:57:41 AM UTC-3:30, Georgios Petasis wrote:
Dear Sam,
If you use as a source a Tk app, is it working?
Regards,
Georgios
Hi Georgios,
Thanks so much for reaching out. To answer your question, I made use of the examples at https://wiki.tcl-lang.org/page/TkDND+Tutorial
and modified the "Destination/Target" example to pack the "target button" into a frame, rather than have it packed directly into the toplevel. I then used the "Source" example to initiate a drag event to that target button.
The behaviour was identical to that of when I drag from the external (file manager) source. That is, the Drop events no longer appear to be received by the target button, nor reported. I do note, however, that when I release the button here, the
triggered. Not so once the target button is packed one layer down through an intermediate frame widget.For completeness, if I use the original "Target" example, and leave the "target button" packed directly into ".", and then drag from, say, the "Drop_Source_Files" button of the "Source" wish process, the <<Drop::DND_Files>> event does get recognized/
I hope this helps!
Thanks so much for your time thinking on this.
Sam
Dear Sam,
I am afraid I cannot reproduce the issue. If you look at the image, I have added a frame around the drop target, and I am able to drop things from both the tkdnd source and the gnome file explorer.
https://www.dropbox.com/s/lpomeu5pb0y5pz3/vncviewer_2022-12-10_20-12-48.png?dl=0
Can you please check your tkdnd version?
If you compile from the latest sources, does it work?
I have committed the changes to demos/simple_target.tcl.
I think it is better to open a ticket at github: https://github.com/petasis/tkdnd
Best regards,
George
Στις 6/12/2022 23:24, ο/η Sam Bromley έγραψε:single <<Drop>> event is observed by the Source process, but not by the Target process. This happens whenever I release the mouse button, wherever the pointer is located, as expected I suppose.
On Tuesday, December 6, 2022 at 10:57:41 AM UTC-3:30, Georgios Petasis wrote:
Dear Sam,
If you use as a source a Tk app, is it working?
Regards,
Georgios
Hi Georgios,
Thanks so much for reaching out. To answer your question, I made use of the examples at https://wiki.tcl-lang.org/page/TkDND+Tutorial
and modified the "Destination/Target" example to pack the "target button" into a frame, rather than have it packed directly into the toplevel. I then used the "Source" example to initiate a drag event to that target button.
The behaviour was identical to that of when I drag from the external (file manager) source. That is, the Drop events no longer appear to be received by the target button, nor reported. I do note, however, that when I release the button here, the
triggered. Not so once the target button is packed one layer down through an intermediate frame widget.
For completeness, if I use the original "Target" example, and leave the "target button" packed directly into ".", and then drag from, say, the "Drop_Source_Files" button of the "Source" wish process, the <<Drop::DND_Files>> event does get recognized/
I hope this helps!
Thanks so much for your time thinking on this.
Sam
Hi Georgios,
are you planning to release or tag an "official" 2.7.3 version in the
near future?
I'm currently preparing a new BAWT release with Tcl/Tk 8.6.13 and
up-to-date packages.
Regards,
Paul
Dear Sam,
I am afraid I cannot reproduce the issue. If you look at the image, I
have added a frame around the drop target, and I am able to drop
things from both the tkdnd source and the gnome file explorer.
https://www.dropbox.com/s/lpomeu5pb0y5pz3/vncviewer_2022-12-10_20-12-48.png?dl=0
Can you please check your tkdnd version?
If you compile from the latest sources, does it work?
I have committed the changes to demos/simple_target.tcl.
I think it is better to open a ticket at github:
https://github.com/petasis/tkdnd
Best regards,
George
Στις 6/12/2022 23:24, ο/η Sam Bromley έγραψε:
On Tuesday, December 6, 2022 at 10:57:41 AM UTC-3:30, Georgios
Petasis wrote:
Dear Sam,
If you use as a source a Tk app, is it working?
Regards,
Georgios
Hi Georgios,
Thanks so much for reaching out. To answer your question, I made use
of the examples at https://wiki.tcl-lang.org/page/TkDND+Tutorial
and modified the "Destination/Target" example to pack the "target
button" into a frame, rather than have it packed directly into the
toplevel. I then used the "Source" example to initiate a drag event
to that target button.
The behaviour was identical to that of when I drag from the external
(file manager) source. That is, the Drop events no longer appear to
be received by the target button, nor reported. I do note, however,
that when I release the button here, the single <<Drop>> event is
observed by the Source process, but not by the Target process. This
happens whenever I release the mouse button, wherever the pointer is
located, as expected I suppose.
For completeness, if I use the original "Target" example, and leave
the "target button" packed directly into ".", and then drag from,
say, the "Drop_Source_Files" button of the "Source" wish process, the
<<Drop::DND_Files>> event does get recognized/triggered. Not so once
the target button is packed one layer down through an intermediate
frame widget.
I hope this helps!
Thanks so much for your time thinking on this.
Sam
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 493 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 183:26:11 |
| Calls: | 9,705 |
| Files: | 13,737 |
| Messages: | 6,179,547 |
