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.
