+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
IllegalSt
Yes, an instance method would look even better. It's up to SQE to agree
with this proposal. I'm fine either way as long as the method has a
proper name.
--
best regards,
Anthony
On 9/10/2014 4:24 PM, Sergey Bylokhov wrote:
On 10.09.2014 16:00, Anthony Petrov wrote:
Taking in
hil.
On 9/9/14 5:33 AM, Anthony Petrov 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).
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
expec
On 9/9/2014 3:40 PM, Hendrik Schreiber wrote:
On Sep 9, 2014, at 12:27, Anthony Petrov wrote:
Yes, this is the right mailing list to discuss this issue. The bug has been
reopened and moved to the JDK project upon your request:
https://bugs.openjdk.java.net/browse/JDK-8057833
Thanks
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
rIdle(boolean nativeSync)
and the current waitForIdle() would simply call waitForIdle(false).
This would be safe enough and elegant enough as no new method names
would have to be introduced.
--
best regards,
Anthony
On 9/9/2014 3:07 PM, Sergey Bylokhov wrote:
On 09.09.2014 14:40, Anthony P
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:
Hi
Hi Dmitriy,
Robot.sync() could also sound confusing if one remembers there's
Toolkit.sync() already.
Why not name it waitForNativeIdle(), analogous to the already existing
Robot.waitForIdle()? The methods perform similar actions, the only
difference is the event queue they perform these acti
Hi Hendrik,
Yes, this is the right mailing list to discuss this issue. The bug has
been reopened and moved to the JDK project upon your request:
https://bugs.openjdk.java.net/browse/JDK-8057833
--
best regards,
Anthony
On 9/4/2014 12:36 PM, Hendrik Schreiber wrote:
On Sep 1, 2014, at 12:54,
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 contri
()).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
Ermashov wrote:
Hi Anthony,
Ok, let's summarize:
We leave all functionality in ExtendedRobot except of realSync() call,
which in turn we move to a new method in java.awt.Toolkit.
I believe it could be a reasonable compromise.
Is it ok?
Thanks,
Dima
On 08/28/2014 10:03 PM, Anthony Petrov wrote
Thanks!
--
best regards,
Anthony
On 8/28/2014 1:00 PM, Magnus Ihse Bursie wrote:
On 2014-08-27 12:57, Anthony Petrov wrote:
Hi Magnus,
Those look like reasonable suggestions. Could you please file separate
bugs for each of these issues? Also, please note that most of them
belong to 2D, not
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.
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 to
regards,
Anthony
-yan
Thanks,
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 reque
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: https://bugs.
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 entirel
aries.
--
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 cla
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
mailto:anthony.pet...@oracle.com>> wrote:
Hi Andreas,
Yes, in fact Petr has proposed this same enhancement back in January:
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
Looks fine. +1
--
best regards,
Anthony
On 8/20/2014 5:35 PM, Alexey Ivanov wrote:
Hello,
Please approve the backport of the fix to jdk7u-dev.
I replaced lambda expressions and method reference with anonymous classes:
webrev: http://cr.openjdk.java.net/~aivanov/8043610/jdk7/webrev.00/
On 8/18/2014 5:47 PM, Magnus Ihse Bursie wrote:
libawt et al:
The relation between libawt, libawt_headless, libjawt, libawt_xawt
and libawt_lwawt are hairy enough to make my brain curl up. I believe
there are simplifications to be made but I gave up trying to figure them
out.
libawt contains
Hi Alexander,
I don't see any immediate problems with the changes and generally the
fix looks good to me. However, I suppose that on some rare window
managers this might not work as expected. We should understand the risk
and be ready to fix problems if any regressions are reported.
Also not
DK/FX 8u40.
--
best regards,
Anthony
On 8/11/2014 6:27 PM, Petr Pchelko wrote:
Hello, Anthony.
The AWT part looks good to me.
With best regards. Petr.
On Aug 6, 2014, at 9:12 PM, Anthony Petrov wrote:
Anton: thank you for reviewing the fix.
All: I need at least one more reviewer for the JDK part
http://cr.openjdk.java.net/~anthony/9-5.2/
https://bugs.openjdk.java.net/browse/JDK-8049065
--
best regards,
Anthony
On 8/5/2014 5:08 PM, Anthony Petrov wrote:
Anton, Artem, Steve,
Could you please review this fix?
--
best regards,
Anthony
On 7/18/2014 6:44 PM, Anthony Petrov wrote:
Hi Petr,
Anton, Artem, Steve,
Could you please review this fix?
--
best regards,
Anthony
On 7/18/2014 6:44 PM, Anthony Petrov wrote:
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
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 DragGestureReco
s you
guarantee that no two threads are operating on the same object simultaneously. 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 wrote:
Hi Petr,
The fix looks good to me overall. A
rating on the same object simultaneously. 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 wrote:
Hi Petr,
The fix looks good to me overall. A few comments:
1. src/macosx/classes/su
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
http://cr.openjdk.java.net/~azvegint/jdk
+1
--
best regards,
Anthony
On 7/15/2014 2:01 PM, Petr Pchelko wrote:
Hello, AWT team.
Please review the fix for the issue:
https://bugs.openjdk.java.net/browse/JDK-8048549
The 8u version is available here:
http://cr.openjdk.java.net/~pchelko/9/8048549/webrev.8u/
For reference, the 9 version i
Looks fine.
--
best regards,
Anthony
On 7/15/2014 11:41 AM, Petr Pchelko wrote:
Hello,
Please review the fix for the issue:
https://bugs.openjdk.java.net/browse/JDK-8050465
The fix is available here:
http://cr.openjdk.java.net/~pchelko/9/8050465/webrev/
Simple clean-up. The package is not use
1) + reader.readLine().trim();
}
int delimiterPosition = line.indexOf('=');
String key = line.substring(0, delimiterPosition).replace("\\ ", " ");
String[] values = line.substring(delimiterPosition + 1,
line.length()).split(",");
With best regards. Petr
e.)
I don't think we should worry about it now. The properties file is internal and
it's 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 regar
ds or
changes)
Mike
On Jul 9 2014, at 23:55 , Petr Pchelko wrote:
Hello, Build Team.
This is a reminder. Could 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
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
cond
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 only
Hi Alexey,
I skimmed through the changes and they look fine to me. +1.
--
best regards,
Anthony
On 7/10/2014 7:59 PM, Alexey Ivanov wrote:
Hi AWT, Swing teams,
Could you please review the backport of JDK-8046559 to jdk7:
bug: https://bugs.openjdk.java.net/browse/JDK-8046559
webrev:
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
performed
+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 pro
The fix looks fine to me, too.
--
best regards,
Anthony
On 7/7/2014 6:50 PM, Alexander Zvegintsev wrote:
Petr,
Sure, it returns back.
https://bugs.openjdk.java.net/browse/JDK-8049439
Thanks,
Alexander.
On 07/07/2014 06:35 PM, Petr Pchelko wrote:
Hi, Alexander.
The fix looks good, just on
ease review 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 Map props = getWProps();
941 updateXPStyleEn
Hi Alexey,
src/windows/classes/sun/awt/windows/WToolkit.java
940 final Map props = getWProps();
941 updateXPStyleEnabled(props.get(XPSTYLE_THEME_ACTIVE));
971 private synchronized Map getWProps() {
972 return (wprops != null) ? wprops.getProperties() : null;
've used this API
without the useScreenMenuBar system property. I'll add a not about this to the
bug comments.
With best regards. Petr.
On 02 июля 2014 г., at 18:37, Anthony Petrov wrote:
Hi Petr,
The fix looks fine to me.
Note that there's also AWT API to set a menubar, and i
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 i
lling to make a second review?
Thank you.
With best regards. Petr.
On 16 июня 2014 г., at 22:32, Anthony Petrov 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, Anthony.
Thanks for the review, the new versi
Thanks. Note that your email editor messed up the HTML part of the email
(see below a text-only quote), so here's the correct link to the webrev:
http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.01/
The fix looks fine to me.
--
best regards,
Anthony
On 7/2/2014 3:10 PM, Petr Pchelko wrote
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
cording recommendations.
On 30.06.2014 19:14, 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.sd
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 e
same type. Here is a version with assert.
http://cr.openjdk.java.net/~mcherkas/artem/webrev.02/
On 27.06.2014 1:12, Anthony Petrov wrote:
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,
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 reque
e variable
was removed.
With best regards. Petr.
On 24 июня 2014 г., at 15:33, Anthony Petrov 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 to
please th
put 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 wrote:
Looks fine.
Out of curiosity, is the import BooleanSupplier statement in Dialog.java only needed to
please the compiler when using "
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 JDK-66381
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 wee
the exist if block.
make/mapfiles/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
d need more CCC requests which
consume time.
Thank you.
With best regards. Petr.
On 20 июня 2014 г., at 15:29, Artem Ananiev wrote:
On 6/20/2014 3:19 PM, Anthony Petrov wrote:
Hi Petr,
I ran the following query:
https://www.google.com/#q=custom+flavormap.properties
and the search yielded the
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=0&tstart=0
w
Hi Petr,
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=0&tstart=0
where developers seem to suggest they do edit the
$JDKHOME/jre/lib/flavormap.properties fi
indent of the
exist if block.
make/mapfiles/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&#x
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){
src/windows/native/sun/awt/splashscreen/spl
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
Looks fine to me. Approved.
--
best regards,
Anthony
On 6/14/2014 1:43 AM, David DeHaven wrote:
In my haste I forgot to post to awt-dev...
Can someone please review this backport to 8u? The differences are trivial from
the 9 changes.
-DrD-
Please review the backport of JDK-8042440. The c
I've forgot about this one
initially.
Now I've made a grep over all loadLibrary("awt") usages and is looks like it's
replaced with getDefaultToolkit in all places we need.
With best regards. Petr.
On 03 июня 2014 г., at 17:59, Anthony Petrov wrote:
Hi Petr,
The fix l
Hi Sergey,
I suggest to add a comment/javadoc to
CWrapper.NSWindow.setBackgroundColor() to document the format of the
integer argument (the order of the color components, to be precise, or
the color model.) No need for a new webrev with this change.
Other than that, the fix looks good to me.
Hi Dmitriy,
The fix looks fine.
--
best regards,
Anthony
On 6/11/2014 10:28 AM, Dmitriy Ermashov wrote:
Just a reminder.
Please, review the changeset.
Thanks,
Dima
On 26.05.2014 17:50, Dmitriy Ermashov wrote:
Hi,
Please review the changeset for:
https://bugs.openjdk.java.net/browse/JDK-804
+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
- JDK-8046
ne. That is why 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 = strd
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 ro
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 bu
k out this fix
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
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:
https://bugs.openjdk.java.ne
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.
e simultaneously which is undesirable. I'll put synchronized modifier to
updateProperties() method.
Regards,
Alexey.
On 06.06.2014 1:07, Anthony Petrov wrote:
Hi Alexey,
In WToolkit.java you're removing the synchronized modifier from the private
updateProperties() method. And it looks li
. I'll put synchronized
modifier to updateProperties() method.
Regards,
Alexey.
On 06.06.2014 1:07, Anthony Petrov wrote:
Hi Alexey,
In WToolkit.java you're removing the synchronized modifier from the
private updateProperties() method. And it looks like the method itself
does allow for calling f
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 can&#x
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 02
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, A
d this is not reproducible.
Bug: https://bugs.openjdk.java.net/browse/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.
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 co
/
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 L&F. What is the solution for custom L&Fs? Can we move the
logic for cache disabling to the shared popup-related code somewhere
so that the
both cases are not correct (in the first we get
duplicated character). Hope to talk to you offline on how to handle both
problems.
Thanks!
Anton.
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 me
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:
http://cr.openjdk.java.net/~azvegint/jdk/9/
5/2014 14:46, 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
then some other character key. Also try AltGr+7 and then again some
other character key. After pressing a dead key, try to press a letter
key with the Shift modifier. Etc.
--
best regards,
Anthony
Thanks!
Anton.
On 23.05.2014 19:44, Anthony Petrov wrote:
Thanks for confirming that. I'm
PM, anton 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 a
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
thony 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 abo
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 to
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
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 tha
014 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?
Nope. I just missed this
Thanks, Omair.
--
best regards,
Anthony
On 5/23/2014 1:01 AM, Omair Majid wrote:
* Anthony Petrov [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
mailing archive. In the
uture.
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 wrote:
Closing this bug as C
more 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 P
.
With best regards. Petr.
On May 22, 2014, at 10:44 PM, Sergey Bylokhov
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, Petr Pchelko wrote
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
On
1 - 100 of 1373 matches
Mail list logo
