On 10/5/2015 3:11 PM, Sergey Bylokhov wrote:
On 05.10.15 15:03, Semyon Sadetsky wrote:
Sergey, any other thoughts?
I suggest to postpone the fix as discussed in private(latest massage
was added to the CR).
Sergey. I have answered you in CR. I disagree with your comment. This
fix is not risky I just made one method public. This method was always
available before through an internal class.
On 9/28/2015 12:43 PM, Semyon Sadetsky wrote:
On 9/27/2015 1:13 AM, Sergey Bylokhov wrote:
My understanding according to the new javadoc:
"* If the window does transfer focus to other
* heavyweight containers and the synchronous lightweight focus
requests
* are enabled to it then further focus behavior is unspecified."
behavior of this feature is undefined on most(all?) of our platforms,
because it is hard to imagine that we(or application developer) can
guarantee that the focus will never be transfered to other
heavyweight containers. Right?
Actuallty KFM tries to use the sync focus transfer and may fail if the
requested container is not the current. If this happens the KFM
fallbacks to the async mode. Probably we could remove this warning I
just copied it from the original spec. The aim of the bug is to
provide access to an internal method which is being used by one app
now. I did not change the original spec a lot.
On 26.09.15 0:04, Phil Race wrote:
Hmm. I thought Anton Tarasov was of the opinion this was not
supportable
anyway
because of platform limitations. In other words we should not do
this.
-phil.
On 09/25/2015 01:51 PM, Mandy Chung wrote:
On 09/25/2015 04:32 AM, Semyon Sadetsky wrote:
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8067470
webrev: http://cr.openjdk.java.net/~ssadetsky/8067470/webrev.00/
The corresponding java.awt.Window method is proposed. The method is
protected by a newly introduced property "awt.enableSyncLWFocus".
Can you explain why this setter method needs to be protected by a
system property? By default this method is a nop?
Mandy
