On Oct 16, 2013, at 9:37 PM, Anthony Petrov wrote:
> Hi Leonid,
>
> The problem with overriding NSApplication -sendEvent: is that you can't be
> sure AWT is running with the NSApplicationAWT instance. If using SWT, FX, or
> otherwise embedding AWT into another application, the NSApp will poin
Hi Leonid,
The problem with overriding NSApplication -sendEvent: is that you can't
be sure AWT is running with the NSApplicationAWT instance. If using SWT,
FX, or otherwise embedding AWT into another application, the NSApp will
point to an instance of another application class, and your sendEv
Looks fine.
--
best regards,
Anthony
On 10/16/2013 08:03 PM, Sergey Bylokhov wrote:
Hello.
Please review the fix for jdk 8.
Some of the classes in awt were marked as FunctionalInterface.
List of all suggested classes
http://mail.openjdk.java.net/pipermail/awt-dev/2013-February/004213.html
Bug
Looks fine.
--
best regards,
Anthony
On 10/16/2013 06:55 PM, Sergey Bylokhov wrote:
Hello.
Please review the fix for jdk 8.
In the fix, synchronization on "this" under awttreelock was removed.
Bug: https://bugs.openjdk.java.net/browse/JDK-8026356
Webrev can be found at: http://cr.openjdk.java.
This indeed makes things clearer. Thanks for the explanation, Artem.
I'm fine with the fix then (although I've noticed Oleg has already
pushed it...)
--
best regards,
Anthony
On 10/16/2013 05:24 PM, Artem Ananiev wrote:
On 10/16/2013 3:29 PM, Anthony Petrov wrote:
Hi Oleg,
The fix looks g
Hello,
This is plan B version of the fix for JDK-8020209: [macosx] Mac OS X key event
confusion for "COMMAND PLUS". The previous, proper version of the fix has been
reviewed here:
http://mail.openjdk.java.net/pipermail/awt-dev/2013-September/005441.html
Unfortunately, I can't proceed with that v
Hello.
Please review the fix for jdk 8.
Some of the classes in awt were marked as FunctionalInterface.
List of all suggested classes
http://mail.openjdk.java.net/pipermail/awt-dev/2013-February/004213.html
Bug: https://bugs.openjdk.java.net/browse/JDK-8022657
Webrev can be found at: http://cr.op
Changeset: 229b10e97bd2
Author:bagiras
Date: 2013-10-16 19:02 +0400
URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/229b10e97bd2
2228674: Fix failed for CR 7162144
Reviewed-by: art, anthony
! src/share/classes/java/awt/EventDispatchThread.java
! src/share/classes/java/awt/EventQue
Hello.
Please review the fix for jdk 8.
In the fix, synchronization on "this" under awttreelock was removed.
Bug: https://bugs.openjdk.java.net/browse/JDK-8026356
Webrev can be found at: http://cr.openjdk.java.net/~serb/8026356/webrev.00
--
Best regards, Sergey.
Hello.
Please review the fix for jdk 8.
The fix has two parts
- Repaint method in the peer now paint the component in place if it
was called on EDT only.
- Most of setters were changed to stop recursion if they were called
on EDT.
Bug: https://bugs.openjdk.java.net/browse/JDK-7090424
Webrev
Hi, Oleg,
as we discussed this fix earlier, it looks fine.
Thanks,
Artem
On 10/16/2013 2:31 PM, Oleg Pekhovskiy wrote:
Hi all,
please review the fix
http://cr.openjdk.java.net/~bagiras/2228674.1/
for
https://bugs.openjdk.java.net/browse/JDK-2228674
The fix covers two scenarios:
1. User code
On 10/16/2013 3:29 PM, Anthony Petrov wrote:
Hi Oleg,
The fix looks good to me. However, I don't recall all details about this
machinery, and removing a call to peekEvent() in
EventQueue.detachDispatchThread() looks a bit scary.
Could Artem or you clarify if AWTAutoShutdown() recreates the EDT
Hi Anthony,
thank you for the review.
As for your question I could just refer to your fix for JDK 7 where the
following changes we made in
src/share/classes/java/awt/EventDispatchThread.java:
@@ -100,7 +94,12 @@ class EventDispatchThread extends Thread
}
Hi Anton,
On 10/16/2013 03:26 PM, anton nashatyrev wrote:
On 15.10.2013 15:02, Anthony Petrov wrote:
The analysis of the problem looks good. Please clarify one point:
"(2) mouse moved to target in a single X11 event"
Is the "single event" the one from (1) or from (3) ? IOW, are the (1)
and (2
Hi Oleg,
The fix looks good to me. However, I don't recall all details about this
machinery, and removing a call to peekEvent() in
EventQueue.detachDispatchThread() looks a bit scary.
Could Artem or you clarify if AWTAutoShutdown() recreates the EDT if
there are still events in the queue, or
Hello Anthony,
thanks for having a look at the fix! See comments inlined:
On 15.10.2013 15:02, Anthony Petrov wrote:
The analysis of the problem looks good. Please clarify one point:
"(2) mouse moved to target in a single X11 event"
Is the "single event" the one from (1) or from (3) ? IOW
Hi all,
please review the fix
http://cr.openjdk.java.net/~bagiras/2228674.1/
for
https://bugs.openjdk.java.net/browse/JDK-2228674
The fix covers two scenarios:
1. User code calls EventDispatchThread.interrupt() and then
EventDispatchThread.interrupted() which clears interrupted state and
EDT d
17 matches
Mail list logo
