+1
--
best regards,
Anthony
On 9/12/2014 2:45 PM, Alexander Zvegintsev wrote:
Hello Sergey,
the fix looks good to me.
Thanks,
Alexander.
On 09/12/2014 02:26 PM, Sergey Bylokhov wrote:
Hello,
Please review the fix for jdk 9.
According to specification createGraphics() should throw
Hi Chauncey,
Yes, generally this looks like a good solution. And a search on the
Internet suggests that the _JAVA_AWT_WM_NONREPARENTING variable is
pretty much a standard now. We'll still need to undergo an internal API
approval process (CCC) to adopt this new variable name, but I don't
Hi Denis,
Long time no see. Did you miss AWT? :)
We would be glad to accept patches from you. However, I think you will
need to sign an OCA before we can do that:
http://www.oracle.com/technetwork/community/oca-486395.html
--
best regards,
Anthony
On 9/8/2014 4:12 PM, Denis Fokin wrote:
Well, if you want to take the risk, let's do it this way then.
--
best regards,
Anthony
On 9/9/2014 3:28 PM, Sergey Bylokhov wrote:
On 09.09.2014 15:15, Anthony Petrov wrote:
and the current waitForIdle() would simply call waitForIdle(false).
This would be safe enough and elegant enough
Vote: YES
--
best regards,
Anthony
On 9/3/2014 2:44 PM, Artem Ananiev wrote:
I hereby nominate Alexander Zvegintsev (OpenJDK user name: azvegint) to
Membership in the AWT Group.
Alexander is a member of AWT/Swing group at Oracle. He has contributed
20+ fixes to JDK9 so far, and JDK8/8u
()).realSync()
They call realSync without instantiating a robot.
It would be great just replace it with
Toolkit.getDefaultToolkit().nativeEventQueueSync()
in existing tests and nothing more.
Thanks,
Dima
On 08/29/2014 04:35 PM, Anthony Petrov wrote:
Yes, that sounds good to me. We need to consider whether
Hi Alexey,
The fix looks fine.
--
best regards,
Anthony
On 8/28/2014 11:29 AM, Alexey Ivanov wrote:
Hello,
Could you please approve the fix of the test in jdk7u-dev?
Could you please review the fix?
webrev: http://cr.openjdk.java.net/~aivanov/8056156/jdk7/webrev.00/
JBS:
,
Dima
On 08/27/2014 03:16 PM, Anthony Petrov wrote:
Hi Dmitriy,
While I realize that all the new methods are useful when writing JDK
regression tests, do you have any evidence that would suggest that
these same methods could be useful to and/or have been requested by
external developers? All
Hi Dmitriy,
On 8/28/2014 1:14 PM, Dmitriy Ermashov wrote:
On 08/28/2014 12:09 PM, Anthony Petrov wrote:
On 8/27/2014 4:54 PM, Yuri Nesterenko wrote:
On 08/27/2014 04:25 PM, Dmitriy Ermashov wrote:
At first, let me focus on fact that the actual motivation of moving
functionality
The fix looks great to me. +1.
--
best regards,
Anthony
On 8/27/2014 8:31 PM, Alexander Zvegintsev wrote:
Hello Alex,
You are welcome and I am glad to see your contribution to OpenJDK project.
Your fix looks good to me, it resolves JDK-6624085 issue too, so let it
be fixed under this bug ID.
.
--
best regards,
Anthony
On 8/25/2014 1:14 PM, Magnus Ihse Bursie wrote:
On 2014-08-20 11:14, Magnus Ihse Bursie wrote:
On 2014-08-18 16:15, Anthony Petrov wrote:
So I'm not sure if the current set of AWT libraries could be
simplified any further.
Hope this helps.
Thank you for the clarification
Hi Dmitriy,
While I realize that all the new methods are useful when writing JDK
regression tests, do you have any evidence that would suggest that these
same methods could be useful to and/or have been requested by external
developers? All of them look like convenient APIs and I'm not
Hi Andreas,
Yes, in fact Petr has proposed this same enhancement back in January:
http://mail.openjdk.java.net/pipermail/awt-dev/2014-January/006799.html
Do you want to contribute a patch for this RFE? If so, please read this
document:
http://openjdk.java.net/contribute/
The most important
Sounds good. Thanks!
--
best regards,
Anthony
On 8/25/2014 2:32 PM, Andreas Lundblad wrote:
On Mon, Aug 25, 2014 at 12:25 PM, Anthony Petrov
anthony.pet...@oracle.com mailto:anthony.pet...@oracle.com wrote:
Hi Andreas,
Yes, in fact Petr has proposed this same enhancement back
Hi Petr, Anton, Artem, Steve,
Please review the fix at https://javafx-jira.kenai.com/browse/RT-37149
Webrevs:
JDK: http://cr.openjdk.java.net/~anthony/9-5.2/
FX: http://cr.openjdk.java.net/~anthony/g-522-swingNodeDnD-RT-37149.3/
JavaFX implements the DragSourceContextPeer and
Hi Alexander,
The fix looks fine. I'd also mention the JDK bug id in the comment at
line 436 (no need for a new webrev with this change).
--
best regards,
Anthony
On 7/16/2014 8:56 PM, Alexander Zvegintsev wrote:
Hello AWT team,
please review the fix
. The
easiest way to achieve this is to not share your objects between threads.
With best regards. Petr.
On 11 июля 2014 г., at 15:15, Anthony Petrov anthony.pet...@oracle.com wrote:
Hi Petr,
The fix looks good to me overall. A few comments:
1. src/macosx/classes/sun/lwawt/LWMouseInfoPeer.java
highly unlikely we would ever make such a mime-type. And we can update the
parser when we need.
If I handle this situation now this would be just dead code and unneeded
complexity.
With best regards. Petr.
On 14 июля 2014 г., at 21:00, Anthony Petrov anthony.pet...@oracle.com wrote:
Hi Petr
you please review the build part of the following fix:
http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.01/
Thank you.
With best regards. Petr.
On 02 июля 2014 г., at 15:13, Anthony Petrov anthony.pet...@oracle.com wrote:
Thanks. Note that your email editor messed up the HTML part
Hi Petr,
The fix looks good to me overall. A few comments:
1. src/macosx/classes/sun/lwawt/LWMouseInfoPeer.java
55 // Most likely the cached window under cursor is correct and we do
not need the native check.
Perhaps instead it would make sense to describe here when the first
+1
--
best regards,
Anthony
On 7/10/2014 11:26 AM, Petr Pchelko wrote:
Hello, AWT Team.
Please review a simple cleanup:
https://bugs.openjdk.java.net/browse/JDK-8049830
The fix is available here:
http://cr.openjdk.java.net/~pchelko/9/8049830/webrev.00/
Just replacing nasty reflection with
Hi Sergey,
I agree if this change goes to 8u as the least risky thing we can do now.
For 9 I'd prefer to fix the root cause of the problem, which is related
to the wrong cast of e.g. AwtList::_IsSelected from (jboolean
(*)(void*)) to (void *(*)(void *)) - we simply should have never
Hi Petr,
I'm fine with the targeted fix. We often do a similar thing in JavaFX
when processing various events, so the approach is proven to work good.
However, generally I agree with your comment from the bug report about
the necessity to process dispose selectors in the outer event loop
Hi Alexey,
src/windows/classes/sun/awt/windows/WToolkit.java
940 final MapString, Object props = getWProps();
941 updateXPStyleEnabled(props.get(XPSTYLE_THEME_ACTIVE));
971 private synchronized MapString, Object getWProps() {
972 return (wprops != null) ?
the updated webrev?
http://cr.openjdk.java.net/~aivanov/8046559/jdk9/webrev.01/
Thank you,
Alexey.
On 04.07.2014 14:12, Anthony Petrov wrote:
Hi Alexey,
src/windows/classes/sun/awt/windows/WToolkit.java
940 final MapString, Object props = getWProps();
941 updateXPStyleEnabled(props.get
:
Hello,
Is anyone willing to make a second review?
Thank you.
With best regards. Petr.
On 16 июня 2014 г., at 22:32, Anthony Petrov anthony.pet...@oracle.com wrote:
Hi Petr,
Thanks for the update. The fix looks fine.
--
best regards,
Anthony
On 6/16/2014 3:31 PM, Petr Pchelko wrote:
Hello
Hi Petr,
The fix looks fine to me.
Note that there's also AWT API to set a menubar, and it seems (I haven't
investigated deeply) that the LWAWT implementation uses the system menu
bar unconditionally in this case. I believe we can assume that AWT API
isn't used widely and we can leave it as
Looks fine.
--
best regards,
Anthony
On 7/1/2014 9:12 AM, Sergey Bylokhov wrote:
Hello.
Please review the fix for jdk 9.
Bug was triggered by the change in JDK-8032435, when WingDings.java was
changed to non-public class. This class is used in native, and looks
like some of these places, when
, Anthony Petrov wrote:
Hi Artem,
1. Your code still uses wrong formatting. Please just open this page
to see the problem with the lines indentation:
http://cr.openjdk.java.net/~mcherkas/artem/webrev.02/src/windows/native/sun/windows/awt_Component.cpp.sdiff.html
2. DASSERT() is only relevant
Hi Petr,
The fix looks fine to me. Only one question:
src/share/classes/java/awt/datatransfer/SystemFlavorMap.java
234 } catch (IOException e) {
235 System.err.println(Warning reading flavor mapping: +
e.getMessage());
Is there a reason to hide the stack trace of the
was removed.
With best regards. Petr.
On 24 июня 2014 г., at 15:33, Anthony Petrov anthony.pet...@oracle.com wrote:
Thanks!
--
best regards,
Anthony
On 6/23/2014 10:04 PM, Petr Pchelko wrote:
Hello, Anthony.
Out of curiosity, is the import BooleanSupplier statement in Dialog.java only needed
Hi Artem,
Please configure you code editor so that it formats the code that you
modify according to Java code conventions used in OpenJDK (4-spaces line
indentation, a space after if and before {, etc.)
Also, please include the bug id and synopsis to the subject line of your
review
it there for some reason. It’s not needed, I’ll remove it before
the push.
With best regards. Petr.
On Jun 23, 2014, at 9:50 PM, Anthony Petrov anthony.pet...@oracle.com wrote:
Looks fine.
Out of curiosity, is the import BooleanSupplier statement in Dialog.java only needed to
please the compiler when
/libsplashscreen/mapfile-vers
+1, good to note this, always trips people up.
Otherwise looks good.
Kumar
On 6/17/2014 7:45 AM, Anthony Petrov wrote:
Hi Alexander,
[ I'm also adding Neil who's taking over the launcher code ]
1. There's a few code formatting issues that should be fixed
Looks fine.
Out of curiosity, is the import BooleanSupplier statement in Dialog.java
only needed to please the compiler when using () - true? Does the
code not compile w/o the import?
--
best regards,
Anthony
On 6/23/2014 1:46 PM, Petr Pchelko wrote:
Hello, AWT Team.
Please review a
The fix looks fine to me.
this fix is a reverse-changeset for JDK-6638195
And I assume it also reverses JDK-6699328 ?
--
best regards,
Anthony
On 6/23/2014 6:40 PM, Petr Pchelko wrote:
Hello, Anthony.
Thank you for the review.
I've checked that this fix is a reverse-changeset for
On 6/20/2014 3:29 PM, Artem Ananiev wrote:
On 6/20/2014 3:19 PM, Anthony Petrov wrote:
I ran the following query:
https://www.google.com/#q=custom+flavormap.properties
and the search yielded the following forum thread:
https://community.oracle.com/thread/1293314?start=0tstart=0
where
/libsplashscreen/mapfile-vers
+1, good to note this, always trips people up.
Otherwise looks good.
Kumar
On 6/17/2014 7:45 AM, Anthony Petrov wrote:
Hi Alexander,
[ I'm also adding Neil who's taking over the launcher code ]
1. There's a few code formatting issues that should be fixed. For
instance:
src
Hi Petr,
The fix looks fine to me.
--
best regards,
Anthony
On 6/17/2014 4:43 PM, Petr Pchelko wrote:
Hello, AWT Team.
Please review the fix for the issue:
https://bugs.openjdk.java.net/browse/JDK-8047061
The fix is available at:
http://cr.openjdk.java.net/~pchelko/9/8047061/webrev/
When we
Hi Alexander,
[ I'm also adding Neil who's taking over the launcher code ]
1. There's a few code formatting issues that should be fixed. For instance:
src/share/bin/java.c
1846 if(scaled_splash_name){
1853 if(scaled_splash_name){
+1
--
best regards,
Anthony
On 6/10/2014 9:52 PM, Alexey Ivanov wrote:
Hello AWT team,
Could you please review the reverse changeset:
http://cr.openjdk.java.net/~aivanov/8046391/jdk9/webrev.02/
This undoes the fixes for
- JDK-8039383 NPE when changing Windows Theme, and
-
ASAP ..
-phil.
On 6/6/2014 7:03 AM, Anthony Petrov wrote:
You're welcome.
--
best regards,
Anthony
On 6/6/2014 5:58 PM, Alexey Ivanov wrote:
Hi Anthony, Petr,
Thank you for reviewing my fix.
Regards,
Alexey.
On 06.06.2014 15:19, Anthony Petrov wrote:
+1
--
best regards,
Anthony
On 6/6
Hi Alexey,
The fix looks fine to me.
--
best regards,
Anthony
On 6/9/2014 5:19 PM, Alexey Ivanov wrote:
Hi Petr, Anthony, AWT and Swing teams,
Could you please review the following webrev for JDK-8046239 to fix
build failure:
http://cr.openjdk.java.net/~aivanov/8046239/jdk9/webrev.01/
The
Hi Alexander,
src/solaris/native/sun/awt/sun_awt_X11_GtkFileDialogPeer.c
176 free(prevDir);
177 prevDir = strdup(dir);
It's unnecessary to re-duplicate the prevDir on each loop iteration
here. I suggest to initialize it once instead. The less pointer
operations, the less
gtk_file_chooser_get_current_folder()
is not used and
isFromSameDirectory() was introduced.
--
Thanks,
Alexander.
On 06/09/2014 06:07 PM, Anthony Petrov wrote:
Hi Alexander,
src/solaris/native/sun/awt/sun_awt_X11_GtkFileDialogPeer.c
176 free(prevDir);
177 prevDir = strdup(dir);
It's
You're welcome.
--
best regards,
Anthony
On 6/6/2014 5:58 PM, Alexey Ivanov wrote:
Hi Anthony, Petr,
Thank you for reviewing my fix.
Regards,
Alexey.
On 06.06.2014 15:19, Anthony Petrov wrote:
+1
--
best regards,
Anthony
On 6/6/2014 3:20 PM, Petr Pchelko wrote:
Hello, Alexey
Hi Petr,
I've skimmed through a few tests (didn't review all of them), and they
look fine. The 100% pass rate also sounds optimistic.
So, +1.
--
best regards,
Anthony
On 6/6/2014 5:05 PM, Petr Pchelko wrote:
Hello, AWT Team.
Please review the fix for the issue:
Hi Petr,
I'm not really an expert in this code, but technically all the changes
look fine to me. Approved.
--
best regards,
Anthony
On 6/5/2014 11:59 AM, Petr Pchelko wrote:
Hello,
Could somebody please make a second review on this simple cleanup?
Thank you.
With best regards. Petr.
On
styles enabled theme to a classic theme.
Thank you,
Alexey.
On 18.04.2014 18:52, Anthony Petrov wrote:
Hi Alexey,
No, unfortunately I don't have any suggestions right now.
As for allowing executing user code on the toolkit thread, we can't accept such
a fix. Sorry about that.
--
best regards
Hi Petr,
The fix looks good to me. One minor nit: every file that includes
AWT_debug.h will contain its own copy of the
ShouldPrintVerboseDebugging() function and the debug flag. Could we have
only one copy instead?
--
best regards,
Anthony
On 6/3/2014 3:18 PM, Petr Pchelko wrote:
Hello,
/
Thanks,
Dmitry
On 26/05/2014 16:53, Anthony Petrov wrote:
Hi Dmitry,
The fix seems to cover only the case when an app is running with the
default LF. What is the solution for custom LFs? Can we move the
logic for cache disabling to the shared popup-related code somewhere
so that the issue
Hi Steve,
This belongs to 2d-dev@openjdk mailing list. Please re-post your review
request there.
--
best regards,
Anthony
On 5/28/2014 9:33 PM, Steve Sides wrote:
Hello,
Could you please review the fix for the following bug:
https://bugs.openjdk.java.net/browse/JDK-8032527
It is a just a
/JDK-8028617
The fix: http://cr.openjdk.java.net/~anashaty/8028617/9/webrev.01/
http://cr.openjdk.java.net/%7Eanashaty/8028617/9/webrev.01/
Thanks!
Anton.
On 27.05.2014 15:35, Anthony Petrov wrote:
Hi Anton,
Interesting. I'm not sure if 'oô' looks very good, however, I agree
that 'ôô' isn't much
Hi Alexander,
The changes look reasonable. +1.
Also, I'd appreciate if you could add the evaluation from your email to
the bug report itself.
--
best regards,
Anthony
On 5/27/2014 2:43 PM, Alexander Zvegintsev wrote:
Hello,
please review the fix:
.
On 23.05.2014 20:14, Anthony Petrov wrote:
On 5/23/2014 8:04 PM, anton nashatyrev wrote:
could you please point me to the i18n tests you have mentioned?
test/java/awt/im ...? In both open and closed repos.
from non-English I'd tested only Russian locale. Do you have in
mind some
, Anthony Petrov wrote:
To add to what Petr just said, what is the exact reason to specify
the NSWindowCollectionBehaviorCanJoinAllSpaces behavior? I believe
that NSWindowCollectionBehaviorFullScreenAuxiliary alone should do
the trick, does it not?
Petr: we used to build JDK with OS X 10.6 SDK where
PM, Anthony Petrov wrote:
Hi Sergey,
The original fix provides some updates and clarifications to the
javadoc for the LightweightContent.imageBufferReset() method, but
they are missing from your fix. Is this intentional?
Nope. I just missed this update. I looked at this method closely
and got
The fix looks good to me.
--
best regards,
Anthony
On 5/22/2014 5:43 PM, Petr Pchelko wrote:
Hello, AWT Team.
Please review the fix for the issue:
https://bugs.openjdk.java.net/browse/JDK-8043610
The fix is available at:
http://cr.openjdk.java.net/~pchelko/9/8043610/webrev/
The problem is
On 5/23/2014 3:12 PM, Anton V. Tarasov wrote:
On 23.05.2014 14:47, Anthony Petrov wrote:
1. The host bounds are not related to the /content/. Hence, adding
this method to the LightweightContent interface would look
inconsistent from API perspective.
It's not strictly about content (the name
Hi Petr,
On 5/22/2014 7:42 PM, Petr Pchelko wrote:
Please review a yet another AppContext fix:
https://bugs.openjdk.java.net/browse/JDK-8043393
The fix is available here:
http://cr.openjdk.java.net/~pchelko/9/8043393/webrev/
checkChange method is called on a Toolkit thread, but we are trying
Petrov wrote:
On 5/23/2014 3:12 PM, Anton V. Tarasov wrote:
On 23.05.2014 14:47, Anthony Petrov wrote:
1. The host bounds are not related to the /content/. Hence, adding
this method to the LightweightContent interface would look
inconsistent from API perspective.
It's not strictly about content
Hi Anton,
If you activate the CAPS LOCK mode and type some characters, will those
be presented as capital letters in Swing/AWT's text fields and text
areas after your fix? (see [1] for a related FX bug)
[1] https://javafx-jira.kenai.com/browse/RT-16616
--
best regards,
Anthony
On 5/23/2014
nashatyrev wrote:
Anthony,
yes, the CapsLock works for me as well.
Thanks!
Anton
On 23.05.2014 19:35, Anthony Petrov wrote:
Hi Anton,
If you activate the CAPS LOCK mode and type some characters, will
those be presented as capital letters in Swing/AWT's text fields and
text areas after your
Looks fine.
--
best regards,
Anthony
On 5/22/2014 12:08 PM, Petr Pchelko wrote:
Hello,
Please review the fix for the issue:
https://bugs.openjdk.java.net/browse/JDK-8043646
The fix is available at:
http://cr.openjdk.java.net/~pchelko/9/8043646/webrev/
Very simple fix, interesting that the
Looks fine.
--
best regards,
Anthony
On 5/21/2014 4:27 PM, Petr Pchelko wrote:
Hello, AWT Team.
Please review the fox for the issue:
https://bugs.openjdk.java.net/browse/JDK-8043513
The fix is available at:
http://cr.openjdk.java.net/~pchelko/9/8043513/webrev/
The problem:
When we fetch all
wrote:
Hi Sergey,
On 22.05.2014 1:44, Sergey Bylokhov wrote:
On 5/21/14 10:13 PM, Anthony Petrov wrote:
Hi Sergey,
The original fix provides some updates and clarifications to the
javadoc for the LightweightContent.imageBufferReset() method, but
they are missing from your fix. Is this intentional
I think that it would be useful to have a bug id prior to sending a
review request, so that a review thread for the bug can be easily found
in the mailing archive. In the future, please do file a bug first and
put its id in the subject line of your review requests.
--
best regards,
Anthony
it.
With best regards. Petr.
On May 22, 2014, at 10:44 PM, Sergey Bylokhov sergey.bylok...@oracle.com
wrote:
Hi, Petr.
Submitter complains about IOException itself, not about incorrect stack trace.
On 5/22/14 1:39 PM, Anthony Petrov wrote:
Looks fine.
--
best regards,
Anthony
On 5/21/2014 4:27 PM
likely an RDP-client bug, not our bug. All we do here is call
winapi function ::EnumClipboardFormats to get all available format and then
call ::GetClipboardData for each format from that list. No place for a bug left
here..
With best regards. Petr.
On May 23, 2014, at 12:52 AM, Anthony Petrov
.
I have filed https://bugs.openjdk.java.net/browse/JDK-8043807 for incorrect
stack trace issue. This fix will go under that bug ID.
The original bug will be closed a cannot reproduce.
With best regards. Petr.
On May 23, 2014, at 1:15 AM, Anthony Petrov anthony.pet...@oracle.com wrote:
Closing
Thanks, Omair.
--
best regards,
Anthony
On 5/23/2014 1:01 AM, Omair Majid wrote:
* Anthony Petrov anthony.pet...@oracle.com [2014-05-22 16:48]:
I think that it would be useful to have a bug id prior to sending a review
request, so that a review thread for the bug can be easily found
in
the future.
The fix is covering hdpi support in SwingNode on osx + system look and
feel(Aqua).
http://cr.openjdk.java.net/~serb/8029455/webrev.01
Notes:
- This fix depends from two other fixes: JDK- 8041129 and JDK-8041644.
Both are under review on 2d alias.
On 5/13/14 9:29 PM, Anthony Petrov
Hi Anton,
If the fix is identical, then you don't need another technical review.
I'm fine with porting the fix to JDK 7u.
--
best regards,
Anthony
On 5/20/2014 6:20 PM, Anton Litvinov wrote:
Hello Anthony and Sergey,
Could you please review this backport of the fix , which was reviewed
and
Indeed. Thanks for the reminder, Sergey. In that case Anton should
discuss this issue with the JCK team before proceeding.
--
best regards,
Anthony
On 5/20/2014 6:39 PM, Sergey Bylokhov wrote:
On 5/20/14 6:37 PM, Anthony Petrov wrote:
Hi Anton,
If the fix is identical, then you don't need
Thanks for the update, Omair. The fix looks good to me now.
--
best regards,
Anthony
On 5/20/2014 9:11 PM, Omair Majid wrote:
Hi,
Updated webrevs:
http://cr.openjdk.java.net/~omajid/webrevs/system-libjpeg/01/
http://cr.openjdk.java.net/~omajid/webrevs/system-libjpeg/01.jdk/
* Anthony Petrov
Hi Omair,
common/autoconf/libraries.m4
624 [use libjpeg from build system or OpenJDK source (system, bundled)
@:bundled@:@])])
@:bundled@:@ should read @:@bundled@:@ - note the missing @.
make/lib/Awt2dLibraries.gmk
1236 LIBJPEG_CFLAGS :=
I hereby nominate David DeHaven (OpenJDK user name: ddehaven) for jdk9
Committer
David has contributed a number of patches to JDK 7u, 8, 8u, and 9. Also,
he has reviewed many fixes that went into those releases. The AWT Group
particularly values his deep expertise in Mac OS X, which helped us
The splashscreen changes look fine to me. Approved.
--
best regards,
Anthony
On 5/16/2014 7:18 PM, David DeHaven wrote:
Could someone on AWT team approve the splashscreen changes?
-DrD-
Approved.
-phil.
On 5/15/2014 9:31 AM, David DeHaven wrote:
Ping!
Does this look OK?
I've also
To add to what Petr just said, what is the exact reason to specify the
NSWindowCollectionBehaviorCanJoinAllSpaces behavior? I believe that
NSWindowCollectionBehaviorFullScreenAuxiliary alone should do the trick,
does it not?
Petr: we used to build JDK with OS X 10.6 SDK where the
Hi David,
src/solaris/native/sun/awt/awt.h
113 #if !defined(HEADLESS) defined(XAWT)
114 extern Display *awt_display; /* awt_GraphicsEnv.c */
You forgot to update this XAWT usage. Otherwise the fix looks fine.
--
best regards,
Anthony
On 5/13/2014 8:30 PM, David DeHaven wrote:
Hi Jim, Sergey, and Anton,
I'd like to revive this old thread and finally push this fix, which has
been reviewed and approved on this mailing list back in February. The
only additional change that I want to introduce, is the addition of
default implementations for the
Hi David,
The fix looks good to me. To answer your questions:
1. Using the XAWT macro is correct. It is only defined if we're building
the XToolkit, which we don't on the Mac. However, everywhere else we
actually check
#ifdef MACOSX
// ... do Mac stuff
#else
// ... do X11/Linux/Solaris/etc.
Well, I don't have a strong opinion on MACOSX vs. XAWT, and I see your
point actually. I've just pointed out that right now this check would
look somewhat inconsistent. But I'm OK with the fix as it is.
Let's hear other opinions, we need at least one more reviewer anyway.
--
best regards,
The fix looks good to me.
--
best regards,
Anthony
On 5/6/2014 7:00 PM, Petr Pchelko wrote:
Hello, AWT Team.
Please review the fix for the issue:
https://bugs.openjdk.java.net/browse/JDK-8036861
The fix is available at:
http://cr.openjdk.java.net/~pchelko/9/8036861/webrev/
After discussions
Hi Volker,
The fix looks fine to me, too.
--
best regards,
Anthony
On 5/5/2014 10:07 PM, Volker Simonis wrote:
Hi,
could you please review this tiny fix:
http://cr.openjdk.java.net/~simonis/webrevs/8042416/
https://bugs.openjdk.java.net/browse/JDK-8042416
You're welcome!
--
best regards,
Anthony
On 5/6/2014 12:19 PM, Alexey Ivanov wrote:
Hi Anthony,
Thank you for your review.
And thanks for pointing out no user code is allowed to run on the
toolkit thread.
--
Regards,
Alexey.
On 25.04.2014 16:03, Anthony Petrov wrote:
Hi Alexey,
I'm
The fix looks good to me, too.
--
best regards,
Anthony
On 5/1/2014 1:19 AM, Phil Race wrote:
Trying again with awt as To: rather than bcc: ..
-phil.
On 4/30/2014 2:12 PM, Phil Race wrote:
Looks OK to me, but adding awt-dev as splashscreen is owned by AWT.
-phil.
On 4/30/2014 1:48 PM,
Looks fine, but there are extra spaces at lines 159 and 176. Please fix
the lines indentation before pushing the fix.
--
best regards,
Anthony
On 4/30/2014 4:13 PM, Sergey Bylokhov wrote:
Hello.
Please review the small fix for jdk 9. According to documentation
CGDisplayScreenSize() can
Hi Petr,
While the bug description and the solution sound reasonable, I'm still a
bit concerned about the presence of the if(component==null) branch in
the old code. I see that the code has been updated recently (with
lambdas and friends), and is aware of the app contexts thing. So someone
for update releases, but I think it’s OK for JDK
9. It’s always better to catch bugs early.
With best regards. Petr.
On Apr 29, 2014, at 9:37 PM, Anthony Petrov anthony.pet...@oracle.com wrote:
Hi Petr,
While the bug description and the solution sound reasonable, I'm still a bit
concerned about
Hi Petr,
The fix looks fine.
--
best regards,
Anthony
On 4/28/2014 1:50 PM, Petr Pchelko wrote:
Hello, AWT Team.
Please review the fix for the issue:
https://bugs.openjdk.java.net/browse/JDK-8041987
The fix is available at:
http://cr.openjdk.java.net/~pchelko/9/8041987/
My recent fix with
them now?
I've made a wrapper class for this cache (see the bottom of the
file). With the wrapper we can create the cache lazily and the cache
logic is now in one place.
With best regards. Petr.
On 21.04.2014, at 17:20, Anthony Petrov anthony.pet...@oracle.com
wrote:
Hi Petr,
1. src/share
+1
--
best regards,
Anthony
On 4/23/2014 5:59 PM, Sergey Bylokhov wrote:
Hi, Petr.
The fix looks good.
On 4/23/14 1:39 PM, Petr Pchelko wrote:
Hello, AWT Team.
Another huge native leak was found:
https://bugs.openjdk.java.net/browse/JDK-8041572
The fix is simple and available here:
Hi Yuri,
Great to see more tests covering the HW/LW Mixing functionality coming
in! I briefly skimmed through the patch, and it looks good to me.
--
best regards,
Anthony
On 4/24/2014 1:26 PM, Yuri Nesterenko wrote:
Hi,
please review this change for
, sometimes exceptions do not occur when changing
theme of visual styles enabled theme to a classic theme.
Thank you,
Alexey.
On 18.04.2014 18:52, Anthony Petrov wrote:
Hi Alexey,
No, unfortunately I don't have any suggestions right now.
As for allowing executing user code on the toolkit thread, we
Hi Petr,
1. src/share/classes/java/awt/datatransfer/SystemFlavorMap.java
118 private MapString, LinkedHashSetDataFlavor getNativeToFlavor() {
Usually we use a generic interface, such as Set, instead of a concrete
implementation class (LinkedHashSet) in generic types declarations to
.
Please review the new version of fix that meets mentioned requirements:
http://cr.openjdk.java.net/~bagiras/9/8014754.2
Thanks,
Oleg
On 18.04.2014 18:18, Anthony Petrov wrote:
Hi Oleg,
We don't want to add binary files to the open repository. If you can
only add the source code to it and make
Hi Alexey,
With this change, property win.xpstyle.themeActive change is fired on the
toolkit thread
Is it possible to install a change listener for this property from user
code, and hence eventually allow executing some user code on the toolkit
thread with your fix?
--
best regards,
Hi Oleg,
We don't want to add binary files to the open repository. If you can
only add the source code to it and make it compile itself upon test
execution, then it is fine. But the .exe file itself should not be
pushed to the repo.
--
best regards,
Anthony
On 4/18/2014 6:13 PM, Oleg
:02, Anthony Petrov wrote:
Hi Alexey,
With this change, property win.xpstyle.themeActive change is fired
on the toolkit thread
Is it possible to install a change listener for this property from
user code, and hence eventually allow executing some user code on the
toolkit thread with your fix
1 - 100 of 996 matches
Mail list logo
