<AWT Dev> [8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag.

Fri Aug 24 13:49:24 PDT 2012

Hi Alexander.
In the fix NSTrackingArea has NSTrackingCursorUpdate option but i did 
not see  cursorUpdate: method. Probably we can get some useful 
information from it?

24.08.2012 17:53, Alexander Scherbatiy пишет:
>
> Could you review the updated fix:
>   http://cr.openjdk.java.net/~alexsch/7171045/webrev.04/
> The comments are below:
>
> On 8/23/2012 4:51 PM, Anthony Petrov wrote:
>> Hi Alexandr,
>>
>> 1. In synthesizeMouseEnteredExitedEventsForAllWindows, can we iterate 
>> through app's windows only once and send both Exited and Entered 
>> events where needed?
>     Now, when we do not care about the order of the mouse enter/exit 
> events generation it is possible to do. I have updated the code.
>>
>> 2. Also, it looks like nativeSynthesizeMouseEnteredExitedEvents no 
>> longer requires a window pointer as an argument.
>        Fixed.
>>
>> 3. Here's a major concern: the LWWindowPeer (and other LW* classes) 
>> should never import C* classes. Instead you should've added a new 
>> method to the PlatformWindow interface, and used it from 
>> LWWindowPeer. The CPlatformWindow should've implemented this method, 
>> and called an appropriate native method from there. In this case, 
>> however, you actually need a static method, so it'd better be part of 
>> the LWToolkit interface, and implemented in the LWCToolkit class 
>> instead.
>      I see.  It seems that the getTopmostWindowUnderMouse method 
> implementation is different for the CPlatformWindow and for the 
> CPlatformEmbeddedFrame.
>      So I added the getTopmostPlatformWindowUnderMouse method to the 
> PlatformWindow  interface.
>
>     Thanks,
>     Alexandr.
>
>>
>> -- 
>> best regards,
>> Anthony
>>
>> On 08/23/12 15:40, Alexander Scherbatiy wrote:
>>>
>>> Could someone review the fix?
>>>
>>> Thanks,
>>> Alexandr.
>>>
>>> On 8/10/2012 6:00 PM, Alexander Scherbatiy wrote:
>>>>
>>>> Could you review the updated fix:
>>>> http://cr.openjdk.java.net/~alexsch/7171045/webrev.02/
>>>>
>>>> The comments are below:
>>>>
>>>> On 8/7/2012 6:47 PM, Mike Swingler wrote:
>>>>> I noticed that, NSWindow's windowNumber is NSInteger, which is 32
>>>>> bits wide on 32-bit and 64 bits wide on 64-bit. Chopping that to a
>>>>> simple 32 bit int is probably not what you intended to do.
>>>> fixed.
>>>>> Also, have you considered simply calling -[NSWindow
>>>>> setAcceptsMouseMovedEvents:YES] in -[AWTView initWithRect:], and then
>>>>> removing the calls that flip it on and off in -[AWTView
>>>>> mouseEntered:] and -[AWTView mouseExited"]? This would also require a
>>>>> change in
>>>>> Java_sun_lwawt_macosx_CPlatformWindow_nativeSetNSWindowBounds(),
>>>>> which has a comment that states it only turns on mouse moved events
>>>>> if the window is currently under the mouse.
>>>> I tried it. The result that I got is that a dragging mouse from one
>>>> window to another does not generate mouse enter/exit events on the
>>>> second window in case when tracking rect is used and the
>>>> acceptsMouseMovedEvents flag is always set to YES.
>>>>
>>>>> I would think that AppKit should be more than happy to send you
>>>>> mouse-over/enter/exited events as long as you say you want them. Was
>>>>> this approach tried and didn't work for some reason?
>>>>>> Hi, Alexander.
>>>>>> Probably all this stuff can be simplified? Can you try to change
>>>>>> TrackingRect to TrackingArea with appropriate flags like
>>>>>> NSTrackingEnabledDuringMouseDrag etc.
>>>> I changed the TrackingRect to TrackingArea in the updated fix. It now
>>>> generates the mouse enter/exit events on the second window during 
>>>> drag.
>>>> So it is not necessary to generates such events from our side.
>>>>
>>>> The getTopmostWindowUnderMouse is necessary to handle mouse enter/exit
>>>> events for component in case when a mouse is dragged from one window
>>>> to another.
>>>> Where the second window contains it's own components and the only way
>>>> to know about tracking over them are drag events which receives the
>>>> first window.
>>>>
>>>> I think that the LWWindowPeer class code can be simplified if we
>>>> assume that window mouse enter/exit events are always come to the
>>>> current window.
>>>> So the component mouse enter/exit events can be tracked only in the
>>>> current or topmost window.
>>>> For this case I separated the global lastCommonMouseEventPeer which is
>>>> necessary for the cursor manager and the local lastMouseEventPeer.
>>>>
>>>> According to the specification: The proper order of mouse-entered and
>>>> mouse-exited events received by tracking-area objects in an
>>>> application cannot be guaranteed.
>>>> https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/EventOverview/TrackingAreaObjects/TrackingAreaObjects.html 
>>>>
>>>>
>>>> So it seems it is not possible to have one lastMouseEventPeer instead
>>>> of two: lastCommonMouseEventPeer and lastMouseEventPeer.
>>>>
>>>> And there are possible situations that we can receive mouse drag event
>>>> between enter and exit.
>>>> To handle this the isMouseOver flag is added to the LWWindowPeer
>>>> class. So the component mouse enter/exit events are not generated if
>>>> the window mouse exited event is received and window mouse entered is
>>>> not.
>>>>
>>>> There is the test:
>>>> test/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java
>>>> It shows that even using the TrackingArea some mouse enter/exit events
>>>> are not generateed in the following cases:
>>>> - window is created under the mouse
>>>> - window changes it's bounds so it becomes under the mouse
>>>>
>>>> For this cases it still necessary to generate mouse enter/exit events
>>>> from our side.
>>>> I just moved the related code to one method
>>>> synthesizeMouseEnteredExitedEventsForAllWindows.
>>>>
>>>> Thanks,
>>>> Alexandr.
>>>>
>>>>>> 07.08.2012 15:17, Alexander Scherbatiy wrote:
>>>>>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171045
>>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/7171045/webrev.01/
>>>>>>>
>>>>>>> This is a regression after the fix 7154048 [macosx] At least drag
>>>>>>> twice, the toolbar can be dragged to the left side.
>>>>>>>
>>>>>>> In the case where a toolbar is created under a mouse and it is
>>>>>>> dragged over the initial window the mouse enter/exit events should
>>>>>>> not be generated for the components which are under the toolbar.
>>>>>>>
>>>>>>> The current fix is supposed to solve this regression and also to
>>>>>>> fix generation of mouse enter/exit events for all cases where a
>>>>>>> mouse is dragged from one window to another or a new window is
>>>>>>> created under a mouse (like it is implemented for toolbar).
>>>>>>>
>>>>>>> Let's see the following cases
>>>>>>> 1) Mouse is dragged from a window and back to the same window.
>>>>>>> The Mac OS X system generates a mouse exit event only the first
>>>>>>> time when a mouse is dragged from a window and does not generate
>>>>>>> mouse enter/exit events next times during one drag trace.
>>>>>>>
>>>>>>> 2) Mouse is dragged from one window to another.
>>>>>>> The Mac OS X system does not generate mouse enter/exit events for
>>>>>>> the second window.
>>>>>>>
>>>>>>> 3) Mouse is dragged from one window to another and released.
>>>>>>> In this case the Mac OS X system generates mouse enter event for
>>>>>>> the second window only after releasing the mouse.
>>>>>>>
>>>>>>> 4) Clicking on window creates a new window after that the new
>>>>>>> window is dragged (toolbar dragging).
>>>>>>>
>>>>>>> However the Java system generates mouse enter/exit events each time
>>>>>>> when a mouse is dragged over any window.
>>>>>>>
>>>>>>> To fix this the following methods are introduced:
>>>>>>> - Get topmost window under mouse
>>>>>>> - Synthesize mouse enter/exit events for all windows
>>>>>>>
>>>>>>>
>>>>>>> The dispatchMouseEvent method from the LWWindowPeer class is
>>>>>>> handled previous and next components and is able to generate mouse
>>>>>>> enter/exit events for them.
>>>>>>> However the the AWTView native class contains isMouseOver flag
>>>>>>> which value becomes inconsistent if we do not updated it. Because
>>>>>>> of this the fix generates the mouse enter/exit window events on the
>>>>>>> native side.
>>>>>>>
>>>>>>> Generating mouse enter/exit events always should be in order where
>>>>>>> mouse exit events are generated before the mouse enter events.
>>>>>>>
>>>>>>> The synthesizeMouseEnteredExitedEventsForAllWindows method tries to
>>>>>>> generate mouse enter/exit events for all windows during mouse drag
>>>>>>> or window creation/window bounds changing.
>>>>>>> However only those windows which isMouseOver flag is differ from
>>>>>>> the isTopMostWindowUnderMouse state are affected.
>>>>>>> This method also tries to generate both mouse enter and exit event
>>>>>>> for the same window but only one of them can be applicable because
>>>>>>> the isTopMostWindowUnderMouse state is not changed for these calls.
>>>>>>>
>>>>>>> So the window enter/exit events now are always generated from the
>>>>>>> native system and component enter/exit events are generated in the
>>>>>>> LWWindowPeer class.
>>>>>>>
>>>>>>> LWWindowPeer class now uses three links to components: current,
>>>>>>> last and topmostUnderMouse. All of them are necessary because in
>>>>>>> case when a mouse is dragged from one window to another the current
>>>>>>> component receives drag events and last and topmostUnderMouse links
>>>>>>> handle components mouse exit/enter events on the second window.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Alexandr.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> -- 
>>>>>> Best regards, Sergey.
>>>>>>
>>>>
>>>
>

-- 
Best regards, Sergey.