Yes, they (the methods mentioning Peer) should be renamed.
Qn. to Mandy & Alan : it seems there is no need to mention this module
in make/common/Modules.gmk in order to get it built, but is there any
advantage in doing so ? I mean without it, there is no conscious listing of
it as a module nor classification of it.
Another thing that Kevin & I touched on in conversation is that it seems
doclint fail on warning must be disabled by default .. and I suppose that
is what we want here since documentation is minimal.
-phil.
On 5/9/18, 5:28 AM, Kevin Rushforth wrote:
The following can also be abstract:
LightweightContentWrapper:
getComponent, createDragGestureRecognizer, createDragSourceContextPeer
DropTargetContextWrapper:
getTargetActions, getDropTarget, getTransferDataFlavors,
getTransferable, isTransferableJVMLocal
DispatcherWrapper:
isDispatchThread, createSecondaryLoop
The rest looks good to me (although I still see two public methods
with "Peer" in the name, so Phil may want those renamed).
-- Kevin
On 5/9/2018 2:14 AM, Prasanta Sadhukhan wrote:
Modified webrev to cater to these 3 observations
http://cr.openjdk.java.net/~psadhukhan/fxswing.11/
Regards
Prasanta
On 5/9/2018 5:03 AM, Kevin Rushforth wrote:
The module definition for jdk.unsupported.desktop and the changes to
java.desktop look fine.
In reviewing the jdk.swing.interop API, I have the following
suggestions / observations:
1. DispatcherWrapper, DragSourceContextWrapper,
DropTargetContextWrapper, and LightweightContentWrapper can all be
abstract, along with most of the methods (rather than having an
empty body return value that is never used).
2. The addNotify method in LightweightFrameWrapper is unused. Should
be used somewhere? If not, then it can be removed.
The implementation of the new wrapper classes looks OK to me with
one observation that might or might not matter:
3. The behavior of getDefaultScaleX/Y (which is now in
SwingInteropUtils) has changed in the case where the Graphics is not
an instance of SunGraphics2D. The former behavior was to leave the
instance variables X and Y unchanged. The new behavior will set them
back to 1.0. Maybe this can't happen in practice, but it is
something to consider.
-- Kevin
On 5/8/2018 3:31 AM, Alan Bateman wrote:
On 08/05/2018 06:51, Prasanta Sadhukhan wrote:
Modified webrev to rename to InteropProviderImpl
http://cr.openjdk.java.net/~psadhukhan/fxswing.10/
This looks okay to me.
-Alan
