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 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"}

* Sam Bromley <sbromle@sambromley.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'

On Monday, December 5, 2022 at 6:51:52 AM UTC-3:30, Ralf Fassel wrote:
> * 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'

Sorry for leaving that out. The events are coming
from an external source, a graphical file manager under Gnome.
The external source delivers the other events (Drop:DND_Files for example) successfully to the widgets directly below the top-level.
Sam

On Sunday, 4 December 2022 at 23:52:09 UTC, sbr...@sambromley.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 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 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?

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
> >
> > #!/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 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?

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 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
> > >
> > > #!/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 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?
> 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

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 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 XChangeProperty on the target (a "sub-window") under X and have Xdnd work on it? Should/can the Xdnd property be set on both the toplevel and the subwindow (button)?
Thanks in advance for any insight you can share.
Sam

Dear Sam,

Yes, these options are there, but I think that according to the specs,
only the toplevel window must have the property.

Best regards,

George

Στις 6/12/2022 04:36, ο/η Sam Bromley έγραψε:
> On Monday, December 5, 2022 at 9:50:08 PM UTC-3:30, Sam Bromley wrote:
>> 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
>>>>
>>>> #!/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 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?
>> 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
>
> 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 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 XChangeProperty on the target (a "sub-window") under X and have Xdnd work on it? Should/can the Xdnd property be set on both the toplevel and the subwindow (button)?
> 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,

George

Στις 6/12/2022 03:20, ο/η Sam Bromley έγραψε:
> 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
>>>
>>> #!/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 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?
>
> 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 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

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

Hi George,

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 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

George -> Georgios. So sorry for having missed that, right at the end. Doh.
Sam

On Saturday, December 10, 2022 at 4:54:38 PM UTC-3:30, Sam Bromley wrote:
> Hi George,
>
> 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 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

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
>

Dear Paul,

I have added the tag tkdnd-release-test-v2.9.3 to the repository.

Regards,

George

Στις 11/12/2022 00:21, ο/η Paul Obermeier έγραψε:
> 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
>>
>