On Wed, 20 Jan 2021 01:59:39 GMT, Sergey Bylokhov <s...@openjdk.org> wrote:
>> I failed to test branches of XDnDDropTargetProtocol::processXdndPosition(..)
>> under condition (xwindow == null) by means of EmbeddedFrame. In addition
>> none of automatic regression tests (test/jdk/java/awt/dnd/,
>> test/jdk/java/awt/xembed/, test/jdk/sun/awt) gets into these branches.
>>
>> I also tried to scale coordinates (as you advised) right after:
>> x = (int)(xclient.get_data(2) >> 16);
>> y = (int)(xclient.get_data(2) & 0xFFFF);
>> as follow:
>> GraphicsConfiguration gc = GraphicsEnvironment
>> .getLocalGraphicsEnvironment()
>> .getDefaultScreenDevice()
>> .getDefaultConfiguration();
>> gc = SunGraphicsEnvironment.getGraphicsConfigurationAtPoint(gc, x,
>> y);
>> GraphicsDevice device = gc.getDevice();
>> if (device instanceof X11GraphicsDevice) {
>> int scale = ((X11GraphicsDevice) device).getScaleFactor();
>> x = XlibUtil.scaleDown(x, scale);
>> y = XlibUtil.scaleDown(y, scale);
>> }
>>
>> but found out that getGraphicsConfigurationAtPoint() also requires the
>> already scaled coordinates.
>>
>> There are 3 different places in
>> XDnDDropTargetProtocol::processXdndPosition(..) where it is necessary to
>> decide whether to scale coordinates or not:
>> 1) I'm not sure and I'm unable to test it:
>> if (xwindow == null)
>> {
>> long receiver =
>> XDropTargetRegistry.getRegistry().getEmbeddedDropSite(
>> xclient.get_window(), x, y);
>> 2) I'm quite sure and I'm able to test it:
>> if (xwindow != null) {
>> /* Translate mouse position from root coordinates
>> to the target window coordinates. */
>> Point p = xwindow.toLocal(xwindow.scaleDown(x),
>> xwindow.scaleDown(y));
>> 3) I think that scaling is necessary but I'm unable to test it (additionally
>> the question raises concerning this case, why the coordinates are not
>> converted to local here similar to the 2 case):
>> if (xwindow == null) {
>> if (targetXWindow != null) {
>> notifyProtocolListener(targetXWindow, x, y,
>> DnDConstants.ACTION_NONE, xclient,
>> MouseEvent.MOUSE_EXITED);
>>
>> Sergey, is it possible at the moment to fix the particular issue and leave
>> the other use cases to work as it works before due to no possibility to test
>> them?
>
>> There are 3 different places in
>> XDnDDropTargetProtocol::processXdndPosition(..) where it is necessary to
>> decide whether to scale coordinates or not:
>
> Unfortunately, this is the purpose of the whole fix to decide when the scale
> is required and then not, otherwise we can simply break the untested cases.
Sergey, please, review my last changes! Finally I managed to check all
necessary branches in XDnDDropTargetProtocol::processXdndPosition(..). The
user's space (the scaled version of the device) must be used everywhere here. I
had to devide scaling according to condition (xwindow != null) in order to use
more simple and fast realization for most of cases. The scaling for the case
(xwindow == null) related to the embedded frame is based on the idea that there
is only one pointer (cursor) in the system and it is used for drag-n-drop
operation. I tried different ways to get scale in the last case but only this
one is workable. If you have some better idea, tell me, please, another way to
do it!
-------------
PR: https://git.openjdk.java.net/jdk/pull/1907
