From zhouyx at linux.vnet.ibm.com  Wed Feb  8 23:54:34 2012
From: zhouyx at linux.vnet.ibm.com (Sean Chou)
Date: Thu, 9 Feb 2012 15:54:34 +0800
Subject: <Swing Dev> Request review for 7089914: Focus on image icons
 are not visible in javaws cache with high contrast mode
In-Reply-To: <4F140018.7070001@oracle.com>
References: <CAOo=rxV4_LdLTj=KuwaMHD6fep_XBOdZn4Mr-wnTtP0663r0Zw@mail.gmail.com>
	<4F140018.7070001@oracle.com>
Message-ID: <CAOo=rxWk8hPD9QyaLJtC9ng4_tMRMj0hE99L3UqAXEwkgfJaqA@mail.gmail.com>

Hi Pavel,

   I modified the patch again. It's now at
http://cr.openjdk.java.net/~zhouyx/7089914/webrev.03/ .
3/4 comments are covered. And there are a little comment bellow, please
have a look. Thanks.


On Mon, Jan 16, 2012 at 6:46 PM, Pavel Porvatov
<pavel.porvatov at oracle.com>wrote:

>  Hi Sean,
>
> There are several comments for your patch:
>
> 1. I found one bug. In Win 7 there are several differnet High Contrast
> themes. Under one of them ("High Contrast White") focus is not visible...
>
      This is fixed.


>
> 2. I also don't like synthetic property. Any desktop property has listener
> (see com.sun.java.swing.plaf.windows.DesktopProperty#pcl) and updated when
> correspondent value is changed. But your win.button.focusColor property is
> updated only while full property reloading.
>
      I tried to not use DesktopProperty, but it is found that the
modification becomes much more complex and not working well. On the other
hand, I think
      use DesktopProperty is reasonable: it is so much like a desktop
property that the only difference is it can not be changed separately.


>
> 3. Please don't add references to bugs in the code. Everybody can trace
> history of the code by VCS.
>
     Reference removed.

>
> 4. The changes in the class WindowsRadioButtonUI looks good. Is it
> possible to make your TestButton test an automatic one and add it to the
> fix?
>
     Test case added.


>
> Regards, Pavel
>
>
>  Hi all,
>
>     This is for bug 7089914,
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7089914 .
> OpenJDK uses black as focus color in windows LAF. However, in high
> contrast mode, windows
> uses white as focus color.
>    In additional, the patch also modified WindowsRadioButtonUI.java so it
> will reload its style
> when system setting is changed.
>
>     The webrev link is :
> http://cr.openjdk.java.net/~zhouyx/7089914/webrev.02/
>
>  The previous discussions are:
> http://mail.openjdk.java.net/pipermail/swing-dev/2011-September/001703.html
> http://mail.openjdk.java.net/pipermail/swing-dev/2011-October/001794.html
> http://mail.openjdk.java.net/pipermail/swing-dev/2011-December/001871.html
>
>     Any comments on the this version? thanks.
>
>
>


-- 
Best Regards,
Sean Chou
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120209/afed7ad3/attachment.html 

From pavel.porvatov at oracle.com  Fri Feb 10 06:36:16 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Fri, 10 Feb 2012 18:36:16 +0400
Subject: <Swing Dev> Request review for 7089914: Focus on image icons
 are not visible in javaws cache with high contrast mode
In-Reply-To: <CAOo=rxWk8hPD9QyaLJtC9ng4_tMRMj0hE99L3UqAXEwkgfJaqA@mail.gmail.com>
References: <CAOo=rxV4_LdLTj=KuwaMHD6fep_XBOdZn4Mr-wnTtP0663r0Zw@mail.gmail.com>
	<4F140018.7070001@oracle.com>
	<CAOo=rxWk8hPD9QyaLJtC9ng4_tMRMj0hE99L3UqAXEwkgfJaqA@mail.gmail.com>
Message-ID: <4F352B60.4080008@oracle.com>

Hi Sean,
> Hi Pavel,
>
>    I modified the patch again. It's now at 
> http://cr.openjdk.java.net/~zhouyx/7089914/webrev.03/ 
> <http://cr.openjdk.java.net/%7Ezhouyx/7089914/webrev.03/> .
> 3/4 comments are covered. And there are a little comment bellow, 
> please have a look. Thanks.
>
>
> On Mon, Jan 16, 2012 at 6:46 PM, Pavel Porvatov 
> <pavel.porvatov at oracle.com <mailto:pavel.porvatov at oracle.com>> wrote:
>
>     Hi Sean,
>
>     There are several comments for your patch:
>
>     1. I found one bug. In Win 7 there are several differnet High
>     Contrast themes. Under one of them ("High Contrast White") focus
>     is not visible...
>
>       This is fixed.
Is there any reason to check high contrast mode in the 
WDesktopProperties class? I think in non-high contrast mode 
backgroundColor checking will be useful as well
>
>
>     2. I also don't like synthetic property. Any desktop property has
>     listener (see com.sun.java.swing.plaf.windows.DesktopProperty#pcl)
>     and updated when correspondent value is changed. But your
>     win.button.focusColor property is updated only while full property
>     reloading.
>
>       I tried to not use DesktopProperty, but it is found that the 
> modification becomes much more complex and not working well. On the 
> other hand, I think
>       use DesktopProperty is reasonable: it is so much like a desktop 
> property that the only difference is it can not be changed separately.
What do you think about the following solution:

     static class FocusColorProperty extends DesktopProperty {
         FocusColorProperty(Object fallback) {
             super("win.3d.backgroundColor", fallback);
         }

         @Override
         protected Object configureValue(Object value) {
             return Color.BLACK.equals(value) ? Color.WHITE : Color.BLACK;
         }
     }

This class solves update problems. Actually I didn't check that but it 
seems it should work...

>
>     3. Please don't add references to bugs in the code. Everybody can
>     trace history of the code by VCS.
>
>      Reference removed.
>
>
>     4. The changes in the class WindowsRadioButtonUI looks good. Is it
>     possible to make your TestButton test an automatic one and add it
>     to the fix?
>
>      Test case added.
Could you please clean the test from TODO and dead code (like commented 
code)

Regards, Pavel
>
>
>     Regards, Pavel
>
>
>>     Hi all,
>>
>>        This is for bug 7089914,
>>     http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7089914 .
>>     OpenJDK uses black as focus color in windows LAF. However, in
>>     high contrast mode, windows
>>     uses white as focus color.
>>        In additional, the patch also
>>     modified WindowsRadioButtonUI.java so it will reload its style
>>     when system setting is changed.
>>
>>        The webrev link is :
>>     http://cr.openjdk.java.net/~zhouyx/7089914/webrev.02/
>>     <http://cr.openjdk.java.net/%7Ezhouyx/7089914/webrev.02/>
>>
>>     The previous discussions are:
>>     http://mail.openjdk.java.net/pipermail/swing-dev/2011-September/001703.html
>>     http://mail.openjdk.java.net/pipermail/swing-dev/2011-October/001794.html
>>     http://mail.openjdk.java.net/pipermail/swing-dev/2011-December/001871.html
>>
>>     Any comments on the this version? thanks.
>
>
>
>
> -- 
> Best Regards,
> Sean Chou
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120210/b1c8fdc4/attachment.html 

From zhouyx at linux.vnet.ibm.com  Tue Feb 14 21:52:21 2012
From: zhouyx at linux.vnet.ibm.com (Sean Chou)
Date: Wed, 15 Feb 2012 13:52:21 +0800
Subject: <Swing Dev> Request review for 7089914: Focus on image icons
 are not visible in javaws cache with high contrast mode
In-Reply-To: <4F352B60.4080008@oracle.com>
References: <CAOo=rxV4_LdLTj=KuwaMHD6fep_XBOdZn4Mr-wnTtP0663r0Zw@mail.gmail.com>
	<4F140018.7070001@oracle.com>
	<CAOo=rxWk8hPD9QyaLJtC9ng4_tMRMj0hE99L3UqAXEwkgfJaqA@mail.gmail.com>
	<4F352B60.4080008@oracle.com>
Message-ID: <CAOo=rxUYY8QKO+2Q7BQCw2AC+tvwFwoPrtXvRL+q=-AwEmZ2Hw@mail.gmail.com>

Hi Pavel,

     Thanks for your suggestion, I didn't know DesktopProperty could be
used this way.
I modified it a little, it's
http://cr.openjdk.java.net/~zhouyx/7089914/webrev.05/ .

The reason for checking high contrast is windows allow
"win.3d.backgroundColor" to
be set black in non-high contrast mode.

The testcase is also cleared. Please review again.

On Fri, Feb 10, 2012 at 10:36 PM, Pavel Porvatov
<pavel.porvatov at oracle.com>wrote:

>  Hi Sean,
>
> Hi Pavel,
>
>     I modified the patch again. It's now at
> http://cr.openjdk.java.net/~zhouyx/7089914/webrev.03/ .
> 3/4 comments are covered. And there are a little comment bellow, please
> have a look. Thanks.
>
>
> On Mon, Jan 16, 2012 at 6:46 PM, Pavel Porvatov <pavel.porvatov at oracle.com
> > wrote:
>
>>  Hi Sean,
>>
>> There are several comments for your patch:
>>
>> 1. I found one bug. In Win 7 there are several differnet High Contrast
>> themes. Under one of them ("High Contrast White") focus is not visible...
>>
>       This is fixed.
>
>
> Is there any reason to check high contrast mode in the WDesktopProperties
> class? I think in non-high contrast mode backgroundColor checking will be
> useful as well
>
>
>> 2. I also don't like synthetic property. Any desktop property has
>> listener (see com.sun.java.swing.plaf.windows.DesktopProperty#pcl) and
>> updated when correspondent value is changed. But your win.button.focusColor
>> property is updated only while full property reloading.
>>
>       I tried to not use DesktopProperty, but it is found that the
> modification becomes much more complex and not working well. On the other
> hand, I think
>       use DesktopProperty is reasonable: it is so much like a desktop
> property that the only difference is it can not be changed separately.
>
> What do you think about the following solution:
>
>     static class FocusColorProperty extends DesktopProperty {
>         FocusColorProperty(Object fallback) {
>             super("win.3d.backgroundColor", fallback);
>         }
>
>         @Override
>         protected Object configureValue(Object value) {
>             return Color.BLACK.equals(value) ? Color.WHITE : Color.BLACK;
>         }
>     }
>
> This class solves update problems. Actually I didn't check that but it
> seems it should work...
>
>
>
>
>>
>> 3. Please don't add references to bugs in the code. Everybody can trace
>> history of the code by VCS.
>>
>      Reference removed.
>
>>
>> 4. The changes in the class WindowsRadioButtonUI looks good. Is it
>> possible to make your TestButton test an automatic one and add it to the
>> fix?
>>
>      Test case added.
>
> Could you please clean the test from TODO and dead code (like commented
> code)
>
> Regards, Pavel
>
>
>
>>
>> Regards, Pavel
>>
>>
>>  Hi all,
>>
>>     This is for bug 7089914,
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7089914 .
>> OpenJDK uses black as focus color in windows LAF. However, in high
>> contrast mode, windows
>> uses white as focus color.
>>    In additional, the patch also modified WindowsRadioButtonUI.java so it
>> will reload its style
>> when system setting is changed.
>>
>>     The webrev link is :
>> http://cr.openjdk.java.net/~zhouyx/7089914/webrev.02/
>>
>>  The previous discussions are:
>>
>> http://mail.openjdk.java.net/pipermail/swing-dev/2011-September/001703.html
>> http://mail.openjdk.java.net/pipermail/swing-dev/2011-October/001794.html
>> http://mail.openjdk.java.net/pipermail/swing-dev/2011-December/001871.html
>>
>>     Any comments on the this version? thanks.
>>
>>
>>
>
>
>  --
> Best Regards,
> Sean Chou
>
>
>


-- 
Best Regards,
Sean Chou
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120215/48c9c938/attachment.html 

From zhouyx at linux.vnet.ibm.com  Wed Feb 15 00:54:50 2012
From: zhouyx at linux.vnet.ibm.com (Sean Chou)
Date: Wed, 15 Feb 2012 16:54:50 +0800
Subject: <Swing Dev> Fwd: <AWT Dev> Request review for 7129742 : Unable to
 view focus in Non-Editable TextArea
In-Reply-To: <CAOo=rxU2Xq27GgK1xDcw_oPSJ_OFZsD5d3L7OV=rycnpzpzrDA@mail.gmail.com>
References: <CAOo=rxXQK3Ztv2ER8GLaW=EWMaCyvS8xO2tTzQcPzH+Le2kXxA@mail.gmail.com>
	<4F1448A5.4050509@oracle.com>
	<CAOo=rxU2Xq27GgK1xDcw_oPSJ_OFZsD5d3L7OV=rycnpzpzrDA@mail.gmail.com>
Message-ID: <CAOo=rxUC8TH2+sxY4MTL0GLkq1GDJJCp6WCWyszJuTVV7WMM2A@mail.gmail.com>

Hi all,

   This is a patch for bug 7129742,
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129742 .

Forwarded from awt-dev to swing-dev as it uses swing peer .
The original discussion is
http://mail.openjdk.java.net/pipermail/awt-dev/2012-January/002167.html .
The patch is at  http://cr.openjdk.java.net/~zhouyx/7129742/webrev.01/  .

   Would any one have a look ? Thanks.


---------- Forwarded message ----------
From: Sean Chou <zhouyx at linux.vnet.ibm.com>
Date: Mon, Feb 6, 2012 at 5:31 PM
Subject: Re: <AWT Dev> Request review for 7129742 : Unable to view focus in
Non-Editable TextArea
To: Artem Ananiev <artem.ananiev at oracle.com>
Cc: OpenJDK awt-dev <awt-dev at openjdk.java.net>, Alexander Potochkin <
Alexander.Potochkin at oracle.com>, Pavel Porvatov <Pavel.Porvatov at oracle.com>


Hi all,

    The testcase is added, the new link is
http://cr.openjdk.java.net/~zhouyx/7129742/webrev.01/  .
Please review and give your comments.

    When writing the testcase, I found the application would not exit if
the caret is set visible. It is
caused by the timer thread controlling the blinking of the caret. So I set
the caret invisible when
disposing the TextArea.

    More info: The patch is for bug 7129742,
    http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=7129742<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129742>
 .

    Thanks.

On Mon, Jan 16, 2012 at 11:56 PM, Artem Ananiev <artem.ananiev at oracle.com>wrote:

> Hi, Sean,
>
> text components in XToolkit use Swing peers, so this change should better
> be reviewed on the swing-dev alias. To save everybody's time, I've asked
> Alex and Pavel from the Swing team (in CC) to take a look and they confirm
> the fix looks fine.
>
> Did you consider creating a new regression test for this fix? I'm not sure
> it's easy to detect if caret is visible in the text component or not,
> though.
>
> Thanks,
>
> Artem
>
>
> On 1/16/2012 7:08 AM, Sean Chou wrote:
>
>> Hi all,
>>
>>    I made a patch for bug 7129742,
>> http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=7129742<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129742>.
>> The webrev link is : http://cr.openjdk.java.net/~**
>> zhouyx/7129742/webrev.00/<http://cr.openjdk.java.net/%7Ezhouyx/7129742/webrev.00/>
>>
>>    The solution is very simple, just set the cursor visible.
>>
>>    Please have a look and give some comments. Thanks.
>>
>> --
>> Best Regards,
>> Sean Chou
>>
>>


-- 
Best Regards,
Sean Chou




-- 
Best Regards,
Sean Chou
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120215/a2fe518b/attachment.html 

From sergey.bylokhov at oracle.com  Wed Feb 15 01:26:11 2012
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 15 Feb 2012 13:26:11 +0400
Subject: <Swing Dev> Fwd: <AWT Dev> Request review for 7129742 : Unable
 to view focus in Non-Editable TextArea
In-Reply-To: <CAOo=rxUC8TH2+sxY4MTL0GLkq1GDJJCp6WCWyszJuTVV7WMM2A@mail.gmail.com>
References: <CAOo=rxXQK3Ztv2ER8GLaW=EWMaCyvS8xO2tTzQcPzH+Le2kXxA@mail.gmail.com>
	<4F1448A5.4050509@oracle.com>
	<CAOo=rxU2Xq27GgK1xDcw_oPSJ_OFZsD5d3L7OV=rycnpzpzrDA@mail.gmail.com>
	<CAOo=rxUC8TH2+sxY4MTL0GLkq1GDJJCp6WCWyszJuTVV7WMM2A@mail.gmail.com>
Message-ID: <4F3B7A33.9020902@oracle.com>

Hi Sean,
In the XAWTCaret.super.focusGained(e) we check isEnabled() state of the 
component.
Probably we should do it in the fix too, just to be closer to the old 
version?
The problem applicable for textarea only? What about textfield?

15.02.2012 12:54, Sean Chou wrote:
> Hi all,
>
>    This is a patch for bug 7129742, 
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129742 .
>
> Forwarded from awt-dev to swing-dev as it uses swing peer .
> The original discussion is 
> http://mail.openjdk.java.net/pipermail/awt-dev/2012-January/002167.html .
> The patch is at http://cr.openjdk.java.net/~zhouyx/7129742/webrev.01/ 
> <http://cr.openjdk.java.net/%7Ezhouyx/7129742/webrev.01/>  .
>
>    Would any one have a look ? Thanks.
>
>
> ---------- Forwarded message ----------
> From: *Sean Chou* <zhouyx at linux.vnet.ibm.com 
> <mailto:zhouyx at linux.vnet.ibm.com>>
> Date: Mon, Feb 6, 2012 at 5:31 PM
> Subject: Re: <AWT Dev> Request review for 7129742 : Unable to view 
> focus in Non-Editable TextArea
> To: Artem Ananiev <artem.ananiev at oracle.com 
> <mailto:artem.ananiev at oracle.com>>
> Cc: OpenJDK awt-dev <awt-dev at openjdk.java.net 
> <mailto:awt-dev at openjdk.java.net>>, Alexander Potochkin 
> <Alexander.Potochkin at oracle.com 
> <mailto:Alexander.Potochkin at oracle.com>>, Pavel Porvatov 
> <Pavel.Porvatov at oracle.com <mailto:Pavel.Porvatov at oracle.com>>
>
>
> Hi all,
>
>     The testcase is added, the new link is 
> http://cr.openjdk.java.net/~zhouyx/7129742/webrev.01/ 
> <http://cr.openjdk.java.net/%7Ezhouyx/7129742/webrev.01/>  .
> Please review and give your comments.
>
>     When writing the testcase, I found the application would not exit 
> if the caret is set visible. It is
> caused by the timer thread controlling the blinking of the caret. So I 
> set the caret invisible when
> disposing the TextArea.
>
>     More info: The patch is for bug 7129742,
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129742 .
>
>     Thanks.
>
> On Mon, Jan 16, 2012 at 11:56 PM, Artem Ananiev 
> <artem.ananiev at oracle.com <mailto:artem.ananiev at oracle.com>> wrote:
>
>     Hi, Sean,
>
>     text components in XToolkit use Swing peers, so this change should
>     better be reviewed on the swing-dev alias. To save everybody's
>     time, I've asked Alex and Pavel from the Swing team (in CC) to
>     take a look and they confirm the fix looks fine.
>
>     Did you consider creating a new regression test for this fix? I'm
>     not sure it's easy to detect if caret is visible in the text
>     component or not, though.
>
>     Thanks,
>
>     Artem
>
>
>     On 1/16/2012 7:08 AM, Sean Chou wrote:
>
>         Hi all,
>
>            I made a patch for bug 7129742,
>         http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129742 .
>         The webrev link is :
>         http://cr.openjdk.java.net/~zhouyx/7129742/webrev.00/
>         <http://cr.openjdk.java.net/%7Ezhouyx/7129742/webrev.00/>
>
>            The solution is very simple, just set the cursor visible.
>
>            Please have a look and give some comments. Thanks.
>
>         --
>         Best Regards,
>         Sean Chou
>
>
>
>
> -- 
> Best Regards,
> Sean Chou
>
>
>
>
> -- 
> Best Regards,
> Sean Chou
>


-- 
Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120215/c4497288/attachment-0001.html 

From zhouyx at linux.vnet.ibm.com  Thu Feb 16 01:42:19 2012
From: zhouyx at linux.vnet.ibm.com (Sean Chou)
Date: Thu, 16 Feb 2012 17:42:19 +0800
Subject: <Swing Dev> Fwd: <AWT Dev> Request review for 7129742 : Unable
 to view focus in Non-Editable TextArea
In-Reply-To: <4F3B7A33.9020902@oracle.com>
References: <CAOo=rxXQK3Ztv2ER8GLaW=EWMaCyvS8xO2tTzQcPzH+Le2kXxA@mail.gmail.com>
	<4F1448A5.4050509@oracle.com>
	<CAOo=rxU2Xq27GgK1xDcw_oPSJ_OFZsD5d3L7OV=rycnpzpzrDA@mail.gmail.com>
	<CAOo=rxUC8TH2+sxY4MTL0GLkq1GDJJCp6WCWyszJuTVV7WMM2A@mail.gmail.com>
	<4F3B7A33.9020902@oracle.com>
Message-ID: <CAOo=rxV3FguJp0UgoHSJ3GJ1kjgbKTpW_sLOYF_C4TqLAwcG9A@mail.gmail.com>

Hi Sergey,

    The isEnabled() test is added.

    TextField has the same problem, in fact, TextField contains a nested
class XAWTCaret which
is the same with the one in TextArea. Maybe this is what the comment "//
TODO : fix this duplicate code"
means. I modified the XAWTCaret class to be static and let TextField
reference the class in
XTextAreaPeer , but I'm not sure is it the right way to remove the
duplicate code.

    Please take a look again. Thanks.

On Wed, Feb 15, 2012 at 5:26 PM, Sergey Bylokhov <sergey.bylokhov at oracle.com
> wrote:

>  Hi Sean,
> In the XAWTCaret.super.focusGained(e) we check isEnabled() state of the
> component.
> Probably we should do it in the fix too, just to be closer to the old
> version?
> The problem applicable for textarea only? What about textfield?
>
>
> 15.02.2012 12:54, Sean Chou wrote:
>
> Hi all,
>
>    This is a patch for bug 7129742,
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129742 .
>
> Forwarded from awt-dev to swing-dev as it uses swing peer .
> The original discussion is
> http://mail.openjdk.java.net/pipermail/awt-dev/2012-January/002167.html .
> The patch is at  http://cr.openjdk.java.net/~zhouyx/7129742/webrev.01/  .
>
>    Would any one have a look ? Thanks.
>
>
> ---------- Forwarded message ----------
> From: Sean Chou <zhouyx at linux.vnet.ibm.com>
> Date: Mon, Feb 6, 2012 at 5:31 PM
> Subject: Re: <AWT Dev> Request review for 7129742 : Unable to view focus
> in Non-Editable TextArea
> To: Artem Ananiev <artem.ananiev at oracle.com>
> Cc: OpenJDK awt-dev <awt-dev at openjdk.java.net>, Alexander Potochkin <
> Alexander.Potochkin at oracle.com>, Pavel Porvatov <Pavel.Porvatov at oracle.com
> >
>
>
> Hi all,
>
>      The testcase is added, the new link is
> http://cr.openjdk.java.net/~zhouyx/7129742/webrev.01/  .
> Please review and give your comments.
>
>      When writing the testcase, I found the application would not exit if
> the caret is set visible. It is
> caused by the timer thread controlling the blinking of the caret. So I set
> the caret invisible when
> disposing the TextArea.
>
>      More info: The patch is for bug 7129742,
>     http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129742 .
>
>      Thanks.
>
>  On Mon, Jan 16, 2012 at 11:56 PM, Artem Ananiev <artem.ananiev at oracle.com
> > wrote:
>
>> Hi, Sean,
>>
>> text components in XToolkit use Swing peers, so this change should better
>> be reviewed on the swing-dev alias. To save everybody's time, I've asked
>> Alex and Pavel from the Swing team (in CC) to take a look and they confirm
>> the fix looks fine.
>>
>> Did you consider creating a new regression test for this fix? I'm not
>> sure it's easy to detect if caret is visible in the text component or not,
>> though.
>>
>> Thanks,
>>
>> Artem
>>
>>
>> On 1/16/2012 7:08 AM, Sean Chou wrote:
>>
>>> Hi all,
>>>
>>>    I made a patch for bug 7129742,
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129742 .
>>> The webrev link is :
>>> http://cr.openjdk.java.net/~zhouyx/7129742/webrev.00/
>>>
>>>    The solution is very simple, just set the cursor visible.
>>>
>>>    Please have a look and give some comments. Thanks.
>>>
>>> --
>>> Best Regards,
>>> Sean Chou
>>>
>>>
>
>
>  --
> Best Regards,
> Sean Chou
>
>
>
>
> --
> Best Regards,
> Sean Chou
>
>
>
> --
> Best regards, Sergey.
>
>


-- 
Best Regards,
Sean Chou
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120216/79a87a94/attachment.html 

From pavel.porvatov at oracle.com  Thu Feb 16 05:58:27 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Thu, 16 Feb 2012 17:58:27 +0400
Subject: <Swing Dev> Request review for 7089914: Focus on image icons
 are not visible in javaws cache with high contrast mode
In-Reply-To: <CAOo=rxUYY8QKO+2Q7BQCw2AC+tvwFwoPrtXvRL+q=-AwEmZ2Hw@mail.gmail.com>
References: <CAOo=rxV4_LdLTj=KuwaMHD6fep_XBOdZn4Mr-wnTtP0663r0Zw@mail.gmail.com>
	<4F140018.7070001@oracle.com>
	<CAOo=rxWk8hPD9QyaLJtC9ng4_tMRMj0hE99L3UqAXEwkgfJaqA@mail.gmail.com>
	<4F352B60.4080008@oracle.com>
	<CAOo=rxUYY8QKO+2Q7BQCw2AC+tvwFwoPrtXvRL+q=-AwEmZ2Hw@mail.gmail.com>
Message-ID: <4F3D0B83.9040207@oracle.com>

Hi Sean,
> Hi Pavel,
>
>      Thanks for your suggestion, I didn't know DesktopProperty could 
> be used this way.
> I modified it a little, it's 
> http://cr.openjdk.java.net/~zhouyx/7089914/webrev.05/ 
> <http://cr.openjdk.java.net/%7Ezhouyx/7089914/webrev.05/> .
>
> The reason for checking high contrast is windows allow 
> "win.3d.backgroundColor" to
> be set black in non-high contrast mode.
>
> The testcase is also cleared. Please review again.
I modified your fix a little bit and rewrote the test (because it 
contained concurrency problems, e.g. the passed field must be volatile 
etc). Here is the commit:
http://hg.openjdk.java.net/jdk8/awt/jdk/rev/362867d5caa4

Thanks, Pavel
>
> On Fri, Feb 10, 2012 at 10:36 PM, Pavel Porvatov 
> <pavel.porvatov at oracle.com <mailto:pavel.porvatov at oracle.com>> wrote:
>
>     Hi Sean,
>>     Hi Pavel,
>>
>>        I modified the patch again. It's now at
>>     http://cr.openjdk.java.net/~zhouyx/7089914/webrev.03/
>>     <http://cr.openjdk.java.net/%7Ezhouyx/7089914/webrev.03/> .
>>     3/4 comments are covered. And there are a little comment bellow,
>>     please have a look. Thanks.
>>
>>
>>     On Mon, Jan 16, 2012 at 6:46 PM, Pavel Porvatov
>>     <pavel.porvatov at oracle.com <mailto:pavel.porvatov at oracle.com>> wrote:
>>
>>         Hi Sean,
>>
>>         There are several comments for your patch:
>>
>>         1. I found one bug. In Win 7 there are several differnet High
>>         Contrast themes. Under one of them ("High Contrast White")
>>         focus is not visible...
>>
>>           This is fixed.
>     Is there any reason to check high contrast mode in the
>     WDesktopProperties class? I think in non-high contrast mode
>     backgroundColor checking will be useful as well
>
>>
>>         2. I also don't like synthetic property. Any desktop property
>>         has listener (see
>>         com.sun.java.swing.plaf.windows.DesktopProperty#pcl) and
>>         updated when correspondent value is changed. But your
>>         win.button.focusColor property is updated only while full
>>         property reloading.
>>
>>           I tried to not use DesktopProperty, but it is found that
>>     the modification becomes much more complex and not working well.
>>     On the other hand, I think
>>           use DesktopProperty is reasonable: it is so much like a
>>     desktop property that the only difference is it can not be
>>     changed separately.
>     What do you think about the following solution:
>
>         static class FocusColorProperty extends DesktopProperty {
>             FocusColorProperty(Object fallback) {
>                 super("win.3d.backgroundColor", fallback);
>             }
>
>             @Override
>             protected Object configureValue(Object value) {
>                 return Color.BLACK.equals(value) ? Color.WHITE :
>     Color.BLACK;
>             }
>         }
>
>     This class solves update problems. Actually I didn't check that
>     but it seems it should work...
>
>
>>
>>         3. Please don't add references to bugs in the code. Everybody
>>         can trace history of the code by VCS.
>>
>>          Reference removed.
>>
>>
>>         4. The changes in the class WindowsRadioButtonUI looks good.
>>         Is it possible to make your TestButton test an automatic one
>>         and add it to the fix?
>>
>>          Test case added.
>     Could you please clean the test from TODO and dead code (like
>     commented code)
>
>     Regards, Pavel
>
>>
>>         Regards, Pavel
>>
>>
>>>         Hi all,
>>>
>>>            This is for bug 7089914,
>>>         http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7089914 .
>>>         OpenJDK uses black as focus color in windows LAF. However,
>>>         in high contrast mode, windows
>>>         uses white as focus color.
>>>            In additional, the patch also
>>>         modified WindowsRadioButtonUI.java so it will reload its style
>>>         when system setting is changed.
>>>
>>>            The webrev link is :
>>>         http://cr.openjdk.java.net/~zhouyx/7089914/webrev.02/
>>>         <http://cr.openjdk.java.net/%7Ezhouyx/7089914/webrev.02/>
>>>
>>>         The previous discussions are:
>>>         http://mail.openjdk.java.net/pipermail/swing-dev/2011-September/001703.html
>>>         http://mail.openjdk.java.net/pipermail/swing-dev/2011-October/001794.html
>>>         http://mail.openjdk.java.net/pipermail/swing-dev/2011-December/001871.html
>>>
>>>         Any comments on the this version? thanks.
>>
>>
>>
>>
>>     -- 
>>     Best Regards,
>>     Sean Chou
>>
>
>
>
>
> -- 
> Best Regards,
> Sean Chou
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120216/28780046/attachment-0001.html 

From Johannes.Lichtenberger at uni-konstanz.de  Mon Feb 20 03:21:46 2012
From: Johannes.Lichtenberger at uni-konstanz.de (Johannes.Lichtenberger)
Date: Mon, 20 Feb 2012 12:21:46 +0100
Subject: <Swing Dev> Multiple Applet-instances in one JFrame (different
	JPanels)
Message-ID: <4F422CCA.2050306@uni-konstanz.de>

Hello,

is it (even) possible to add multiple Applet instances to a single
JFrame (within different JPanels)? I never thought about it in the first
place, but I've embedded a few Processing(.org) views, which are PApplet
instances and extend Applet in a Swing-GUI but now want to view them
side by side, but the things get messed up somehow, meaning errors like
a popMatrix(...) has to go with a pushMatrix(...) whereas with a single
view/Applet instance it's working all right.

kind regards,
Johannes


From zhouyx at linux.vnet.ibm.com  Wed Feb 22 00:00:47 2012
From: zhouyx at linux.vnet.ibm.com (Sean Chou)
Date: Wed, 22 Feb 2012 16:00:47 +0800
Subject: <Swing Dev> A proposal for a behavior change about mnemonic key
In-Reply-To: <4F1951DF.4010403@oracle.com>
References: <AANLkTimDaioEK4oLkeqtRBPUCt4yPCZ0r3yHi=waisOg@mail.gmail.com>
	<BANLkTi=yLQgf_c1J6ahVqenC+aHCJWh=kg@mail.gmail.com>
	<CAOo=rxVvLQWxvLFZErt3xFTJokyHtfzetfbN3Rn=4DFPpVgmcA@mail.gmail.com>
	<B56FF905-2911-41DB-935D-A2026AD1D137@gmail.com>
	<CAOo=rxUNj5aCAbDKDo3i6rq-uEet4KdMKwy_iu4nRWdvE+oB6A@mail.gmail.com>
	<4E6E2CC9.5080100@oracle.com>
	<CAOo=rxUiLukv5rZbUG6QpSCorTwiNdCkvS3w3B1OV3WTW3us8w@mail.gmail.com>
	<4E6F290E.9010701@oracle.com>
	<CAOo=rxU1d=vvzDiRk=-PG1_JbtTgUNmE0QF2cuPtEH3bhTNQ+g@mail.gmail.com>
	<4E70C568.6050105@oracle.com>
	<CAOo=rxXGNy9qA5GoJ0y+0Cb6jTxvho1jNPgrp4hTGLHeR+wCUA@mail.gmail.com>
	<4E79F306.3040406@oracle.com>
	<CAOo=rxVZZfCZjKRakzhQ9RxzQPC5bM1gUkDS-j6EORUoj91ybg@mail.gmail.com>
	<4E903584.9030808@oracle.com>
	<CAOo=rxXASaRnoPrgFgQ8daW9jLKdec=Cu_LJOt94ENUgNuNiRg@mail.gmail.com>
	<4ECD33FC.10404@oracle.com>
	<CAOo=rxVKTitGnAkZPVSU678FLotuiokapMHs2yF-RDzZJ+WWpg@mail.gmail.com>
	<4F1951DF.4010403@oracle.com>
Message-ID: <CAOo=rxWBckF9D+bpnweKOpHnpTgQLCJUWN9A-YedY4xV6gGsww@mail.gmail.com>

Hi Pavel,

     The current behavior correspondent to Windows' behavior . However, the
modification is in javax.swing.KeyboardManager , it is LAF independent I
think.
I uploaded a webrev about the modification :
http://cr.openjdk.java.net/~zhouyx/7108342/webrev.00/  .  Please have a
look.


On Fri, Jan 20, 2012 at 7:37 PM, Pavel Porvatov
<pavel.porvatov at oracle.com>wrote:

>  Hi Sean,
>
> Hi Pavel,
>
>  About the LAF, I didn't quite get you. Do you mean we should ask users to
> press "esc" before next mnemonic key event takes effect when using gtk LAF?
> Or, do you mean we should implement the focus transfer code in each LAF?
>
> Previously, I thought this patch is just a small enhancement to current
> implementation and the enhancement benefits all LAFs.
>
> I meant that native look and feels (like Windows and GTK LAFs) should have
> behavior of native system. As I wrote there are a couple differences
> between these LAFs:
> ----------------
>
> 1. When Alt+i is pressed several times:
> In Windows focus moves between items
> In Ubuntu focus stays at the initially selected item
>
> 2. When sequence Alt+i and Escape pressed several times
> In Windows the first menu item is selected
> In Ubuntu after every sequence the next item is selected
> ----------------
>
> As I understand your current implementation correspondent to WindowsLAF,
> right? We can add the new functionality in cross platform look and feel, so
> we could use your patch for Metal and Nimbus as well. But Motif and GTK
> should use different strategy. I'd suggest to use your new behavior only
> for Windows, Nimbus and Metal, but doesn't touch Motif and GTK .
>
> Regards, Pavel
>
>
>
> On Thu, Nov 24, 2011 at 1:57 AM, Pavel Porvatov <pavel.porvatov at oracle.com
> > wrote:
>
>>  Hi Sean,
>>
>> We still doesn't have consensus about native LAF behavior. As noticed
>> Mario "I believe that native look and feel should mandate the different
>>  keybindings". I agree with him and I'd like to not extend the new behavior
>> on all LAFs.
>>
>> I also glanced at the fix and have one comment: you should use
>> getModifiersEx method instead of getModifiers (see javadoc for the
>> InputEvent#ALT_MASK field for details)
>>
>> Regards, Pavel
>>
>> Hi all,
>>
>>      I modified the patch and added the testcase, please see attachment.
>>
>>      However, the testcase works on windows, but does not work right on
>> linux. That's
>>  the reason for the Manualbug7108342.java file. When I test it manually,
>> it works. And
>> because of this problem, I haven't tested it with jtreg.
>>
>>      Following is the scenario of testcase:
>>     The test has three buttons with Mnemonic key "b", at start up, focus
>> is on button1,
>> when alt+b is pressed, focus goes to button3, and if pressed again, it
>> goes to button2,
>> and then button1, etc.
>>
>>      When the testcase runs on linux, only button3 and button1 get
>> focused, and there
>> are 18 focus events recorded instead of 9. I'm not sure what's the
>> problem with it.
>> When I press alt+b manually(using Manualbug7108342.java), it works well.
>>
>>      Does anyone have some comments about the patch or the testcase ?
>>
>> On Sat, Oct 8, 2011 at 7:35 PM, Pavel Porvatov <pavel.porvatov at oracle.com
>> > wrote:
>>
>>>  Hi Sean,
>>>
>>> Hi Pavel,
>>>
>>>     Your observation is right, but I can't agree with the conclusion.
>>> Windows and
>>> GTK behave differently about how to close an opened menu. Under GTK,
>>> press
>>> "alt" can not close an opened menu, so, the "esc" is used to close it;
>>> while
>>> windows performs more friendly, when mnemonic key is pressed again, the
>>> first
>>> opened menu is closed automatically. This is totally about how to close
>>> an
>>> opened menu, and it doesn't change the fact that menus with same mnemonic
>>> key are iterated.
>>>
>>>     On the other side, swing implementation doesn't follow GTK's
>>> behavior about
>>> how to close the menu at all. Open the swingset2 and you can find its
>>> behavior
>>> is the same with windows. Press "alt+f" and then press "alt+l" will open
>>> the
>>> "look and feel" menu instead of GTK's "alt+f", "esc", and "alt+l".
>>>
>>>     So, I think GTK's behavior about "use esc to close an opened menu"
>>> is not
>>> user friendly and we can ignore it, while GTK's "iterate over menus with
>>> same
>>> mnemonic key" is better than current java implementation and we can add
>>> this feature. And if a user wants to use GTK's key sequence "alt+f",
>>> "esc",
>>> "alt+l", it is also functional.
>>>
>>>     So I think this enhancement will help keep the behavior same with
>>> both these
>>> platforms, how do you think?
>>>
>>>  Sounds reasonable and I don't object now to the decision. Does anybody
>>> have ideas (e.g. objections) about the new functionality?
>>>
>>> I glanced at your patch and have the following comments:
>>> 1. Could you please file CR about the problem
>>> 2. A test is needed (I think it's possible to write an automatic one)
>>> 3. Could you please correct the new code to obey our code standards
>>> (aligning, spacing, mandatory braces in if/else conditions and others)
>>>
>>> If possible send patch as a webrev, please.
>>>
>>> Thanks, Pavel
>>>
>>>
>>>
>>> 2011/9/21 Pavel Porvatov <pavel.porvatov at oracle.com>
>>>
>>>>  Hi Sean,
>>>>
>>>> I found out that Windows and GTK works in different ways (I used your
>>>> apps):
>>>>
>>>> 1. When Alt+i is pressed several times:
>>>> In Windows focus moves between items
>>>> In Ubuntu focus stays at the initially selected item
>>>>
>>>> 2. When sequence Alt+i and Escape pressed several times
>>>> In Windows the first menu item is selected
>>>> In Ubuntu after every sequence the next item is selected
>>>>
>>>> In such case we should use different strategies for different
>>>> platforms...
>>>>
>>>>
>>>> Regards, Pavel
>>>>
>>>>  Hi Pavel,
>>>>
>>>>      I just tested linux gtk platform.  With gtk2+, ubuntu linux with
>>>> kernel 2.6.38, xfce, x86_32.
>>>> I set four menus with mnemonic "i". Press "alt+i" will travel through
>>>> four menus. The difference
>>>> is that each menu must be closed with "esc" before "alt+i" opens the
>>>> next one.
>>>>
>>>>      So press "alt+i" opens "File", and press "esc" to close it;
>>>>     then press "alt+i" opens "Edit", and press "esc" to close it;
>>>>     ... for next menu with mnemonic "i"
>>>>
>>>>  I attached the test application and its ui file. If it is blocked,
>>>> please use
>>>> this link:
>>>> https://docs.google.com/leaf?id=0B8kRxsymP7imOGU1NjhiM2ItMGQ5Ni00NWNhLWJmMDQtZjZiZmQzN2U4ZGUw&hl=en_US
>>>>
>>>>  Ubuntu x86_32 should work.
>>>>
>>>>
>>>>  So, I think both windows and linux gtk have supported traversal of
>>>> same mnemonic keyed
>>>> items already.
>>>>
>>>>
>>>> 2011/9/14 Pavel Porvatov <pavel.porvatov at oracle.com>
>>>>
>>>>  Hi Sean,
>>>>
>>>> Hi Pavel,
>>>>
>>>>      Let's see if this time works. The attachement just contains the
>>>> exe file written by C#, the application is very simple, I just drag a menu
>>>> to the default WinForm in VS2003.
>>>>     Please change the extension from exe1 to exe after unzip as gmail
>>>> doesn't allow exe file to be sent.
>>>>
>>>>  Yes, I see. And what about other platforms/lafs? Your patch affects
>>>> behavior of all lafs. So we must be sure, that such behavior is correct for
>>>> every supported platform...
>>>>
>>>> Regards, Pavel
>>>>
>>>>
>>>> 2011/9/13 Pavel Porvatov <pavel.porvatov at oracle.com>
>>>>
>>>>  Hi Sean,
>>>>
>>>> I think the attached sample was removed because I didn't get any
>>>> attachments...
>>>>
>>>> Regards, Pavel
>>>>
>>>>  Hi Pavel,
>>>>
>>>>     I found C# Form application treats Mnemonics in menu in this way.
>>>> I attached the sample
>>>> application. Press alt+i will iterate over three menu.
>>>>
>>>>  2011/9/13 Pavel Porvatov <pavel.porvatov at oracle.com>
>>>>
>>>>  Hi Sean,
>>>>
>>>> Hi,
>>>>
>>>>     Thanks.
>>>>
>>>>     So is there any one can give me a suggestion about what shall I
>>>> do if we want these feature ?  Thanks again.
>>>>
>>>>  First of all you should file a bug (RFE actually). BTW: before
>>>> reviewing the fix I'd like to ask about OS behavior when there are several
>>>> components with the same mnemonic. How Windows XP/Vista/7 and Linux
>>>> (Gnome/KDE) manage the described situation?
>>>>
>>>> Regards, Pavel
>>>>
>>>>
>>>>
>>>> 2011/7/6 Jean-Remi Desjardins <jeanremi.desjardins at gmail.com>
>>>>
>>>>  I think that sounds like a great idea!
>>>>
>>>>  Regards,
>>>> Jean-R?mi Desjardins
>>>>
>>>> Sent from my iPhone (so don't expect me to be too verbose)
>>>>
>>>> On 2011-07-06, at 5:42 AM, Sean Chou <zhouyx at linux.vnet.ibm.com> wrote:
>>>>
>>>>  Hi,
>>>>
>>>>     Is there anybody interested in this feature? Or any other
>>>> comments?
>>>>
>>>> 2011/4/21 Sean Chou <zhouyx at linux.vnet.ibm.com>
>>>>
>>>> Hi,
>>>>
>>>>     I have a simple patch to demo the new behavior. With the patch,
>>>> the focus will go through the radiobuttons with mnemonic key Y when alt+y
>>>> is pressed instead of select the last.
>>>>
>>>>
>>>>  The patch is as follows:
>>>>
>>>> diff -r 554adcfb615e src/share/classes/javax/swing/KeyboardManager.java
>>>> --- a/src/share/classes/javax/swing/KeyboardManager.java	Wed Mar 16 15:01:07 2011 -0700
>>>> +++ b/src/share/classes/javax/swing/KeyboardManager.java	Thu Mar 17 14:57:14 2011 +0800
>>>> @@ -251,6 +251,93 @@
>>>>                   }
>>>>               } else if ( tmp instanceof Vector) { //more than one comp registered for this
>>>>                   Vector v = (Vector)tmp;
>>>> +
>>>> +                 /* The below code is added to make sure the focus is not always
>>>> +                    transferred to the last component in the vector when
>>>> +                    more than one component have the same mnemonic
>>>> +                 */
>>>> +	              if ((e.getModifiers() & Event.ALT_MASK) == Event.ALT_MASK) {
>>>> +                      /* Mnemonic key should transfer the focus only, do not select.
>>>> +                       * The following code works in this way:
>>>> +                       * 1. If only one component in the vector is visible, fireBinding on it.
>>>> +                       * 2. If multi-components in the vector are visible, move the focus to next component.
>>>> +                       *    2.1 If the next component is not a JAbstractButton, fireBinding on it.
>>>> +                       *    2.2 If the next component is a JMenu, which is a JAbstractButton, fireBinding
>>>> +                       *        on it to open the menu.
>>>> +                       *    2.3 If the next component is another JAbstractButton like JRadioButton. Request
>>>> +                       *        focus on it instead of fireBinding. To AVOID SELECTION & CLICK of the button.
>>>> +                       * 3. If the code is triggered by release event, fireBinding on current focus component
>>>> +                       *    instead of move focus.
>>>> +                       * 4. Further consideration: there may be more swing control like JMenu, or customized
>>>> +                       *    controls, which may break this behavior.
>>>> +                       */
>>>> +                      // This has alt as it's modifier so this could be a mnemonic
>>>> +                      Component focusOwner = KeyboardFocusManager.getCurrentKeyboardFocusManager().getFocusOwner();
>>>> +                      {
>>>> +                      // If only one visible component, invoke it.
>>>> +                      int visibleComponentCounter = 0;
>>>> +                      int nextFocus = 0;
>>>> +                      for (int i =  0; i < v.size(); i++){
>>>> +                          JComponent c = (JComponent) v.elementAt(i);
>>>> +                          if (c.isShowing() && c.isEnabled()){
>>>> +                    	         visibleComponentCounter++ ;
>>>> +                    		      nextFocus = i;
>>>> +                    	     }
>>>> +                      }
>>>> +                      if (visibleComponentCounter == 1){
>>>> +                    	     JComponent tmpc = (JComponent) v.elementAt(nextFocus);
>>>> +                    	     fireBinding(tmpc, ks, e, pressed);
>>>> +                          if (e.isConsumed())
>>>> +                        	  return true;
>>>> +                      }
>>>> +                      // If multi-components are visible, do not select the button, just move the focus.
>>>> +                      for (int counter = v.size() - 1; counter >= 0; counter--) {
>>>> +                          JComponent c = (JComponent) v.elementAt(counter);
>>>> +                          if (c.isShowing() && c.isEnabled()) {
>>>> +                              if ((c == focusOwner)
>>>> +                                       || (c instanceof JLabel && ((JLabel) c).getLabelFor() == focusOwner)) {
>>>> +                                  if (e.getID() == KeyEvent.KEY_RELEASED){
>>>> +                                	     nextFocus = counter;
>>>> +                                	     break;
>>>> +                                  }
>>>> +                            	    nextFocus = (counter - 1 + v.size()) % v.size();
>>>> +                                  break;
>>>> +                              }
>>>> +                          }
>>>> +                      }
>>>> +                      for (; nextFocus >= 0; nextFocus--) {
>>>> +                          JComponent c = (JComponent) v.elementAt(nextFocus);
>>>> +                          if (c.isShowing() && c.isEnabled()) {
>>>> +                              break;
>>>> +                          }
>>>> +                      }
>>>> +                      if (nextFocus >= 0) {
>>>> +                          JComponent tmpc = (JComponent) v.elementAt(nextFocus);
>>>> +                          // Next is the hack for this accessibility:
>>>> +                          // For general Buttons, do not press them, but request focus only.
>>>> +                          // For special buttons like JMenu, needs press.
>>>> +                          // If it is not a button, let the component handles by itself.
>>>> +                          if (!(tmpc instanceof javax.swing.AbstractButton)){
>>>> +                        	   fireBinding(tmpc, ks, e, pressed);
>>>> +                              if (e.isConsumed())
>>>> +                            	    return true;
>>>> +                          }
>>>> +                          if (tmpc instanceof JMenu ) {
>>>> +                              fireBinding(tmpc, ks, e, pressed);
>>>> +                              tmpc.requestFocusInWindow();
>>>> +                              if (e.isConsumed())
>>>> +                                  return true;
>>>> +                          } else {
>>>> +                              boolean result = tmpc.requestFocusInWindow();
>>>> +                              e.consume();
>>>> +                              return result;
>>>> +                          }
>>>> +                      }
>>>> +                      // If it is not handled here, default behavior is selecting the last.
>>>> +                      }
>>>> +                 }
>>>> +
>>>> +
>>>>                   // There is no well defined order for WHEN_IN_FOCUSED_WINDOW
>>>>                   // bindings, but we give precedence to those bindings just
>>>>                   // added. This is done so that JMenus WHEN_IN_FOCUSED_WINDOW
>>>>
>>>>
>>>>
>>>>
>>>> 2011/4/1 Sean Chou <zhouyx at linux.vnet.ibm.com>
>>>>
>>>> Hi all,
>>>>
>>>>     In daily use, we may encounter a problem of mnemonic key: there
>>>> may be several
>>>> controls want the same key to be set as mnemonic key. It is not common
>>>> but it does exist.
>>>>
>>>>     Current openjdk implementation allows users to set a same mnemonic
>>>> key for
>>>> different controls; but during the execution, when the mnemonic key is
>>>> pressed,
>>>> the last control always gets the action. Users are not able to touch
>>>> other controls with
>>>> that mnemonic key. This may confuse them.
>>>>
>>>>     If all the controls with the same mnemonic key can be accessed
>>>> through, for
>>>> example, when the mnemonic key is pressed, the focus is moved to the
>>>> last control,
>>>> and when the mnemonic key is pressed again, the focus is moved to the
>>>> second control
>>>> with that mnemonic, it will give user the choice to select other
>>>> controls.
>>>>
>>>>     Here is an example for the case:
>>>>
>>>>  package test;
>>>>
>>>>  import java.awt.BorderLayout;
>>>> import java.awt.Container;
>>>> import javax.swing.ButtonGroup;
>>>> import javax.swing.JFrame;
>>>> import javax.swing.JRadioButton;
>>>>
>>>>  public class TestFocus extends JFrame {
>>>>  public TestFocus() {
>>>>  Container pane = getContentPane();
>>>>  pane.setLayout(new BorderLayout());
>>>>  JRadioButton btn1,btn2,btn3;
>>>>  btn1 = new JRadioButton("Yes");
>>>>  btn1.setMnemonic('Y');
>>>>  btn2 = new JRadioButton("Yup");
>>>>  btn2.setMnemonic('Y');
>>>>  btn3 = new JRadioButton("No");
>>>>  btn3.setMnemonic('N');
>>>>  btn3.setSelected(true);
>>>>  ButtonGroup group = new ButtonGroup();
>>>>  group.add(btn1);
>>>>  group.add(btn2);
>>>>  group.add(btn3);
>>>>  pane.add(btn1,BorderLayout.NORTH);
>>>>  pane.add(btn2,BorderLayout.CENTER);
>>>>  pane.add(btn3,BorderLayout.SOUTH);
>>>>  setSize(200,200);
>>>>  setVisible(true);
>>>>  setDefaultCloseOperation(EXIT_ON_CLOSE);
>>>>  }
>>>>   public static void main(String[] args) {
>>>>  new TestFocus();
>>>>  }
>>>> }
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Best Regards,
>>>> Sean Chou
>>>>
>>>>
>>>>
>>>>
>>>>  --
>>>> Best Regards,
>>>> Sean Chou
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Best Regards,
>>>> Sean Chou
>>>>
>>>>
>>>>
>>>>
>>>>  --
>>>> Best Regards,
>>>> Sean Chou
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>  --
>>>> Best Regards,
>>>> Sean Chou
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>  --
>>>> Best Regards,
>>>> Sean Chou
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>  --
>>>> Best Regards,
>>>> Sean Chou
>>>>
>>>>
>>>>
>>>
>>>
>>>  --
>>> Best Regards,
>>> Sean Chou
>>>
>>>
>>>
>>
>>
>>  --
>> Best Regards,
>> Sean Chou
>>
>>
>>
>
>
>  --
> Best Regards,
> Sean Chou
>
>
>


-- 
Best Regards,
Sean Chou
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120222/f06eb4d4/attachment-0001.html 

From zhouyx at linux.vnet.ibm.com  Wed Feb 29 00:50:52 2012
From: zhouyx at linux.vnet.ibm.com (Sean Chou)
Date: Wed, 29 Feb 2012 16:50:52 +0800
Subject: <Swing Dev> Fwd: <AWT Dev> Request review for 7129742 : Unable
 to view focus in Non-Editable TextArea
In-Reply-To: <4F3B7A33.9020902@oracle.com>
References: <CAOo=rxXQK3Ztv2ER8GLaW=EWMaCyvS8xO2tTzQcPzH+Le2kXxA@mail.gmail.com>
	<4F1448A5.4050509@oracle.com>
	<CAOo=rxU2Xq27GgK1xDcw_oPSJ_OFZsD5d3L7OV=rycnpzpzrDA@mail.gmail.com>
	<CAOo=rxUC8TH2+sxY4MTL0GLkq1GDJJCp6WCWyszJuTVV7WMM2A@mail.gmail.com>
	<4F3B7A33.9020902@oracle.com>
Message-ID: <CAOo=rxVuZPgee27po6okss4C2x+b-uAOYjNm4Ui-8TJHri3HCA@mail.gmail.com>

Hi all,

   I updated the patch to as suggested and simplified the testcase .
Would anyone like to take a look again ? Thanks.

  The link is : http://cr.openjdk.java.net/~zhouyx/7129742/webrev.04/


On Wed, Feb 15, 2012 at 5:26 PM, Sergey Bylokhov <sergey.bylokhov at oracle.com
> wrote:

>  Hi Sean,
> In the XAWTCaret.super.focusGained(e) we check isEnabled() state of the
> component.
> Probably we should do it in the fix too, just to be closer to the old
> version?
> The problem applicable for textarea only? What about textfield?
>
>
> 15.02.2012 12:54, Sean Chou wrote:
>
> Hi all,
>
>    This is a patch for bug 7129742,
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129742 .
>
> Forwarded from awt-dev to swing-dev as it uses swing peer .
> The original discussion is
> http://mail.openjdk.java.net/pipermail/awt-dev/2012-January/002167.html .
> The patch is at  http://cr.openjdk.java.net/~zhouyx/7129742/webrev.01/  .
>
>    Would any one have a look ? Thanks.
>
>
> ---------- Forwarded message ----------
> From: Sean Chou <zhouyx at linux.vnet.ibm.com>
> Date: Mon, Feb 6, 2012 at 5:31 PM
> Subject: Re: <AWT Dev> Request review for 7129742 : Unable to view focus
> in Non-Editable TextArea
> To: Artem Ananiev <artem.ananiev at oracle.com>
> Cc: OpenJDK awt-dev <awt-dev at openjdk.java.net>, Alexander Potochkin <
> Alexander.Potochkin at oracle.com>, Pavel Porvatov <Pavel.Porvatov at oracle.com
> >
>
>
> Hi all,
>
>      The testcase is added, the new link is
> http://cr.openjdk.java.net/~zhouyx/7129742/webrev.01/  .
> Please review and give your comments.
>
>      When writing the testcase, I found the application would not exit if
> the caret is set visible. It is
> caused by the timer thread controlling the blinking of the caret. So I set
> the caret invisible when
> disposing the TextArea.
>
>      More info: The patch is for bug 7129742,
>     http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129742 .
>
>      Thanks.
>
>  On Mon, Jan 16, 2012 at 11:56 PM, Artem Ananiev <artem.ananiev at oracle.com
> > wrote:
>
>> Hi, Sean,
>>
>> text components in XToolkit use Swing peers, so this change should better
>> be reviewed on the swing-dev alias. To save everybody's time, I've asked
>> Alex and Pavel from the Swing team (in CC) to take a look and they confirm
>> the fix looks fine.
>>
>> Did you consider creating a new regression test for this fix? I'm not
>> sure it's easy to detect if caret is visible in the text component or not,
>> though.
>>
>> Thanks,
>>
>> Artem
>>
>>
>> On 1/16/2012 7:08 AM, Sean Chou wrote:
>>
>>> Hi all,
>>>
>>>    I made a patch for bug 7129742,
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7129742 .
>>> The webrev link is :
>>> http://cr.openjdk.java.net/~zhouyx/7129742/webrev.00/
>>>
>>>    The solution is very simple, just set the cursor visible.
>>>
>>>    Please have a look and give some comments. Thanks.
>>>
>>> --
>>> Best Regards,
>>> Sean Chou
>>>
>>>
>
>
>  --
> Best Regards,
> Sean Chou
>
>
>
>
> --
> Best Regards,
> Sean Chou
>
>
>
> --
> Best regards, Sergey.
>
>


-- 
Best Regards,
Sean Chou
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120229/dff3179e/attachment.html