Hi Brian,
Thanks for submitting a patch for this issue. I hope Petr, who is more
familiar with the SWT_AWT bridge, could also take a look at this fix.
Note that you should base your patch on JDK 8 sources as initially a bug
should be fixed in a development release. Only then can we consider
porting it to an update release.
Some comments:
1. Java Plugin uses the XEmbeddedFramePeer as well. If you substitute
this class in the rt.jar with a copy containing your changes, how does
it affect applets that allow users to DnD? (such applets should be
signed, obviously, because unsigned applets can't do DnD). This needs to
be tested thoroughly to ensure we don't introduce a regression. If there
was a way to detect that only a specific (swt-managed) XEFP really needs
this additional processing, this might even be better, although I don't
see a way to implement this easily. Also, running AWT DnD regression
tests could be useful (see jdk/test/java/awt/ in the repo).
2. You should document the newly added boolean field and new methods
with javadocs.
3. Could you please elaborate on the root cause of the issue? What code
does call the addDropTarget() initially for an XEmbeddedFramePeer
instance, and why exactly does it not get called for other instances of
the peer class? BTW, why can't this be implemented on the SWT side of
the bridge when processing regular focus events?
4. Should we protect from multiple calls to the registerDropTarget()
just in case, or is it safe to register the same window multiple times?
5. All debugging println's should be removed from the patch.
6. Please add @Override annotations to methods that you override.
7. Formatting issues: you should add spaces after the "if" keywords.
Also, the statements should either be one-liners w/o a {} block, or the
blocks should be spread over multiple lines.
--
best regards,
Anthony
On 09/05/2013 01:00 AM, Brian de Alwis wrote:
I'm helping with an Eclipse-based project that uses Eclipse's SWT_AWT facility
to embed Swing within SWT. SWT_AWT uses an embedded frame to host Swing/AWT
content. In this application, we frequently have several SWT_AWT-based editors
open simultaneously, that support drag-and-drop, and have been hitting bug
6640765 (Eclipse bug 141893 [1]). This is a Linux-specific bug where drops,
when displaying several SWT_AWT embedded-frames, use the wrong frame.
The original reporter on the Eclipse bug report identified the problem as
something to do with XEmbeddedFramePeer. I've tried to come up with a patch
that solves the issue against JDK7 (attached). I'm not very confident of the
patch's correctness, but it seems to work in my application workflows. I found
I had to ensure that only a single embedded frame was registered as a drop
target site.
I fully admit that I am neither a proficient AWT hacker, nor with deep
understanding of X11 DND. Could someone with X11/AWT background provide some
guidance as to whether this seems like a worthy fix, and pointers for how to
build a unit test for this behaviour?
Brian.
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=141893
