From artem.ananiev at oracle.com  Sun Mar  4 22:08:04 2012
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Sun, 04 Mar 2012 22:08:04 -0800
Subject: <Swing Dev> Miglayout
In-Reply-To: <CAOeeQyo6JLthT5k=WS2f_0xV9BLAbycq6wwJq_wVLzY7wW8D3A@mail.gmail.com>
References: <CAOeeQyo6JLthT5k=WS2f_0xV9BLAbycq6wwJq_wVLzY7wW8D3A@mail.gmail.com>
Message-ID: <4F545844.3070905@oracle.com>


It should be discussed on the AWT/Swing alias, so I'm adding 
swing-dev at openjdk and bcc'ing discuss at openjdk.

Thanks,

Artem

On 3/4/2012 4:05 PM, Frans Thamura wrote:
> hi all
>
> just read this, a long bugs issue 2007
>
> and a little discussion with Geejan from Netbeans around MigLayout
>
> http://bugs.sun.com/bugdatabase/view_bug.do;jsessionid=e02b026c1ef0bffffffffdfbd57e8f43560d?bug_id=6530906
>
> any idea why, MIG Layout cannot be part of JDK?
>
>
> --
> Frans Thamura (???)
> Shadow Master and Lead Investor
> Meruvian.
> Integrated Hypermedia Java Solution Provider.
>
> Mobile: +628557888699
> Blog: http://blogs.mervpolis.com/roller/flatburger (id)
>
> FB: http://www.facebook.com/meruvian
> TW: http://www.twitter.com/meruvian / @meruvian
> Website: http://www.meruvian.org
>
> "We grow because we share the same belief."

From Alexander.Potochkin at oracle.com  Mon Mar  5 05:26:27 2012
From: Alexander.Potochkin at oracle.com (Alexander Potochkin)
Date: Mon, 05 Mar 2012 17:26:27 +0400
Subject: <Swing Dev> Miglayout
In-Reply-To: <4F545844.3070905@oracle.com>
References: <CAOeeQyo6JLthT5k=WS2f_0xV9BLAbycq6wwJq_wVLzY7wW8D3A@mail.gmail.com>
	<4F545844.3070905@oracle.com>
Message-ID: <4F54BF03.7070609@oracle.com>

Hello Frans

There are a lot of great Swing components
and there are also a list of good reasons why not to include them to the 
JDK:

1. Once a component is in JDK it becomes "frozen",
it can't be updated as quick as it used to be,
because the JDK updates don't go out every month.

2. Most of the API refactoring (even very small) will be impossible 
because of backward compatibility.

3. Adding a new methods is possible only in the *next major release*.

Every big Swing project has its own set of third-party components, look 
and feels and layouts
and we don't want to dictate what version of a component/layout/whatever 
they should use.

So we decided not to add any existing Swing components to the JDK.

The only new Swing feature in JDK 7 was JLayer
which required some fixes inside Swing to be completed.

Thanks
alexp
>
> It should be discussed on the AWT/Swing alias, so I'm adding 
> swing-dev at openjdk and bcc'ing discuss at openjdk.
>
> Thanks,
>
> Artem
>
> On 3/4/2012 4:05 PM, Frans Thamura wrote:
>> hi all
>>
>> just read this, a long bugs issue 2007
>>
>> and a little discussion with Geejan from Netbeans around MigLayout
>>
>> http://bugs.sun.com/bugdatabase/view_bug.do;jsessionid=e02b026c1ef0bffffffffdfbd57e8f43560d?bug_id=6530906 
>>
>>
>> any idea why, MIG Layout cannot be part of JDK?
>>
>>
>> -- 
>> Frans Thamura (???)
>> Shadow Master and Lead Investor
>> Meruvian.
>> Integrated Hypermedia Java Solution Provider.
>>
>> Mobile: +628557888699
>> Blog: http://blogs.mervpolis.com/roller/flatburger (id)
>>
>> FB: http://www.facebook.com/meruvian
>> TW: http://www.twitter.com/meruvian / @meruvian
>> Website: http://www.meruvian.org
>>
>> "We grow because we share the same belief."


From frans at meruvian.org  Mon Mar  5 05:30:43 2012
From: frans at meruvian.org (Frans Thamura)
Date: Mon, 5 Mar 2012 20:30:43 +0700
Subject: <Swing Dev> Miglayout
In-Reply-To: <4F54BF03.7070609@oracle.com>
References: <CAOeeQyo6JLthT5k=WS2f_0xV9BLAbycq6wwJq_wVLzY7wW8D3A@mail.gmail.com>
	<4F545844.3070905@oracle.com> <4F54BF03.7070609@oracle.com>
Message-ID: <CAOeeQyqVJQw16sU+uF9sV1V2dVSJm-6mcm6WbKM5HGKOYSijAA@mail.gmail.com>

No problem

Just see post like in the thread.
On Mar 5, 2012 8:26 PM, "Alexander Potochkin" <
Alexander.Potochkin at oracle.com> wrote:

> Hello Frans
>
> There are a lot of great Swing components
> and there are also a list of good reasons why not to include them to the
> JDK:
>
> 1. Once a component is in JDK it becomes "frozen",
> it can't be updated as quick as it used to be,
> because the JDK updates don't go out every month.
>
> 2. Most of the API refactoring (even very small) will be impossible
> because of backward compatibility.
>
> 3. Adding a new methods is possible only in the *next major release*.
>
> Every big Swing project has its own set of third-party components, look
> and feels and layouts
> and we don't want to dictate what version of a component/layout/whatever
> they should use.
>
> So we decided not to add any existing Swing components to the JDK.
>
> The only new Swing feature in JDK 7 was JLayer
> which required some fixes inside Swing to be completed.
>
> Thanks
> alexp
>
>>
>> It should be discussed on the AWT/Swing alias, so I'm adding
>> swing-dev at openjdk and bcc'ing discuss at openjdk.
>>
>> Thanks,
>>
>> Artem
>>
>> On 3/4/2012 4:05 PM, Frans Thamura wrote:
>>
>>> hi all
>>>
>>> just read this, a long bugs issue 2007
>>>
>>> and a little discussion with Geejan from Netbeans around MigLayout
>>>
>>> http://bugs.sun.com/**bugdatabase/view_bug.do;**jsessionid=**
>>> e02b026c1ef0bffffffffdfbd57e8f**43560d?bug_id=6530906<http://bugs.sun.com/bugdatabase/view_bug.do;jsessionid=e02b026c1ef0bffffffffdfbd57e8f43560d?bug_id=6530906>
>>>
>>> any idea why, MIG Layout cannot be part of JDK?
>>>
>>>
>>> --
>>> Frans Thamura (???)
>>> Shadow Master and Lead Investor
>>> Meruvian.
>>> Integrated Hypermedia Java Solution Provider.
>>>
>>> Mobile: +628557888699
>>> Blog: http://blogs.mervpolis.com/**roller/flatburger<http://blogs.mervpolis.com/roller/flatburger>(id)
>>>
>>> FB: http://www.facebook.com/**meruvian<http://www.facebook.com/meruvian>
>>> TW: http://www.twitter.com/**meruvian <http://www.twitter.com/meruvian>/ @meruvian
>>> Website: http://www.meruvian.org
>>>
>>> "We grow because we share the same belief."
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120305/2275500a/attachment.html 

From zhouyx at linux.vnet.ibm.com  Tue Mar  6 20:37:45 2012
From: zhouyx at linux.vnet.ibm.com (Sean Chou)
Date: Wed, 7 Mar 2012 12:37:45 +0800
Subject: <Swing Dev> Request review for 7129742 : Unable to view focus in
	Non-Editable TextArea
Message-ID: <CAOo=rxXMRHoBdnrhm38smXf9krRzEsWzneZAsSu65L_Da7+6kg@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 webrev is at : http://cr.openjdk.java.net/~zhouyx/7129742/webrev.04/

  Previous discussion at :
  http://mail.openjdk.java.net/pipermail/swing-dev/2012-February/001913.html

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

From Alexander.Potochkin at oracle.com  Sun Mar 11 10:27:15 2012
From: Alexander.Potochkin at oracle.com (Alexander Potochkin)
Date: Sun, 11 Mar 2012 21:27:15 +0400
Subject: <Swing Dev> Request review for 7129742 : Unable to view focus
 in Non-Editable TextArea
In-Reply-To: <CAOo=rxXMRHoBdnrhm38smXf9krRzEsWzneZAsSu65L_Da7+6kg@mail.gmail.com>
References: <CAOo=rxXMRHoBdnrhm38smXf9krRzEsWzneZAsSu65L_Da7+6kg@mail.gmail.com>
Message-ID: <4F5CE073.10108@oracle.com>

Hello Sean

Could you give more details about your changes in XTextFieldPeer?

Thanks
alexp

> Hi all,
>
>    I updated the patch to as suggested and simplified the testcase .
> Would anyone like to take a look again ? Thanks.
>
>   The webrev is at : 
> http://cr.openjdk.java.net/~zhouyx/7129742/webrev.04/ 
> <http://cr.openjdk.java.net/%7Ezhouyx/7129742/webrev.04/>
>
>   Previous discussion at :
> http://mail.openjdk.java.net/pipermail/swing-dev/2012-February/001913.html
>
> -- 
> Best Regards,
> Sean Chou
>


From zhouyx at linux.vnet.ibm.com  Sun Mar 11 20:17:57 2012
From: zhouyx at linux.vnet.ibm.com (Sean Chou)
Date: Mon, 12 Mar 2012 11:17:57 +0800
Subject: <Swing Dev> Request review for 7129742 : Unable to view focus
 in Non-Editable TextArea
In-Reply-To: <4F5CE073.10108@oracle.com>
References: <CAOo=rxXMRHoBdnrhm38smXf9krRzEsWzneZAsSu65L_Da7+6kg@mail.gmail.com>
	<4F5CE073.10108@oracle.com>
Message-ID: <CAOo=rxWMrZpWtg=LTa63jSE=aFfc2XSdFuJ6=6zizjet6rZ-kw@mail.gmail.com>

Hi Alexander,

    XTextFieldPeer and   XTextAreaPeer have a same inner class XAWTCaret,
and in  XTextAreaPeer  there is also a comment:
"// TODO : fix this duplicate code "   before XAWTCaret . So I removed
the XAWTCaret in XTextFieldPeer and changed the
XAWTCaret  into a static class, so XTextFieldPeer can
use XAWTCaret from XTextAreaPeer  .

    As XAWTCaret is only used in the following
method  in both XTextAreaPeer and  XTextFieldPeer .
protected Caret createCaret() {
 return new XAWTCaret();
 }
    I think this modification should not bring side effect.

On Mon, Mar 12, 2012 at 1:27 AM, Alexander Potochkin <
Alexander.Potochkin at oracle.com> wrote:

> Hello Sean
>
> Could you give more details about your changes in XTextFieldPeer?
>
> Thanks
> alexp
>
>  Hi all,
>>
>>   I updated the patch to as suggested and simplified the testcase .
>> Would anyone like to take a look again ? Thanks.
>>
>>  The webrev is at : http://cr.openjdk.java.net/~**
>> zhouyx/7129742/webrev.04/<http://cr.openjdk.java.net/~zhouyx/7129742/webrev.04/><
>> http://cr.openjdk.java.net/%**7Ezhouyx/7129742/webrev.04/<http://cr.openjdk.java.net/%7Ezhouyx/7129742/webrev.04/>
>> >
>>
>>
>>  Previous discussion at :
>> http://mail.openjdk.java.net/**pipermail/swing-dev/2012-**
>> February/001913.html<http://mail.openjdk.java.net/pipermail/swing-dev/2012-February/001913.html>
>>
>> --
>> 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/20120312/71d5bb51/attachment.html 

From Alexander.Potochkin at oracle.com  Mon Mar 12 06:02:04 2012
From: Alexander.Potochkin at oracle.com (Alexander Potochkin)
Date: Mon, 12 Mar 2012 17:02:04 +0400
Subject: <Swing Dev> Request review for 7129742 : Unable to view focus
 in Non-Editable TextArea
In-Reply-To: <CAOo=rxWMrZpWtg=LTa63jSE=aFfc2XSdFuJ6=6zizjet6rZ-kw@mail.gmail.com>
References: <CAOo=rxXMRHoBdnrhm38smXf9krRzEsWzneZAsSu65L_Da7+6kg@mail.gmail.com>
	<4F5CE073.10108@oracle.com>
	<CAOo=rxWMrZpWtg=LTa63jSE=aFfc2XSdFuJ6=6zizjet6rZ-kw@mail.gmail.com>
Message-ID: <4F5DF3CC.7020107@oracle.com>

Hello Sean

Thanks for the details
The fix looks good for me!

alexp

> Hi Alexander,
>
>     XTextFieldPeer and   XTextAreaPeer have a same inner 
> class XAWTCaret, and in  XTextAreaPeer  there is also a comment:
> "// TODO : fix this duplicate code "   before XAWTCaret . So I removed 
> the XAWTCaret in XTextFieldPeer and changed the
> XAWTCaret  into a static class, so XTextFieldPeer can 
> use XAWTCaret from XTextAreaPeer  .
>
>     As XAWTCaret is only used in the following 
> method  in both XTextAreaPeer and  XTextFieldPeer .
> protected Caret createCaret() {
>  return new XAWTCaret();
>  }
>     I think this modification should not bring side effect.
>
> On Mon, Mar 12, 2012 at 1:27 AM, Alexander Potochkin 
> <Alexander.Potochkin at oracle.com 
> <mailto:Alexander.Potochkin at oracle.com>> wrote:
>
>     Hello Sean
>
>     Could you give more details about your changes in XTextFieldPeer?
>
>     Thanks
>     alexp
>
>         Hi all,
>
>           I updated the patch to as suggested and simplified the
>         testcase .
>         Would anyone like to take a look again ? Thanks.
>
>          The webrev is at :
>         http://cr.openjdk.java.net/~zhouyx/7129742/webrev.04/
>         <http://cr.openjdk.java.net/%7Ezhouyx/7129742/webrev.04/>
>         <http://cr.openjdk.java.net/%7Ezhouyx/7129742/webrev.04/>
>
>
>          Previous discussion at :
>         http://mail.openjdk.java.net/pipermail/swing-dev/2012-February/001913.html
>
>         -- 
>         Best Regards,
>         Sean Chou
>
>
>
>
>
> -- 
> Best Regards,
> Sean Chou
>


From zhouyx at linux.vnet.ibm.com  Mon Mar 12 06:23:47 2012
From: zhouyx at linux.vnet.ibm.com (Sean Chou)
Date: Mon, 12 Mar 2012 21:23:47 +0800
Subject: <Swing Dev> Request review for 7129742 : Unable to view focus
 in Non-Editable TextArea
In-Reply-To: <4F5DF3CC.7020107@oracle.com>
References: <CAOo=rxXMRHoBdnrhm38smXf9krRzEsWzneZAsSu65L_Da7+6kg@mail.gmail.com>
	<4F5CE073.10108@oracle.com>
	<CAOo=rxWMrZpWtg=LTa63jSE=aFfc2XSdFuJ6=6zizjet6rZ-kw@mail.gmail.com>
	<4F5DF3CC.7020107@oracle.com>
Message-ID: <CAOo=rxVpyZjh4MtOdgTgHkoFdt8YDnS6-d0Gvnpfgg4O=a+0YA@mail.gmail.com>

Thanks for your time !

On Mon, Mar 12, 2012 at 9:02 PM, Alexander Potochkin <
Alexander.Potochkin at oracle.com> wrote:

> Hello Sean
>
> Thanks for the details
> The fix looks good for me!
>
> alexp
>
>  Hi Alexander,
>>
>>    XTextFieldPeer and   XTextAreaPeer have a same inner class XAWTCaret,
>> and in  XTextAreaPeer  there is also a comment:
>> "// TODO : fix this duplicate code "   before XAWTCaret . So I removed
>> the XAWTCaret in XTextFieldPeer and changed the
>> XAWTCaret  into a static class, so XTextFieldPeer can use XAWTCaret from
>> XTextAreaPeer  .
>>
>>    As XAWTCaret is only used in the following method  in both
>> XTextAreaPeer and  XTextFieldPeer .
>> protected Caret createCaret() {
>>  return new XAWTCaret();
>>  }
>>    I think this modification should not bring side effect.
>>
>> On Mon, Mar 12, 2012 at 1:27 AM, Alexander Potochkin <
>> Alexander.Potochkin at oracle.**com <Alexander.Potochkin at oracle.com><mailto:
>> Alexander.Potochkin@**oracle.com <Alexander.Potochkin at oracle.com>>>
>> wrote:
>>
>>    Hello Sean
>>
>>    Could you give more details about your changes in XTextFieldPeer?
>>
>>    Thanks
>>    alexp
>>
>>        Hi all,
>>
>>          I updated the patch to as suggested and simplified the
>>        testcase .
>>        Would anyone like to take a look again ? Thanks.
>>
>>         The webrev is at :
>>        http://cr.openjdk.java.net/~**zhouyx/7129742/webrev.04/<http://cr.openjdk.java.net/~zhouyx/7129742/webrev.04/>
>>        <http://cr.openjdk.java.net/%**7Ezhouyx/7129742/webrev.04/<http://cr.openjdk.java.net/%7Ezhouyx/7129742/webrev.04/>
>> >
>>        <http://cr.openjdk.java.net/%**7Ezhouyx/7129742/webrev.04/<http://cr.openjdk.java.net/%7Ezhouyx/7129742/webrev.04/>
>> >
>>
>>
>>         Previous discussion at :
>>        http://mail.openjdk.java.net/**pipermail/swing-dev/2012-**
>> February/001913.html<http://mail.openjdk.java.net/pipermail/swing-dev/2012-February/001913.html>
>>
>>        --         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/20120312/36bf222a/attachment.html 

From pavel.porvatov at oracle.com  Tue Mar 13 06:49:34 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Tue, 13 Mar 2012 17:49:34 +0400
Subject: <Swing Dev> Request review for 7129742 : Unable to view focus
 in Non-Editable TextArea
In-Reply-To: <CAOo=rxWMrZpWtg=LTa63jSE=aFfc2XSdFuJ6=6zizjet6rZ-kw@mail.gmail.com>
References: <CAOo=rxXMRHoBdnrhm38smXf9krRzEsWzneZAsSu65L_Da7+6kg@mail.gmail.com>
	<4F5CE073.10108@oracle.com>
	<CAOo=rxWMrZpWtg=LTa63jSE=aFfc2XSdFuJ6=6zizjet6rZ-kw@mail.gmail.com>
Message-ID: <4F5F506E.6070600@oracle.com>

Hi Sean,

I have a couple questions about the following code in the 
XTextAreaPeer.java class
+        // visible caret has a timer thread, which must be stopped
+        jtext.getCaret().setVisible(false);

1. Why this code wasn't needed before your fix, when caret was visible 
for enabled text area?
2. Why don't we need the same code in the XTextFieldPeer class?

About the bug7129742 test:
Because of the passed field is used from different threads you must use 
synchronization or mark the field as a volatile.

Regards, Pavel

> Hi Alexander,
>
>     XTextFieldPeer and   XTextAreaPeer have a same inner 
> class XAWTCaret, and in  XTextAreaPeer  there is also a comment:
> "// TODO : fix this duplicate code "   before XAWTCaret . So I removed 
> the XAWTCaret in XTextFieldPeer and changed the
> XAWTCaret  into a static class, so XTextFieldPeer can 
> use XAWTCaret from XTextAreaPeer  .
>
>     As XAWTCaret is only used in the following 
> method  in both XTextAreaPeer and  XTextFieldPeer .
> protected Caret createCaret() {
>  return new XAWTCaret();
>  }
>     I think this modification should not bring side effect.
>
> On Mon, Mar 12, 2012 at 1:27 AM, Alexander Potochkin 
> <Alexander.Potochkin at oracle.com 
> <mailto:Alexander.Potochkin at oracle.com>> wrote:
>
>     Hello Sean
>
>     Could you give more details about your changes in XTextFieldPeer?
>
>     Thanks
>     alexp
>
>         Hi all,
>
>           I updated the patch to as suggested and simplified the
>         testcase .
>         Would anyone like to take a look again ? Thanks.
>
>          The webrev is at :
>         http://cr.openjdk.java.net/~zhouyx/7129742/webrev.04/
>         <http://cr.openjdk.java.net/%7Ezhouyx/7129742/webrev.04/>
>         <http://cr.openjdk.java.net/%7Ezhouyx/7129742/webrev.04/>
>
>
>          Previous discussion at :
>         http://mail.openjdk.java.net/pipermail/swing-dev/2012-February/001913.html
>
>         -- 
>         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/20120313/568637b6/attachment.html 

From zhouyx at linux.vnet.ibm.com  Wed Mar 14 00:48:46 2012
From: zhouyx at linux.vnet.ibm.com (Sean Chou)
Date: Wed, 14 Mar 2012 15:48:46 +0800
Subject: <Swing Dev> Request review for 7129742 : Unable to view focus
 in Non-Editable TextArea
In-Reply-To: <4F5F506E.6070600@oracle.com>
References: <CAOo=rxXMRHoBdnrhm38smXf9krRzEsWzneZAsSu65L_Da7+6kg@mail.gmail.com>
	<4F5CE073.10108@oracle.com>
	<CAOo=rxWMrZpWtg=LTa63jSE=aFfc2XSdFuJ6=6zizjet6rZ-kw@mail.gmail.com>
	<4F5F506E.6070600@oracle.com>
Message-ID: <CAOo=rxVs2jHEnFgp9zOLmk-mfGioAn1bCO-gJKqVYQ5z562dcQ@mail.gmail.com>

Hi Pavel,

   Thanks for your comments.

About the 1st question, I modified the testcase a little to demonstrate the
problem, testcase is pasted at the end.

If textArea.setEditable(true) is executed, the frame disposes, but
application doesn't exit.
If textArea.setEditable(false), the application exits as normal.

java 1.7.0_01 and latest java8 code are tested.  And TextField contains
this problem as well. I'll add it to fix later.
Shall I report a separate bug for it ?


About the 2nd question, I was driven by the comment "// TODO : fix this
duplicate code". Is there any strong reason to keep it ?


///////////////////////////////////  a testcase
 ////////////////////////////////////////////////////////////
/*
 * Copyright (c) 2012 Oracle and/or its affiliates. All rights reserved.
 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 *
 * This code is free software; you can redistribute it and/or modify it
 * under the terms of the GNU General Public License version 2 only, as
 * published by the Free Software Foundation.
 *
 * This code is distributed in the hope that it will be useful, but WITHOUT
 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
 * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
 * version 2 for more details (a copy is included in the LICENSE file that
 * accompanied this code).
 *
 * You should have received a copy of the GNU General Public License version
 * 2 along with this work; if not, write to the Free Software Foundation,
 * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 *
 * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
 * or visit www.oracle.com if you need additional information or have any
 * questions.
 */

/*
 * Portions Copyright (c) 2012 IBM Corporation
 */

/* @test
 * @bug
 * @summary editable TextArea blocks gui app from dispose.
 * @author Sean Chou
 */

import java.awt.FlowLayout;
import java.awt.Frame;
import java.awt.TextArea;
import java.awt.Toolkit;
import java.lang.reflect.Field;

import javax.swing.JFrame;
import javax.swing.JTextArea;
import javax.swing.SwingUtilities;
import javax.swing.text.DefaultCaret;

import sun.awt.SunToolkit;

public class TextAreaDisposeBug {
    public static volatile boolean passed = false;

    public static Frame frame = null;
    public static TextArea textArea = null;

    public static DefaultCaret caret = null;
    public static Class XTextAreaPeerClzz = null;

    public static void main(String[] args) throws Exception {
        SunToolkit toolkit = (SunToolkit) Toolkit.getDefaultToolkit();
        SwingUtilities.invokeAndWait(new Runnable() {
            @Override
            public void run() {
                frame = new JFrame("Test");

                textArea = new TextArea("editable textArea");
                textArea.setEditable(true);
//                textArea.setEditable(false);

                frame.setLayout(new FlowLayout());
                frame.add(textArea);

                frame.pack();
                frame.setVisible(true);

            }
        });
        toolkit.realSync();

        SwingUtilities.invokeAndWait(new Runnable() {
            @Override
            public void run() {
                frame.dispose();
            }
        });
        toolkit.realSync();
    }

}


//////////////////////////////////////////////////////////////////////////////////////////
/*
 * Copyright (c) 2012 Oracle and/or its affiliates. All rights reserved.
 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 *
 * This code is free software; you can redistribute it and/or modify it
 * under the terms of the GNU General Public License version 2 only, as
 * published by the Free Software Foundation.
 *
 * This code is distributed in the hope that it will be useful, but WITHOUT
 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
 * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
 * version 2 for more details (a copy is included in the LICENSE file that
 * accompanied this code).
 *
 * You should have received a copy of the GNU General Public License version
 * 2 along with this work; if not, write to the Free Software Foundation,
 * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 *
 * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
 * or visit www.oracle.com if you need additional information or have any
 * questions.
 */

/*
 * Portions Copyright (c) 2012 IBM Corporation
 */


/* @test
 * @bug
 * @summary editable TextField blocks gui app from dispose.
 * @author Sean Chou
 */

import java.awt.FlowLayout;
import java.awt.Frame;
import java.awt.TextField;
import java.awt.Toolkit;
import java.lang.reflect.Field;

import javax.swing.JFrame;
import javax.swing.JTextArea;
import javax.swing.SwingUtilities;
import javax.swing.text.DefaultCaret;

import sun.awt.SunToolkit;

public class TextFieldDisposeBug {
    public static volatile boolean passed = false;

    public static Frame frame = null;
    public static TextField textField = null;

    public static DefaultCaret caret = null;
    public static Class XTextAreaPeerClzz = null;

    public static void main(String[] args) throws Exception {
        SunToolkit toolkit = (SunToolkit) Toolkit.getDefaultToolkit();
        SwingUtilities.invokeAndWait(new Runnable() {
            @Override
            public void run() {
                frame = new JFrame("Test");

                textField = new TextField("editable textArea");
//                textField.setEditable(true);
                textField.setEditable(false);

                frame.setLayout(new FlowLayout());
                frame.add(textField);

                frame.pack();
                frame.setVisible(true);

            }
        });
        toolkit.realSync();

        SwingUtilities.invokeAndWait(new Runnable() {
            @Override
            public void run() {
                frame.dispose();
            }
        });
        toolkit.realSync();
    }

}


On Tue, Mar 13, 2012 at 9:49 PM, Pavel Porvatov
<pavel.porvatov at oracle.com>wrote:

>  Hi Sean,
>
> I have a couple questions about the following code in the
> XTextAreaPeer.java class
> +        // visible caret has a timer thread, which must be stopped
> +        jtext.getCaret().setVisible(false);
>
> 1. Why this code wasn't needed before your fix, when caret was visible for
> enabled text area?
> 2. Why don't we need the same code in the XTextFieldPeer class?
>
> About the bug7129742 test:
> Because of the passed field is used from different threads you must use
> synchronization or mark the field as a volatile.
>
> Regards, Pavel
>
>
> Hi Alexander,
>
>      XTextFieldPeer and   XTextAreaPeer have a same inner
> class XAWTCaret, and in  XTextAreaPeer  there is also a comment:
> "// TODO : fix this duplicate code "   before XAWTCaret . So I removed
> the XAWTCaret in XTextFieldPeer and changed the
> XAWTCaret  into a static class, so XTextFieldPeer can
> use XAWTCaret from XTextAreaPeer  .
>
>      As XAWTCaret is only used in the following
> method  in both XTextAreaPeer and  XTextFieldPeer .
> protected Caret createCaret() {
>  return new XAWTCaret();
>  }
>      I think this modification should not bring side effect.
>
>  On Mon, Mar 12, 2012 at 1:27 AM, Alexander Potochkin <
> Alexander.Potochkin at oracle.com> wrote:
>
>> Hello Sean
>>
>> Could you give more details about your changes in XTextFieldPeer?
>>
>> Thanks
>> alexp
>>
>>  Hi all,
>>>
>>>   I updated the patch to as suggested and simplified the testcase .
>>> Would anyone like to take a look again ? Thanks.
>>>
>>>   The webrev is at :
>>> http://cr.openjdk.java.net/~zhouyx/7129742/webrev.04/ <
>>> http://cr.openjdk.java.net/%7Ezhouyx/7129742/webrev.04/>
>>>
>>>
>>>  Previous discussion at :
>>>
>>> http://mail.openjdk.java.net/pipermail/swing-dev/2012-February/001913.html
>>>
>>> --
>>> 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/20120314/5efc66c4/attachment.html 

From sanjayacl at gmail.com  Wed Mar 14 09:07:19 2012
From: sanjayacl at gmail.com (Sanjaya Liyanage)
Date: Wed, 14 Mar 2012 21:37:19 +0530
Subject: <Swing Dev> Selecting cells in jtable
Message-ID: <CAK94idsAWqXYpxAQ68vK8gv18PORRLFC4yHczACwCohv0=-fsg@mail.gmail.com>

Hi,
   I have a jtable with 5 rows and 5 columns.I want to select the
following diagonal cell when the enter key is pressed.Initially 0,0
cell is selected.(1,1),(2,2),(3,3),(4,4) cells should be selected when
the enter key is pressed 4 times consecutively.How can I do this?

thank you
Sanjaya

From pavel.porvatov at oracle.com  Thu Mar 15 03:15:02 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Thu, 15 Mar 2012 14:15:02 +0400
Subject: <Swing Dev> Selecting cells in jtable
In-Reply-To: <CAK94idsAWqXYpxAQ68vK8gv18PORRLFC4yHczACwCohv0=-fsg@mail.gmail.com>
References: <CAK94idsAWqXYpxAQ68vK8gv18PORRLFC4yHczACwCohv0=-fsg@mail.gmail.com>
Message-ID: <4F61C126.5020607@oracle.com>

Hi Sanjaya,

Take a look at the javadoc for the JTable#setCellSelectionEnabled method:

      * Sets whether this table allows both a column selection and a
      * row selection to exist simultaneously. When set,
      * the table treats the intersection of the row and column selection
      * models as the selected cells. Override 
<code>isCellSelected</code> to
      * change this default behavior

So, for your purpose you have to override isCellSelected....

Regards, Pavel
> Hi,
>     I have a jtable with 5 rows and 5 columns.I want to select the
> following diagonal cell when the enter key is pressed.Initially 0,0
> cell is selected.(1,1),(2,2),(3,3),(4,4) cells should be selected when
> the enter key is pressed 4 times consecutively.How can I do this?
>
> thank you
> Sanjaya


From pavel.porvatov at oracle.com  Thu Mar 15 05:57:27 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Thu, 15 Mar 2012 16:57:27 +0400
Subject: <Swing Dev> Request review for 7129742 : Unable to view focus
 in Non-Editable TextArea
In-Reply-To: <CAOo=rxVs2jHEnFgp9zOLmk-mfGioAn1bCO-gJKqVYQ5z562dcQ@mail.gmail.com>
References: <CAOo=rxXMRHoBdnrhm38smXf9krRzEsWzneZAsSu65L_Da7+6kg@mail.gmail.com>
	<4F5CE073.10108@oracle.com>
	<CAOo=rxWMrZpWtg=LTa63jSE=aFfc2XSdFuJ6=6zizjet6rZ-kw@mail.gmail.com>
	<4F5F506E.6070600@oracle.com>
	<CAOo=rxVs2jHEnFgp9zOLmk-mfGioAn1bCO-gJKqVYQ5z562dcQ@mail.gmail.com>
Message-ID: <4F61E737.7010201@oracle.com>

Hi Sean,
>
> Hi Pavel,
>
>    Thanks for your comments.
>
> About the 1st question, I modified the testcase a little to 
> demonstrate the problem, testcase is pasted at the end.
>
> If textArea.setEditable(true) is executed, the frame disposes, but 
> application doesn't exit.
> If textArea.setEditable(false), the application exits as normal.
>
> java 1.7.0_01 and latest java8 code are tested.  And TextField 
> contains this problem as well. I'll add it to fix later.
> Shall I report a separate bug for it ?
Yes. I think it will be better if you fix the described above problem as 
a separate bug. Note that it should be reviewed by the AWT team...
>
>
> About the 2nd question, I was driven by the comment "// TODO : fix 
> this duplicate code". Is there any strong reason to keep it ?
I'm absolutely agree with removing duplicate code. My second question 
was about added by you "jtext.getCaret().setVisible(false)" in the 
XTextAreaPeer.java class. I wrote:
2. Why don't we need the same code in the XTextFieldPeer class?

As I can see you've noticed that XTextFieldPeer should be fixed as well 
(in a separate fix with XTextAreaPeer)

Regards, Pavel
>
>
> ///////////////////////////////////  a testcase 
>  ////////////////////////////////////////////////////////////
> /*
>  * Copyright (c) 2012 Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
>  * under the terms of the GNU General Public License version 2 only, as
>  * published by the Free Software Foundation.
>  *
>  * This code is distributed in the hope that it will be useful, but 
> WITHOUT
>  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>  * version 2 for more details (a copy is included in the LICENSE file that
>  * accompanied this code).
>  *
>  * You should have received a copy of the GNU General Public License 
> version
>  * 2 along with this work; if not, write to the Free Software Foundation,
>  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>  *
>  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>  * or visit www.oracle.com <http://www.oracle.com> if you need 
> additional information or have any
>  * questions.
>  */
>
> /*
>  * Portions Copyright (c) 2012 IBM Corporation
>  */
>
> /* @test
>  * @bug
>  * @summary editable TextArea blocks gui app from dispose.
>  * @author Sean Chou
>  */
>
> import java.awt.FlowLayout;
> import java.awt.Frame;
> import java.awt.TextArea;
> import java.awt.Toolkit;
> import java.lang.reflect.Field;
>
> import javax.swing.JFrame;
> import javax.swing.JTextArea;
> import javax.swing.SwingUtilities;
> import javax.swing.text.DefaultCaret;
>
> import sun.awt.SunToolkit;
>
> public class TextAreaDisposeBug {
>     public static volatile boolean passed = false;
>
>     public static Frame frame = null;
>     public static TextArea textArea = null;
>
>     public static DefaultCaret caret = null;
>     public static Class XTextAreaPeerClzz = null;
>
>     public static void main(String[] args) throws Exception {
>         SunToolkit toolkit = (SunToolkit) Toolkit.getDefaultToolkit();
>         SwingUtilities.invokeAndWait(new Runnable() {
>             @Override
>             public void run() {
>                 frame = new JFrame("Test");
>                 textArea = new TextArea("editable textArea");
>                 textArea.setEditable(true);
> //                textArea.setEditable(false);
>
>                 frame.setLayout(new FlowLayout());
>                 frame.add(textArea);
>
>                 frame.pack();
>                 frame.setVisible(true);
>             }
>         });
>         toolkit.realSync();
>         SwingUtilities.invokeAndWait(new Runnable() {
>             @Override
>             public void run() {
>                 frame.dispose();
>             }
>         });
>         toolkit.realSync();
>     }
>
> }
>
>
> ////////////////////////////////////////////////////////////////////////////////////////// 
>
> /*
>  * Copyright (c) 2012 Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
>  * under the terms of the GNU General Public License version 2 only, as
>  * published by the Free Software Foundation.
>  *
>  * This code is distributed in the hope that it will be useful, but 
> WITHOUT
>  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>  * version 2 for more details (a copy is included in the LICENSE file that
>  * accompanied this code).
>  *
>  * You should have received a copy of the GNU General Public License 
> version
>  * 2 along with this work; if not, write to the Free Software Foundation,
>  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>  *
>  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>  * or visit www.oracle.com <http://www.oracle.com> if you need 
> additional information or have any
>  * questions.
>  */
>
> /*
>  * Portions Copyright (c) 2012 IBM Corporation
>  */
>
>
> /* @test
>  * @bug
>  * @summary editable TextField blocks gui app from dispose.
>  * @author Sean Chou
>  */
>
> import java.awt.FlowLayout;
> import java.awt.Frame;
> import java.awt.TextField;
> import java.awt.Toolkit;
> import java.lang.reflect.Field;
>
> import javax.swing.JFrame;
> import javax.swing.JTextArea;
> import javax.swing.SwingUtilities;
> import javax.swing.text.DefaultCaret;
>
> import sun.awt.SunToolkit;
>
> public class TextFieldDisposeBug {
>     public static volatile boolean passed = false;
>
>     public static Frame frame = null;
>     public static TextField textField = null;
>
>     public static DefaultCaret caret = null;
>     public static Class XTextAreaPeerClzz = null;
>
>     public static void main(String[] args) throws Exception {
>         SunToolkit toolkit = (SunToolkit) Toolkit.getDefaultToolkit();
>         SwingUtilities.invokeAndWait(new Runnable() {
>             @Override
>             public void run() {
>                 frame = new JFrame("Test");
>                 textField = new TextField("editable textArea");
> //                textField.setEditable(true);
>                 textField.setEditable(false);
>
>                 frame.setLayout(new FlowLayout());
>                 frame.add(textField);
>
>                 frame.pack();
>                 frame.setVisible(true);
>             }
>         });
>         toolkit.realSync();
>         SwingUtilities.invokeAndWait(new Runnable() {
>             @Override
>             public void run() {
>                 frame.dispose();
>             }
>         });
>         toolkit.realSync();
>     }
>
> }
>
>
> On Tue, Mar 13, 2012 at 9:49 PM, Pavel Porvatov 
> <pavel.porvatov at oracle.com <mailto:pavel.porvatov at oracle.com>> wrote:
>
>     Hi Sean,
>
>     I have a couple questions about the following code in the
>     XTextAreaPeer.java class
>     +        // visible caret has a timer thread, which must be stopped
>     +        jtext.getCaret().setVisible(false);
>
>     1. Why this code wasn't needed before your fix, when caret was
>     visible for enabled text area?
>     2. Why don't we need the same code in the XTextFieldPeer class?
>
>     About the bug7129742 test:
>     Because of the passed field is used from different threads you
>     must use synchronization or mark the field as a volatile.
>
>     Regards, Pavel
>
>
>>     Hi Alexander,
>>
>>         XTextFieldPeer and   XTextAreaPeer have a same inner
>>     class XAWTCaret, and in  XTextAreaPeer  there is also a comment:
>>     "// TODO : fix this duplicate code "   before XAWTCaret . So I
>>     removed the XAWTCaret in XTextFieldPeer and changed the
>>     XAWTCaret  into a static class, so XTextFieldPeer can
>>     use XAWTCaret from XTextAreaPeer  .
>>
>>         As XAWTCaret is only used in the following
>>     method  in both XTextAreaPeer and  XTextFieldPeer .
>>     protected Caret createCaret() {
>>      return new XAWTCaret();
>>      }
>>         I think this modification should not bring side effect.
>>
>>     On Mon, Mar 12, 2012 at 1:27 AM, Alexander Potochkin
>>     <Alexander.Potochkin at oracle.com
>>     <mailto:Alexander.Potochkin at oracle.com>> wrote:
>>
>>         Hello Sean
>>
>>         Could you give more details about your changes in XTextFieldPeer?
>>
>>         Thanks
>>         alexp
>>
>>             Hi all,
>>
>>               I updated the patch to as suggested and simplified the
>>             testcase .
>>             Would anyone like to take a look again ? Thanks.
>>
>>              The webrev is at :
>>             http://cr.openjdk.java.net/~zhouyx/7129742/webrev.04/
>>             <http://cr.openjdk.java.net/%7Ezhouyx/7129742/webrev.04/>
>>             <http://cr.openjdk.java.net/%7Ezhouyx/7129742/webrev.04/>
>>
>>
>>              Previous discussion at :
>>             http://mail.openjdk.java.net/pipermail/swing-dev/2012-February/001913.html
>>
>>             -- 
>>             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/20120315/c10606db/attachment-0001.html 

From artem.ananiev at oracle.com  Tue Mar 20 01:54:11 2012
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Tue, 20 Mar 2012 12:54:11 +0400
Subject: <Swing Dev> <AWT Dev> Review request for 7154030:
 java.awt.Component.hide() does not repaint parent container
In-Reply-To: <CAC-GWLenUzrra+P3_U3mQuho34Oj3OXRE+ievM44WarNYS4G7w@mail.gmail.com>
References: <CAC-GWLe8d6mR+tyoEKOuSb4A8Caun-9_NcTePV7+i0McJjsO+w@mail.gmail.com>
	<4F67511F.5040109@oracle.com>
	<CAC-GWLenUzrra+P3_U3mQuho34Oj3OXRE+ievM44WarNYS4G7w@mail.gmail.com>
Message-ID: <4F6845B3.1060506@oracle.com>

Hi, Jonathan,

I'm adding swing-dev to CC as we now consider changing Swing code.

What you propose sounds technically reasonable, but I don't think it is 
worth doing anyway as show() and hide() have been deprecated for years now.

Even if we accept the change in JComponent.hide(), we should then 
override show() as well (lightweight component may be non-opaque, so we 
should repaint from its parent), so there will be code duplication. This 
is one more reason to leave all as is.

This is my personal opinion, I'm not a Swing expert, though. Let anyone 
from the Swing group comment.

Thanks,

Artem

On 3/20/2012 12:28 PM, Jonathan Lu wrote:
> Hi Artem,
>
> Thanks for your time.
>
> 2012/3/19 Artem Ananiev <artem.ananiev at oracle.com
> <mailto:artem.ananiev at oracle.com>>
>
>     Hi, Jonathan,
>
>     given the code in java.awt.Component, your statement about
>     difference between hide() and setVisible(false) looks pretty strange
>     to me. Indeed, here is the implementation:
>
>
>
>         public void show(boolean b) {
>             if (b) {
>                 show();
>             } else {
>                 hide();
>             }
>         }
>
>     and
>
>         public void setVisible(boolean b) {
>             show(b);
>         }
>
>     In JComponent the latter method is overridden and adds exactly what
>     you propose: parent.repaint(). This addition makes sense for
>     lightweight components (e.g. Swing), but heavyweight AWT components
>     shouldn't require this: repaint request is sent from the native system.
>
>
> Yes, lightweight and  heavyweight components differ in painting. The
> original test case only works for the conditions of lightweight
> components, with another test case for heavyweight components, I found
> that the problem could not be reproduced on AWT any more. I think the
> change is only applicable for Swing components, so how about repaint in
> JComponent.hide() like this?
>
> diff -r cdbb33303ea3 src/share/classes/javax/swing/JComponent.java
> --- a/src/share/classes/javax/swing/JComponent.java    Wed Mar 14
> 13:50:37 2012 -0700 <tel:2012%20-0700>
> +++ b/src/share/classes/javax/swing/JComponent.java    Tue Mar 20
> 16:24:09 2012 +0800
> @@ -5237,6 +5237,16 @@
>           }
>       }
>
> +    public void hide() {
> +        super.hide();
> +        Container parent = getParent();
> +        if (parent != null) {
> +            Rectangle r = getBounds();
> +            parent.repaint(r.x, r.y, r.width, r.height);
> +            parent.invalidate();
> +        }
> +    }
> +
>       /**
>        * Returns whether or not the region of the specified component is
>        * obscured by a sibling.
>
>
>
>     Thanks,
>
>     Artem
>
>
>     On 3/15/2012 12:24 PM, Jonathan Lu wrote:
>
>         Hi awt-dev,
>
>         java.awt.Component.hide() was declared as deprecation and
>         replaced by
>         setVisible(boolean), but in my tests, it does not works in the
>         same way
>         as setVisible(false). The reason of this failure is that
>         java.awt.Component.hide() does not repaint the special area it
>         used to
>         taken of parent container. Although this is deprecated method,
>         it may
>         still valuable for customers due to compatibility reason. Bug
>         7154030
>         created for this issue.
>
>         Here's a simple test case to demonstrate this problem.
>
>         /*
>           * Copyright (c) 2012 Oracle and/or its affiliates. All rights
>         reserved.
>           * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>           *
>           * This code is free software; you can redistribute it and/or
>         modify it
>           * under the terms of the GNU General Public License version 2
>         only, as
>           * published by the Free Software Foundation.
>           *
>           * This code is distributed in the hope that it will be useful, but
>         WITHOUT
>           * ANY WARRANTY; without even the implied warranty of
>         MERCHANTABILITY or
>           * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General
>         Public License
>           * version 2 for more details (a copy is included in the
>         LICENSE file that
>           * accompanied this code).
>           *
>           * You should have received a copy of the GNU General Public
>         License
>         version
>           * 2 along with this work; if not, write to the Free Software
>         Foundation,
>           * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>           *
>           * Please contact Oracle, 500 Oracle Parkway, Redwood Shores,
>         CA 94065 USA
>           * or visit www.oracle.com <http://www.oracle.com> if you need
>         additional information or have any
>           * questions.
>           */
>
>         /*
>           * Portions Copyright (c) 2012 IBM Corporation
>           */
>
>         import javax.swing.*;
>
>         /* @test 1.1 2012/03/15
>             @bug 7154030
>             @run main/manual ComponentHideShowTest.html */
>
>         @SuppressWarnings("serial")
>         public class ComponetHideShowTest extends JFrame {
>              JInternalFrame internalFrame;
>              JButton btn;
>              JDesktopPane desktop;
>
>              ComponetHideShowTest(String name) {
>                  super(name);
>                  desktop = new JDesktopPane();
>                  setContentPane(desktop);
>
>                  setSize(600, 400);
>                  setVisible(true);
>
>                  internalFrame = new JInternalFrame("Test Internal Frame");
>                  internalFrame.setSize(100, 100);
>                  internalFrame.setLocation(10, 10);
>                  internalFrame.setVisible(true)__;
>                  desktop.add(internalFrame);
>
>                  btn = new JButton("OK");
>                  btn.setSize(100, 50);
>                  btn.setLocation( 300, 300);
>                  btn.setVisible(true);
>                  desktop.add(btn);
>
>                  setDefaultCloseOperation(__JFrame.EXIT_ON_CLOSE);
>              }
>
>              @SuppressWarnings("__deprecation")
>              public void runTest() throws Exception {
>                  Object[] options = { "Yes, I saw it", "No, I did not
>         see it!" };
>
>                  int ret = JOptionPane.showOptionDialog(__this,
>         "Do you see the internal window?", "InternalFrmaeHideTest",
>                          JOptionPane.YES_NO_OPTION,
>         JOptionPane.QUESTION_MESSAGE, null,
>                          options, options[1]);
>
>                  if (ret == 1 || ret == JOptionPane.CLOSED_OPTION) {
>                      throw new Exception("Failed to display internal
>         window");
>                  }
>
>                  internalFrame.hide();
>                  btn.hide();
>
>                  ret = JOptionPane.showOptionDialog(__this,
>         "Do you see the internal window?", "InternalFrmaeHideTest",
>                          JOptionPane.YES_NO_OPTION,
>         JOptionPane.QUESTION_MESSAGE, null,
>                          options, options[1]);
>
>                  if (ret == 0 || ret == JOptionPane.CLOSED_OPTION) {
>                      throw new Exception("Failed to hide internal window");
>                  }
>
>                  internalFrame.show();
>                  btn.show();
>
>                  ret = JOptionPane.showOptionDialog(__this,
>         "Do you see the internal window?", "InternalFrmaeHideTest",
>                          JOptionPane.YES_NO_OPTION,
>         JOptionPane.QUESTION_MESSAGE, null,
>                          options, options[1]);
>
>                  if (ret == 1 || ret == JOptionPane.CLOSED_OPTION) {
>                      throw new Exception("Failed to hide internal window");
>                  }
>              }
>
>              public static void main(String[] args) throws Exception {
>                  ComponetHideShowTest test = null;
>                  test = new ComponetHideShowTest("__InternalFrameHideTest");
>                  test.runTest();
>              }
>         }
>
>         And here's the patch
>         http://cr.openjdk.java.net/~__littlee/7154030/
>         <http://cr.openjdk.java.net/%7Elittlee/7154030/>
>
>         Can anybody please help to take a look?
>
>         Cheers!
>         - Jonathan
>
>
> Best regards!
> - Jonathan

From chuanshenglu at gmail.com  Tue Mar 20 02:47:10 2012
From: chuanshenglu at gmail.com (Jonathan Lu)
Date: Tue, 20 Mar 2012 17:47:10 +0800
Subject: <Swing Dev> <AWT Dev> Review request for 7154030:
 java.awt.Component.hide() does not repaint parent container
In-Reply-To: <4F6845B3.1060506@oracle.com>
References: <CAC-GWLe8d6mR+tyoEKOuSb4A8Caun-9_NcTePV7+i0McJjsO+w@mail.gmail.com>
	<4F67511F.5040109@oracle.com>
	<CAC-GWLenUzrra+P3_U3mQuho34Oj3OXRE+ievM44WarNYS4G7w@mail.gmail.com>
	<4F6845B3.1060506@oracle.com>
Message-ID: <CAC-GWLcmkA_tbydcKLfvor_nGTAOiS1xboC0Ua3wiXou=d7vOw@mail.gmail.com>

Hi Artem,

2012/3/20 Artem Ananiev <artem.ananiev at oracle.com>

> Hi, Jonathan,
>
> I'm adding swing-dev to CC as we now consider changing Swing code.
>
> What you propose sounds technically reasonable, but I don't think it is
> worth doing anyway as show() and hide() have been deprecated for years now.
>

Although show() and hide() have been deprecated for years, in my opinion
supporting these APIs will still benefit many applications and convince
users that Java still has got strong backward compatibility :D. Any ideas
from Swing group?


>
> Even if we accept the change in JComponent.hide(), we should then override
> show() as well (lightweight component may be non-opaque, so we should
> repaint from its parent), so there will be code duplication. This is one
> more reason to leave all as is.
>
>
Yes, I noticed that code duplication too and am trying to make a more
compact patch for this problem.


> This is my personal opinion, I'm not a Swing expert, though. Let anyone
> from the Swing group comment.
>

Thanks,
>
> Artem
>
> On 3/20/2012 12:28 PM, Jonathan Lu wrote:
>
>> Hi Artem,
>>
>> Thanks for your time.
>>
>> 2012/3/19 Artem Ananiev <artem.ananiev at oracle.com
>> <mailto:artem.ananiev at oracle.**com <artem.ananiev at oracle.com>>>
>>
>>    Hi, Jonathan,
>>
>>    given the code in java.awt.Component, your statement about
>>    difference between hide() and setVisible(false) looks pretty strange
>>    to me. Indeed, here is the implementation:
>>
>>
>>
>>        public void show(boolean b) {
>>            if (b) {
>>                show();
>>            } else {
>>                hide();
>>            }
>>        }
>>
>>    and
>>
>>        public void setVisible(boolean b) {
>>            show(b);
>>        }
>>
>>    In JComponent the latter method is overridden and adds exactly what
>>    you propose: parent.repaint(). This addition makes sense for
>>    lightweight components (e.g. Swing), but heavyweight AWT components
>>    shouldn't require this: repaint request is sent from the native system.
>>
>>
>> Yes, lightweight and  heavyweight components differ in painting. The
>> original test case only works for the conditions of lightweight
>> components, with another test case for heavyweight components, I found
>> that the problem could not be reproduced on AWT any more. I think the
>> change is only applicable for Swing components, so how about repaint in
>> JComponent.hide() like this?
>>
>> diff -r cdbb33303ea3 src/share/classes/javax/swing/**JComponent.java
>> --- a/src/share/classes/javax/**swing/JComponent.java    Wed Mar 14
>> 13:50:37 2012 -0700 <tel:2012%20-0700>
>> +++ b/src/share/classes/javax/**swing/JComponent.java    Tue Mar 20
>> 16:24:09 2012 +0800
>> @@ -5237,6 +5237,16 @@
>>          }
>>      }
>>
>> +    public void hide() {
>> +        super.hide();
>> +        Container parent = getParent();
>> +        if (parent != null) {
>> +            Rectangle r = getBounds();
>> +            parent.repaint(r.x, r.y, r.width, r.height);
>> +            parent.invalidate();
>> +        }
>> +    }
>> +
>>      /**
>>       * Returns whether or not the region of the specified component is
>>       * obscured by a sibling.
>>
>>
>>
>>    Thanks,
>>
>>    Artem
>>
>>
>>    On 3/15/2012 12:24 PM, Jonathan Lu wrote:
>>
>>        Hi awt-dev,
>>
>>        java.awt.Component.hide() was declared as deprecation and
>>        replaced by
>>        setVisible(boolean), but in my tests, it does not works in the
>>        same way
>>        as setVisible(false). The reason of this failure is that
>>        java.awt.Component.hide() does not repaint the special area it
>>        used to
>>        taken of parent container. Although this is deprecated method,
>>        it may
>>        still valuable for customers due to compatibility reason. Bug
>>        7154030
>>        created for this issue.
>>
>>        Here's a simple test case to demonstrate this problem.
>>
>>        /*
>>          * Copyright (c) 2012 Oracle and/or its affiliates. All rights
>>        reserved.
>>          * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>          *
>>          * This code is free software; you can redistribute it and/or
>>        modify it
>>          * under the terms of the GNU General Public License version 2
>>        only, as
>>          * published by the Free Software Foundation.
>>          *
>>          * This code is distributed in the hope that it will be useful,
>> but
>>        WITHOUT
>>          * ANY WARRANTY; without even the implied warranty of
>>        MERCHANTABILITY or
>>          * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General
>>        Public License
>>          * version 2 for more details (a copy is included in the
>>        LICENSE file that
>>          * accompanied this code).
>>          *
>>          * You should have received a copy of the GNU General Public
>>        License
>>        version
>>          * 2 along with this work; if not, write to the Free Software
>>        Foundation,
>>          * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>>          *
>>          * Please contact Oracle, 500 Oracle Parkway, Redwood Shores,
>>        CA 94065 USA
>>          * or visit www.oracle.com <http://www.oracle.com> if you need
>>        additional information or have any
>>          * questions.
>>          */
>>
>>        /*
>>          * Portions Copyright (c) 2012 IBM Corporation
>>          */
>>
>>        import javax.swing.*;
>>
>>        /* @test 1.1 2012/03/15
>>            @bug 7154030
>>            @run main/manual ComponentHideShowTest.html */
>>
>>        @SuppressWarnings("serial")
>>        public class ComponetHideShowTest extends JFrame {
>>             JInternalFrame internalFrame;
>>             JButton btn;
>>             JDesktopPane desktop;
>>
>>             ComponetHideShowTest(String name) {
>>                 super(name);
>>                 desktop = new JDesktopPane();
>>                 setContentPane(desktop);
>>
>>                 setSize(600, 400);
>>                 setVisible(true);
>>
>>                 internalFrame = new JInternalFrame("Test Internal Frame");
>>                 internalFrame.setSize(100, 100);
>>                 internalFrame.setLocation(10, 10);
>>                 internalFrame.setVisible(true)**__;
>>                 desktop.add(internalFrame);
>>
>>                 btn = new JButton("OK");
>>                 btn.setSize(100, 50);
>>                 btn.setLocation( 300, 300);
>>                 btn.setVisible(true);
>>                 desktop.add(btn);
>>
>>                 setDefaultCloseOperation(__**JFrame.EXIT_ON_CLOSE);
>>             }
>>
>>             @SuppressWarnings("__**deprecation")
>>             public void runTest() throws Exception {
>>                 Object[] options = { "Yes, I saw it", "No, I did not
>>        see it!" };
>>
>>                 int ret = JOptionPane.showOptionDialog(_**_this,
>>        "Do you see the internal window?", "InternalFrmaeHideTest",
>>                         JOptionPane.YES_NO_OPTION,
>>        JOptionPane.QUESTION_MESSAGE, null,
>>                         options, options[1]);
>>
>>                 if (ret == 1 || ret == JOptionPane.CLOSED_OPTION) {
>>                     throw new Exception("Failed to display internal
>>        window");
>>                 }
>>
>>                 internalFrame.hide();
>>                 btn.hide();
>>
>>                 ret = JOptionPane.showOptionDialog(_**_this,
>>        "Do you see the internal window?", "InternalFrmaeHideTest",
>>                         JOptionPane.YES_NO_OPTION,
>>        JOptionPane.QUESTION_MESSAGE, null,
>>                         options, options[1]);
>>
>>                 if (ret == 0 || ret == JOptionPane.CLOSED_OPTION) {
>>                     throw new Exception("Failed to hide internal window");
>>                 }
>>
>>                 internalFrame.show();
>>                 btn.show();
>>
>>                 ret = JOptionPane.showOptionDialog(_**_this,
>>        "Do you see the internal window?", "InternalFrmaeHideTest",
>>                         JOptionPane.YES_NO_OPTION,
>>        JOptionPane.QUESTION_MESSAGE, null,
>>                         options, options[1]);
>>
>>                 if (ret == 1 || ret == JOptionPane.CLOSED_OPTION) {
>>                     throw new Exception("Failed to hide internal window");
>>                 }
>>             }
>>
>>             public static void main(String[] args) throws Exception {
>>                 ComponetHideShowTest test = null;
>>                 test = new ComponetHideShowTest("__**
>> InternalFrameHideTest");
>>                 test.runTest();
>>             }
>>        }
>>
>>        And here's the patch
>>        http://cr.openjdk.java.net/~__**littlee/7154030/<http://cr.openjdk.java.net/%7E__littlee/7154030/>
>>        <http://cr.openjdk.java.net/%**7Elittlee/7154030/<http://cr.openjdk.java.net/%7Elittlee/7154030/>
>> >
>>
>>        Can anybody please help to take a look?
>>
>>        Cheers!
>>        - Jonathan
>>
>>
>> Best regards!
>> - Jonathan
>>
>
Thanks a lot !

- Jonathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120320/4a3bcfe9/attachment-0001.html 

From pavel.porvatov at oracle.com  Tue Mar 20 07:03:26 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Tue, 20 Mar 2012 18:03:26 +0400
Subject: <Swing Dev> <AWT Dev> Review request for 7154030:
 java.awt.Component.hide() does not repaint parent container
In-Reply-To: <CAC-GWLcmkA_tbydcKLfvor_nGTAOiS1xboC0Ua3wiXou=d7vOw@mail.gmail.com>
References: <CAC-GWLe8d6mR+tyoEKOuSb4A8Caun-9_NcTePV7+i0McJjsO+w@mail.gmail.com>
	<4F67511F.5040109@oracle.com>
	<CAC-GWLenUzrra+P3_U3mQuho34Oj3OXRE+ievM44WarNYS4G7w@mail.gmail.com>
	<4F6845B3.1060506@oracle.com>
	<CAC-GWLcmkA_tbydcKLfvor_nGTAOiS1xboC0Ua3wiXou=d7vOw@mail.gmail.com>
Message-ID: <4F688E2E.9080508@oracle.com>

Hi Jonathan,
> Hi Artem,
>
> 2012/3/20 Artem Ananiev <artem.ananiev at oracle.com 
> <mailto:artem.ananiev at oracle.com>>
>
>     Hi, Jonathan,
>
>     I'm adding swing-dev to CC as we now consider changing Swing code.
>
>     What you propose sounds technically reasonable, but I don't think
>     it is worth doing anyway as show() and hide() have been deprecated
>     for years now.
>
>
> Although show() and hide() have been deprecated for years, in my 
> opinion supporting these APIs will still benefit many applications and 
> convince users that Java still has got strong backward compatibility 
> :D. Any ideas from Swing group?
I don't see why the words "backward compatibility" are here. There is a 
bug in deprecated methods "show" and "hide" (I've checked that jdk5 has 
the same problem), and that's one additional reason to use setVisible(). 
I agree with Artem that fixing deprecated API is not a high priority 
task (but we should keep backward compatibility, of course). I also 
think, that "to leave all as is" is a good decision for the described 
problem

Regards, Pavel
>
>
>     Even if we accept the change in JComponent.hide(), we should then
>     override show() as well (lightweight component may be non-opaque,
>     so we should repaint from its parent), so there will be code
>     duplication. This is one more reason to leave all as is.
>
>
> Yes, I noticed that code duplication too and am trying to make a more 
> compact patch for this problem.
>
>     This is my personal opinion, I'm not a Swing expert, though. Let
>     anyone from the Swing group comment.
>
>     Thanks,
>
>     Artem
>
>     On 3/20/2012 12:28 PM, Jonathan Lu wrote:
>
>         Hi Artem,
>
>         Thanks for your time.
>
>         2012/3/19 Artem Ananiev <artem.ananiev at oracle.com
>         <mailto:artem.ananiev at oracle.com>
>         <mailto:artem.ananiev at oracle.com
>         <mailto:artem.ananiev at oracle.com>>>
>
>            Hi, Jonathan,
>
>            given the code in java.awt.Component, your statement about
>            difference between hide() and setVisible(false) looks
>         pretty strange
>            to me. Indeed, here is the implementation:
>
>
>
>                public void show(boolean b) {
>                    if (b) {
>                        show();
>                    } else {
>                        hide();
>                    }
>                }
>
>            and
>
>                public void setVisible(boolean b) {
>                    show(b);
>                }
>
>            In JComponent the latter method is overridden and adds
>         exactly what
>            you propose: parent.repaint(). This addition makes sense for
>            lightweight components (e.g. Swing), but heavyweight AWT
>         components
>            shouldn't require this: repaint request is sent from the
>         native system.
>
>
>         Yes, lightweight and  heavyweight components differ in
>         painting. The
>         original test case only works for the conditions of lightweight
>         components, with another test case for heavyweight components,
>         I found
>         that the problem could not be reproduced on AWT any more. I
>         think the
>         change is only applicable for Swing components, so how about
>         repaint in
>         JComponent.hide() like this?
>
>         diff -r cdbb33303ea3 src/share/classes/javax/swing/JComponent.java
>         --- a/src/share/classes/javax/swing/JComponent.java    Wed Mar 14
>         13:50:37 2012 -0700 <tel:2012%20-0700> <tel:2012%20-0700>
>         +++ b/src/share/classes/javax/swing/JComponent.java    Tue Mar 20
>         16:24:09 2012 +0800
>         @@ -5237,6 +5237,16 @@
>                  }
>              }
>
>         +    public void hide() {
>         +        super.hide();
>         +        Container parent = getParent();
>         +        if (parent != null) {
>         +            Rectangle r = getBounds();
>         +            parent.repaint(r.x, r.y, r.width, r.height);
>         +            parent.invalidate();
>         +        }
>         +    }
>         +
>              /**
>               * Returns whether or not the region of the specified
>         component is
>               * obscured by a sibling.
>
>
>
>            Thanks,
>
>            Artem
>
>
>            On 3/15/2012 12:24 PM, Jonathan Lu wrote:
>
>                Hi awt-dev,
>
>                java.awt.Component.hide() was declared as deprecation and
>                replaced by
>                setVisible(boolean), but in my tests, it does not works
>         in the
>                same way
>                as setVisible(false). The reason of this failure is that
>                java.awt.Component.hide() does not repaint the special
>         area it
>                used to
>                taken of parent container. Although this is deprecated
>         method,
>                it may
>                still valuable for customers due to compatibility
>         reason. Bug
>                7154030
>                created for this issue.
>
>                Here's a simple test case to demonstrate this problem.
>
>                /*
>                  * Copyright (c) 2012 Oracle and/or its affiliates.
>         All rights
>                reserved.
>                  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS
>         FILE HEADER.
>                  *
>                  * This code is free software; you can redistribute it
>         and/or
>                modify it
>                  * under the terms of the GNU General Public License
>         version 2
>                only, as
>                  * published by the Free Software Foundation.
>                  *
>                  * This code is distributed in the hope that it will
>         be useful, but
>                WITHOUT
>                  * ANY WARRANTY; without even the implied warranty of
>                MERCHANTABILITY or
>                  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General
>                Public License
>                  * version 2 for more details (a copy is included in the
>                LICENSE file that
>                  * accompanied this code).
>                  *
>                  * You should have received a copy of the GNU General
>         Public
>                License
>                version
>                  * 2 along with this work; if not, write to the Free
>         Software
>                Foundation,
>                  * Inc., 51 Franklin St, Fifth Floor, Boston, MA
>         02110-1301 USA.
>                  *
>                  * Please contact Oracle, 500 Oracle Parkway, Redwood
>         Shores,
>                CA 94065 USA
>                  * or visit www.oracle.com <http://www.oracle.com>
>         <http://www.oracle.com> if you need
>                additional information or have any
>                  * questions.
>                  */
>
>                /*
>                  * Portions Copyright (c) 2012 IBM Corporation
>                  */
>
>                import javax.swing.*;
>
>                /* @test 1.1 2012/03/15
>                    @bug 7154030
>                    @run main/manual ComponentHideShowTest.html */
>
>                @SuppressWarnings("serial")
>                public class ComponetHideShowTest extends JFrame {
>                     JInternalFrame internalFrame;
>                     JButton btn;
>                     JDesktopPane desktop;
>
>                     ComponetHideShowTest(String name) {
>                         super(name);
>                         desktop = new JDesktopPane();
>                         setContentPane(desktop);
>
>                         setSize(600, 400);
>                         setVisible(true);
>
>                         internalFrame = new JInternalFrame("Test
>         Internal Frame");
>                         internalFrame.setSize(100, 100);
>                         internalFrame.setLocation(10, 10);
>                         internalFrame.setVisible(true)__;
>                         desktop.add(internalFrame);
>
>                         btn = new JButton("OK");
>                         btn.setSize(100, 50);
>                         btn.setLocation( 300, 300);
>                         btn.setVisible(true);
>                         desktop.add(btn);
>
>                         setDefaultCloseOperation(__JFrame.EXIT_ON_CLOSE);
>                     }
>
>                     @SuppressWarnings("__deprecation")
>                     public void runTest() throws Exception {
>                         Object[] options = { "Yes, I saw it", "No, I
>         did not
>                see it!" };
>
>                         int ret = JOptionPane.showOptionDialog(__this,
>                "Do you see the internal window?", "InternalFrmaeHideTest",
>                                 JOptionPane.YES_NO_OPTION,
>                JOptionPane.QUESTION_MESSAGE, null,
>                                 options, options[1]);
>
>                         if (ret == 1 || ret ==
>         JOptionPane.CLOSED_OPTION) {
>                             throw new Exception("Failed to display
>         internal
>                window");
>                         }
>
>                         internalFrame.hide();
>                         btn.hide();
>
>                         ret = JOptionPane.showOptionDialog(__this,
>                "Do you see the internal window?", "InternalFrmaeHideTest",
>                                 JOptionPane.YES_NO_OPTION,
>                JOptionPane.QUESTION_MESSAGE, null,
>                                 options, options[1]);
>
>                         if (ret == 0 || ret ==
>         JOptionPane.CLOSED_OPTION) {
>                             throw new Exception("Failed to hide
>         internal window");
>                         }
>
>                         internalFrame.show();
>                         btn.show();
>
>                         ret = JOptionPane.showOptionDialog(__this,
>                "Do you see the internal window?", "InternalFrmaeHideTest",
>                                 JOptionPane.YES_NO_OPTION,
>                JOptionPane.QUESTION_MESSAGE, null,
>                                 options, options[1]);
>
>                         if (ret == 1 || ret ==
>         JOptionPane.CLOSED_OPTION) {
>                             throw new Exception("Failed to hide
>         internal window");
>                         }
>                     }
>
>                     public static void main(String[] args) throws
>         Exception {
>                         ComponetHideShowTest test = null;
>                         test = new
>         ComponetHideShowTest("__InternalFrameHideTest");
>                         test.runTest();
>                     }
>                }
>
>                And here's the patch
>         http://cr.openjdk.java.net/~__littlee/7154030/
>         <http://cr.openjdk.java.net/%7E__littlee/7154030/>
>         <http://cr.openjdk.java.net/%7Elittlee/7154030/>
>
>                Can anybody please help to take a look?
>
>                Cheers!
>                - Jonathan
>
>
>         Best regards!
>         - Jonathan
>
>
> Thanks a lot !
>
> - Jonathan

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

From littlee at linux.vnet.ibm.com  Wed Mar 21 02:42:40 2012
From: littlee at linux.vnet.ibm.com (Charles Lee)
Date: Wed, 21 Mar 2012 17:42:40 +0800
Subject: <Swing Dev> Fixes for sunbug 7026933 and 4310381
Message-ID: <4F69A290.7030907@linux.vnet.ibm.com>

Hi guys,

I am trying to fix 7026933 and 4310381.

Patch @ http://cr.openjdk.java.net/~littlee/7026933/webrev.00/ 
<http://cr.openjdk.java.net/%7Elittlee/7026933/webrev.00/>

The test case is @ 4310381 and 7026933.

My patch fix the padding problem on all the tabs except the top tab. The 
reason about this is Metal look and feel does not want to pad the last 
one. Please check the code in MetalTabbedPaneUI:

// Don't pad last run
protected boolean shouldPadTabRun( int tabPlacement, int run ) {
     return runCount > 1 && run < runCount - 1;
}

Does anyone has some knowledge about this? If metal does not want pad 
that tab, my patch should be consider fixing the problem :-)

-- 
Yours Charles


From pavel.porvatov at oracle.com  Wed Mar 21 06:15:23 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Wed, 21 Mar 2012 17:15:23 +0400
Subject: <Swing Dev> Fixes for sunbug 7026933 and 4310381
In-Reply-To: <4F69A290.7030907@linux.vnet.ibm.com>
References: <4F69A290.7030907@linux.vnet.ibm.com>
Message-ID: <4F69D46B.2090302@oracle.com>

Hi Charles,
> Hi guys,
>
> I am trying to fix 7026933 and 4310381.
>
> Patch @ http://cr.openjdk.java.net/~littlee/7026933/webrev.00/ 
> <http://cr.openjdk.java.net/%7Elittlee/7026933/webrev.00/>
>
> The test case is @ 4310381 and 7026933.
>
> My patch fix the padding problem on all the tabs except the top tab. 
> The reason about this is Metal look and feel does not want to pad the 
> last one. Please check the code in MetalTabbedPaneUI:
>
> // Don't pad last run
> protected boolean shouldPadTabRun( int tabPlacement, int run ) {
>     return runCount > 1 && run < runCount - 1;
> }
>
> Does anyone has some knowledge about this? If metal does not want pad 
> that tab, my patch should be consider fixing the problem :-)
>
That strange line was introduced with fix of CR 4253906 (since 1999). 
Looks strange indeed...

The fix looks good for me. What about a test? I'm not sure automatic 
test is possible here, so you can write manual test...

Regards, Pavel

From luchsh at linux.vnet.ibm.com  Wed Mar 21 22:27:30 2012
From: luchsh at linux.vnet.ibm.com (Jonathan Lu)
Date: Thu, 22 Mar 2012 13:27:30 +0800
Subject: <Swing Dev> <AWT Dev> Review request for 7154030:
 java.awt.Component.hide() does not repaint parent container
In-Reply-To: <4F688E2E.9080508@oracle.com>
References: <CAC-GWLe8d6mR+tyoEKOuSb4A8Caun-9_NcTePV7+i0McJjsO+w@mail.gmail.com>
	<4F67511F.5040109@oracle.com>
	<CAC-GWLenUzrra+P3_U3mQuho34Oj3OXRE+ievM44WarNYS4G7w@mail.gmail.com>
	<4F6845B3.1060506@oracle.com>
	<CAC-GWLcmkA_tbydcKLfvor_nGTAOiS1xboC0Ua3wiXou=d7vOw@mail.gmail.com>
	<4F688E2E.9080508@oracle.com>
Message-ID: <CAC-GWLcHxYxnOJPmmv0j2GOtahHwJJqntK43367R5YJi8xZJNA@mail.gmail.com>

Hi Pavel,

Thanks for your explanation.

But this bug affects almost all Swing components, hide()'s presence also
helps to maintain backward compatibility, so is it possible to put a fix in
JComponent to help all the potential affected applications to work
correctly? if not, is it there any sunset plan for these deprecated APIs?

Thanks and best regards!

- Jonathan

2012/3/20 Pavel Porvatov <pavel.porvatov at oracle.com>

>  Hi Jonathan,
>
> Hi Artem,
>
> 2012/3/20 Artem Ananiev <artem.ananiev at oracle.com>
>
>> Hi, Jonathan,
>>
>> I'm adding swing-dev to CC as we now consider changing Swing code.
>>
>> What you propose sounds technically reasonable, but I don't think it is
>> worth doing anyway as show() and hide() have been deprecated for years now.
>>
>
> Although show() and hide() have been deprecated for years, in my opinion
> supporting these APIs will still benefit many applications and convince
> users that Java still has got strong backward compatibility :D. Any ideas
> from Swing group?
>
> I don't see why the words "backward compatibility" are here. There is a
> bug in deprecated methods "show" and "hide" (I've checked that jdk5 has the
> same problem), and that's one additional reason to use setVisible(). I
> agree with Artem that fixing deprecated API is not a high priority task
> (but we should keep backward compatibility, of course). I also think, that
> "to leave all as is" is a good decision for the described problem
>
> Regards, Pavel
>
>
>
>>
>> Even if we accept the change in JComponent.hide(), we should then
>> override show() as well (lightweight component may be non-opaque, so we
>> should repaint from its parent), so there will be code duplication. This is
>> one more reason to leave all as is.
>>
>>
> Yes, I noticed that code duplication too and am trying to make a more
> compact patch for this problem.
>
>
>> This is my personal opinion, I'm not a Swing expert, though. Let anyone
>> from the Swing group comment.
>>
>
>  Thanks,
>>
>> Artem
>>
>> On 3/20/2012 12:28 PM, Jonathan Lu wrote:
>>
>>> Hi Artem,
>>>
>>> Thanks for your time.
>>>
>>> 2012/3/19 Artem Ananiev <artem.ananiev at oracle.com
>>> <mailto:artem.ananiev at oracle.com>>
>>>
>>>    Hi, Jonathan,
>>>
>>>    given the code in java.awt.Component, your statement about
>>>    difference between hide() and setVisible(false) looks pretty strange
>>>    to me. Indeed, here is the implementation:
>>>
>>>
>>>
>>>        public void show(boolean b) {
>>>            if (b) {
>>>                show();
>>>            } else {
>>>                hide();
>>>            }
>>>        }
>>>
>>>    and
>>>
>>>        public void setVisible(boolean b) {
>>>            show(b);
>>>        }
>>>
>>>    In JComponent the latter method is overridden and adds exactly what
>>>    you propose: parent.repaint(). This addition makes sense for
>>>    lightweight components (e.g. Swing), but heavyweight AWT components
>>>    shouldn't require this: repaint request is sent from the native
>>> system.
>>>
>>>
>>> Yes, lightweight and  heavyweight components differ in painting. The
>>> original test case only works for the conditions of lightweight
>>> components, with another test case for heavyweight components, I found
>>> that the problem could not be reproduced on AWT any more. I think the
>>> change is only applicable for Swing components, so how about repaint in
>>> JComponent.hide() like this?
>>>
>>> diff -r cdbb33303ea3 src/share/classes/javax/swing/JComponent.java
>>> --- a/src/share/classes/javax/swing/JComponent.java    Wed Mar 14
>>> 13:50:37 2012 -0700 <tel:2012%20-0700>
>>> +++ b/src/share/classes/javax/swing/JComponent.java    Tue Mar 20
>>> 16:24:09 2012 +0800
>>> @@ -5237,6 +5237,16 @@
>>>          }
>>>      }
>>>
>>> +    public void hide() {
>>> +        super.hide();
>>> +        Container parent = getParent();
>>> +        if (parent != null) {
>>> +            Rectangle r = getBounds();
>>> +            parent.repaint(r.x, r.y, r.width, r.height);
>>> +            parent.invalidate();
>>> +        }
>>> +    }
>>> +
>>>      /**
>>>       * Returns whether or not the region of the specified component is
>>>       * obscured by a sibling.
>>>
>>>
>>>
>>>    Thanks,
>>>
>>>    Artem
>>>
>>>
>>>    On 3/15/2012 12:24 PM, Jonathan Lu wrote:
>>>
>>>        Hi awt-dev,
>>>
>>>        java.awt.Component.hide() was declared as deprecation and
>>>        replaced by
>>>        setVisible(boolean), but in my tests, it does not works in the
>>>        same way
>>>        as setVisible(false). The reason of this failure is that
>>>        java.awt.Component.hide() does not repaint the special area it
>>>        used to
>>>        taken of parent container. Although this is deprecated method,
>>>        it may
>>>        still valuable for customers due to compatibility reason. Bug
>>>        7154030
>>>        created for this issue.
>>>
>>>        Here's a simple test case to demonstrate this problem.
>>>
>>>        /*
>>>          * Copyright (c) 2012 Oracle and/or its affiliates. All rights
>>>        reserved.
>>>          * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>          *
>>>          * This code is free software; you can redistribute it and/or
>>>        modify it
>>>          * under the terms of the GNU General Public License version 2
>>>        only, as
>>>          * published by the Free Software Foundation.
>>>          *
>>>          * This code is distributed in the hope that it will be useful,
>>> but
>>>        WITHOUT
>>>          * ANY WARRANTY; without even the implied warranty of
>>>        MERCHANTABILITY or
>>>          * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General
>>>        Public License
>>>          * version 2 for more details (a copy is included in the
>>>        LICENSE file that
>>>          * accompanied this code).
>>>          *
>>>          * You should have received a copy of the GNU General Public
>>>        License
>>>        version
>>>          * 2 along with this work; if not, write to the Free Software
>>>        Foundation,
>>>          * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>>>          *
>>>          * Please contact Oracle, 500 Oracle Parkway, Redwood Shores,
>>>        CA 94065 USA
>>>          * or visit www.oracle.com <http://www.oracle.com> if you need
>>>        additional information or have any
>>>          * questions.
>>>          */
>>>
>>>        /*
>>>          * Portions Copyright (c) 2012 IBM Corporation
>>>          */
>>>
>>>        import javax.swing.*;
>>>
>>>        /* @test 1.1 2012/03/15
>>>            @bug 7154030
>>>            @run main/manual ComponentHideShowTest.html */
>>>
>>>        @SuppressWarnings("serial")
>>>        public class ComponetHideShowTest extends JFrame {
>>>             JInternalFrame internalFrame;
>>>             JButton btn;
>>>             JDesktopPane desktop;
>>>
>>>             ComponetHideShowTest(String name) {
>>>                 super(name);
>>>                 desktop = new JDesktopPane();
>>>                 setContentPane(desktop);
>>>
>>>                 setSize(600, 400);
>>>                 setVisible(true);
>>>
>>>                 internalFrame = new JInternalFrame("Test Internal
>>> Frame");
>>>                 internalFrame.setSize(100, 100);
>>>                 internalFrame.setLocation(10, 10);
>>>                 internalFrame.setVisible(true)__;
>>>                 desktop.add(internalFrame);
>>>
>>>                 btn = new JButton("OK");
>>>                 btn.setSize(100, 50);
>>>                 btn.setLocation( 300, 300);
>>>                 btn.setVisible(true);
>>>                 desktop.add(btn);
>>>
>>>                 setDefaultCloseOperation(__JFrame.EXIT_ON_CLOSE);
>>>             }
>>>
>>>             @SuppressWarnings("__deprecation")
>>>             public void runTest() throws Exception {
>>>                 Object[] options = { "Yes, I saw it", "No, I did not
>>>        see it!" };
>>>
>>>                 int ret = JOptionPane.showOptionDialog(__this,
>>>        "Do you see the internal window?", "InternalFrmaeHideTest",
>>>                         JOptionPane.YES_NO_OPTION,
>>>        JOptionPane.QUESTION_MESSAGE, null,
>>>                         options, options[1]);
>>>
>>>                 if (ret == 1 || ret == JOptionPane.CLOSED_OPTION) {
>>>                     throw new Exception("Failed to display internal
>>>        window");
>>>                 }
>>>
>>>                 internalFrame.hide();
>>>                 btn.hide();
>>>
>>>                 ret = JOptionPane.showOptionDialog(__this,
>>>        "Do you see the internal window?", "InternalFrmaeHideTest",
>>>                         JOptionPane.YES_NO_OPTION,
>>>        JOptionPane.QUESTION_MESSAGE, null,
>>>                         options, options[1]);
>>>
>>>                 if (ret == 0 || ret == JOptionPane.CLOSED_OPTION) {
>>>                     throw new Exception("Failed to hide internal
>>> window");
>>>                 }
>>>
>>>                 internalFrame.show();
>>>                 btn.show();
>>>
>>>                 ret = JOptionPane.showOptionDialog(__this,
>>>        "Do you see the internal window?", "InternalFrmaeHideTest",
>>>                         JOptionPane.YES_NO_OPTION,
>>>        JOptionPane.QUESTION_MESSAGE, null,
>>>                         options, options[1]);
>>>
>>>                 if (ret == 1 || ret == JOptionPane.CLOSED_OPTION) {
>>>                     throw new Exception("Failed to hide internal
>>> window");
>>>                 }
>>>             }
>>>
>>>             public static void main(String[] args) throws Exception {
>>>                 ComponetHideShowTest test = null;
>>>                 test = new
>>> ComponetHideShowTest("__InternalFrameHideTest");
>>>                 test.runTest();
>>>             }
>>>        }
>>>
>>>        And here's the patch
>>>        http://cr.openjdk.java.net/~__littlee/7154030/
>>>        <http://cr.openjdk.java.net/%7Elittlee/7154030/>
>>>
>>>        Can anybody please help to take a look?
>>>
>>>        Cheers!
>>>        - Jonathan
>>>
>>>
>>> Best regards!
>>> - Jonathan
>>>
>>
> Thanks a lot !
>
> - Jonathan
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120322/c8579e08/attachment-0001.html 

From zhouyx at linux.vnet.ibm.com  Wed Mar 21 23:15:48 2012
From: zhouyx at linux.vnet.ibm.com (Sean Chou)
Date: Thu, 22 Mar 2012 14:15:48 +0800
Subject: <Swing Dev> <AWT Dev> Request for review: 7155298 : Editable
 TextArea blocks GUI application from exit
In-Reply-To: <CAK6==_kghcdGRRbUXT37xAZRehbBKUn+6oJM_=dMnNtrFJbJRQ@mail.gmail.com>
References: <CAOo=rxWoExdrCbp-iod4dyCG1kj47ZrMZgMJ4hPa1mbXbxVMUg@mail.gmail.com>
	<CAK6==_kghcdGRRbUXT37xAZRehbBKUn+6oJM_=dMnNtrFJbJRQ@mail.gmail.com>
Message-ID: <CAOo=rxUo1rjzp4apeLULv6PN-MGWthRFYqmtsqS7Nrn1M++Mvg@mail.gmail.com>

Hi Oleg,

    I replaced the TextArea with JTextArea in the test and the application
exits.
With some code added to DefaultCaret.java after invocation to flasher.stop
, I got
a stack trace as follow, which is not seen in test with TextArea.

java.lang.RuntimeException: my exception 2
at javax.swing.text.DefaultCaret.setVisible(DefaultCaret.java:985)
at javax.swing.text.DefaultCaret.focusLost(DefaultCaret.java:364)
at java.awt.AWTEventMulticaster.focusLost(AWTEventMulticaster.java:230)
at java.awt.Component.processFocusEvent(Component.java:6396)
at java.awt.Component.processEvent(Component.java:6260)
at java.awt.Container.processEvent(Container.java:2229)
at java.awt.Component.dispatchEventImpl(Component.java:4860)
at java.awt.Container.dispatchEventImpl(Container.java:2287)
at java.awt.Component.dispatchEvent(Component.java:4686)
at
java.awt.KeyboardFocusManager.redispatchEvent(KeyboardFocusManager.java:1908)
at
java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(DefaultKeyboardFocusManager.java:937)
at
java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManager.java:611)
at java.awt.Component.dispatchEventImpl(Component.java:4730)
at java.awt.Container.dispatchEventImpl(Container.java:2287)
at java.awt.Component.dispatchEvent(Component.java:4686)
at sun.awt.SunToolkit$4.run(SunToolkit.java:588)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:251)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:705)
at java.awt.EventQueue.access$000(EventQueue.java:101)
at java.awt.EventQueue$3.run(EventQueue.java:666)
at java.awt.EventQueue$3.run(EventQueue.java:664)
at java.security.AccessController.doPrivileged(Native Method)
at
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:675)
at
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:211)
at
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:128)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:117)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:113)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:105)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:90)


So, the difference is when disposing, if JTextArea is used, DefaultCaret
receives a focusLost event;
if TextArea is used, DefaultCaret does not receive that event.

I also instrumented forwardFocusLost and found it is not invoked when
disposing (this can be
seen from the above stack trace as well) .

But I can't answer the question whether
AWTTextArea/AWTTextField.removeNotify()
should stop the timer. Swing-dev is added to cc list.


On Wed, Mar 21, 2012 at 9:14 PM, Oleg Sukhodolsky <son.two at gmail.com> wrote:

> Hi Sean,
>
> as far as I understand the caret and the timer both come from Swing,
> thus I wonder why
> calling removeNotify() on JPasswotrdField/JTextArea doesn't stop the
> timer? What does Swing expect?
> It might be some bug in Swing (I hope it is not, but it is better to
> verify ;)
>
> As for changes I'd suggest to move this additional call (if we decide
> that this is the right way to fix the problem) into
> AWTTextArea/AWTTextField.removeNotify() this will help in case we
> decide to call it in some other place.
>
> Regards, Oleg.
>
> On Wed, Mar 21, 2012 at 11:55 AM, Sean Chou <zhouyx at linux.vnet.ibm.com>
> wrote:
> > Hi all,
> >
> >      It is found that when TextArea or TextField is setEditable(true),
> the
> > application will not exit after the application frame disposes.
> > The reason is the visible caret contains a timer which controls its
> flashing
> > . This timer must be stopped when disposing.
> >
> > Link to webrev: http://cr.openjdk.java.net/~zhouyx/7155298/webrev.00/
> > Link to bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7155298
> >
> > --
> > 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/20120322/267d4bc8/attachment.html 

From son.two at gmail.com  Wed Mar 21 23:42:47 2012
From: son.two at gmail.com (Oleg Sukhodolsky)
Date: Thu, 22 Mar 2012 10:42:47 +0400
Subject: <Swing Dev> <AWT Dev> Request for review: 7155298 : Editable
 TextArea blocks GUI application from exit
In-Reply-To: <CAOo=rxUo1rjzp4apeLULv6PN-MGWthRFYqmtsqS7Nrn1M++Mvg@mail.gmail.com>
References: <CAOo=rxWoExdrCbp-iod4dyCG1kj47ZrMZgMJ4hPa1mbXbxVMUg@mail.gmail.com>
	<CAK6==_kghcdGRRbUXT37xAZRehbBKUn+6oJM_=dMnNtrFJbJRQ@mail.gmail.com>
	<CAOo=rxUo1rjzp4apeLULv6PN-MGWthRFYqmtsqS7Nrn1M++Mvg@mail.gmail.com>
Message-ID: <CAK6==_m27G8CmniOACB3bnFZmnnDekE+dk16TR2G32jnZzOnyA@mail.gmail.com>

Hi Sean,

comments inlined.

On Thu, Mar 22, 2012 at 10:15 AM, Sean Chou <zhouyx at linux.vnet.ibm.com> wrote:
> Hi Oleg,
>
> ? ? I replaced the TextArea with JTextArea in the test and the application
> exits.
> With some code added to DefaultCaret.java after invocation to flasher.stop ,
> I got
> a stack trace as follow, which is not seen in test with TextArea.
>
> java.lang.RuntimeException: my exception 2
> at javax.swing.text.DefaultCaret.setVisible(DefaultCaret.java:985)
> at javax.swing.text.DefaultCaret.focusLost(DefaultCaret.java:364)
> at java.awt.AWTEventMulticaster.focusLost(AWTEventMulticaster.java:230)
> at java.awt.Component.processFocusEvent(Component.java:6396)
> at java.awt.Component.processEvent(Component.java:6260)
> at java.awt.Container.processEvent(Container.java:2229)
> at java.awt.Component.dispatchEventImpl(Component.java:4860)
> at java.awt.Container.dispatchEventImpl(Container.java:2287)
> at java.awt.Component.dispatchEvent(Component.java:4686)
> at
> java.awt.KeyboardFocusManager.redispatchEvent(KeyboardFocusManager.java:1908)
> at
> java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(DefaultKeyboardFocusManager.java:937)
> at
> java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManager.java:611)
> at java.awt.Component.dispatchEventImpl(Component.java:4730)
> at java.awt.Container.dispatchEventImpl(Container.java:2287)
> at java.awt.Component.dispatchEvent(Component.java:4686)
> at sun.awt.SunToolkit$4.run(SunToolkit.java:588)
> at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:251)
> at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:705)
> at java.awt.EventQueue.access$000(EventQueue.java:101)
> at java.awt.EventQueue$3.run(EventQueue.java:666)
> at java.awt.EventQueue$3.run(EventQueue.java:664)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
> at java.awt.EventQueue.dispatchEvent(EventQueue.java:675)
> at
> java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:211)
> at
> java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:128)
> at
> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:117)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:113)
> at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:105)
> at java.awt.EventDispatchThread.run(EventDispatchThread.java:90)
>
>
> So, the difference is when disposing, if JTextArea is used, DefaultCaret
> receives a focusLost event;
> if TextArea is used,?DefaultCaret?does not receive that event.

Does DefaultCaret receives focusGained for TextArea?
If yes, perhaps we should investigate why it doesn't receive focusLost
and fix this (who knows what other
problems could be introduced by invisible focused JTextArea)

> I also instrumented?forwardFocusLost and found it is not invoked when
> disposing (this can be
> seen from the above stack trace as well) .
>
> But I can't answer the question whether
> AWTTextArea/AWTTextField.removeNotify()
> should stop the timer. Swing-dev is added to cc list.

AWTTextArea/AWTTextField are our own classes, so it is we who
responsible to decide
whether added some calls to thier methods or not.


Regards, Oleg.

>
> On Wed, Mar 21, 2012 at 9:14 PM, Oleg Sukhodolsky <son.two at gmail.com> wrote:
>>
>> Hi Sean,
>>
>> as far as I understand the caret and the timer both come from Swing,
>> thus I wonder why
>> calling removeNotify() on JPasswotrdField/JTextArea doesn't stop the
>> timer? What does Swing expect?
>> It might be some bug in Swing (I hope it is not, but it is better to
>> verify ;)
>>
>> As for changes I'd suggest to move this additional call (if we decide
>> that this is the right way to fix the problem) into
>> AWTTextArea/AWTTextField.removeNotify() this will help in case we
>> decide to call it in some other place.
>>
>> Regards, Oleg.
>>
>> On Wed, Mar 21, 2012 at 11:55 AM, Sean Chou <zhouyx at linux.vnet.ibm.com>
>> wrote:
>> > Hi all,
>> >
>> > ? ? ?It is found that when?TextArea or TextField is setEditable(true),
>> > the
>> > application will not exit after the application frame disposes.
>> > The reason is the visible caret contains a timer which controls its
>> > flashing
>> > . This timer must be stopped when disposing.
>> >
>> > Link to webrev:?http://cr.openjdk.java.net/~zhouyx/7155298/webrev.00/
>> > Link to bug:?http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7155298
>> >
>> > --
>> > Best Regards,
>> > Sean Chou
>> >
>
>
>
>
> --
> Best Regards,
> Sean Chou
>

From luchsh at linux.vnet.ibm.com  Thu Mar 22 00:05:12 2012
From: luchsh at linux.vnet.ibm.com (Jonathan Lu)
Date: Thu, 22 Mar 2012 15:05:12 +0800
Subject: <Swing Dev> Request for review 7155887: ComboBox does not paint
 focus correctly on GTK L&F
Message-ID: <4F6ACF28.5050102@linux.vnet.ibm.com>

Hi Swing-dev,

ComboBox on linux GTK L&F does not works as gtk native applications, 
when get focused, the apperance of Java ComboBox remains unchanged but 
native GTK ComboBox control will have a outline to indicate it has got 
focused.

The problem seems similar to bug
6947671 ( http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6947671),
except that I did not reproduced the problem on Nimbus L&F, so another bug
7155887 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7155887)
was created for this issue,

And here's the proposed patch to fix this problem,
http://cr.openjdk.java.net/~luchsh/7155887/

Could anybody please help to take a look?

Cheers!
- Jonathan


From pavel.porvatov at oracle.com  Thu Mar 22 07:24:40 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Thu, 22 Mar 2012 18:24:40 +0400
Subject: <Swing Dev> Request for review 7155887: ComboBox does not paint
 focus correctly on GTK L&F
In-Reply-To: <4F6ACF28.5050102@linux.vnet.ibm.com>
References: <4F6ACF28.5050102@linux.vnet.ibm.com>
Message-ID: <4F6B3628.50707@oracle.com>

Hi Jonathan,
> Hi Swing-dev,
>
> ComboBox on linux GTK L&F does not works as gtk native applications, 
> when get focused, the apperance of Java ComboBox remains unchanged but 
> native GTK ComboBox control will have a outline to indicate it has got 
> focused.
>
> The problem seems similar to bug
> 6947671 ( http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6947671),
> except that I did not reproduced the problem on Nimbus L&F, so another 
> bug
> 7155887 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7155887)
> was created for this issue,
>
> And here's the proposed patch to fix this problem,
> http://cr.openjdk.java.net/~luchsh/7155887/
>
> Could anybody please help to take a look?
I have several comments about the patch:

1. "c.getName().equals("ComboBox.renderer")": I think we can get NPE here

2.
+            for (Component comboBoxParent = c.getParent(); 
comboBoxParent != null; comboBoxParent = comboBoxParent
+                    .getParent()) {
+                if (comboBoxParent instanceof JComboBox
+ && comboBoxParent.hasFocus()) {
+                    comboBoxFocused = true;
+                }
+            }

I'm not sure we should do such deep parent investigation. Why don't you 
check first parent only?

3. "if (ENGINE.paintCachedImage(g, x, y, w, h, id, state) && 
!comboBoxFocused)"
If you are going to ignore ENGINE.paintCachedImage when comboBoxFocused, 
then there is no need to invoke it at all

4. "if (comboBoxFocused || focusSize > 0)"
I'm not sure we should paint focus if focusSize == 0

Regards, Pavel

From littlee at linux.vnet.ibm.com  Fri Mar 23 01:12:27 2012
From: littlee at linux.vnet.ibm.com (Charles Lee)
Date: Fri, 23 Mar 2012 16:12:27 +0800
Subject: <Swing Dev> Fixes for sunbug 7026933 and 4310381
In-Reply-To: <4F69D46B.2090302@oracle.com>
References: <4F69A290.7030907@linux.vnet.ibm.com> <4F69D46B.2090302@oracle.com>
Message-ID: <4F6C306B.9010404@linux.vnet.ibm.com>

On 03/21/2012 09:15 PM, Pavel Porvatov wrote:
> Hi Charles,
>> Hi guys,
>>
>> I am trying to fix 7026933 and 4310381.
>>
>> Patch @ http://cr.openjdk.java.net/~littlee/7026933/webrev.00/ 
>> <http://cr.openjdk.java.net/%7Elittlee/7026933/webrev.00/>
>>
>> The test case is @ 4310381 and 7026933.
>>
>> My patch fix the padding problem on all the tabs except the top tab. 
>> The reason about this is Metal look and feel does not want to pad the 
>> last one. Please check the code in MetalTabbedPaneUI:
>>
>> // Don't pad last run
>> protected boolean shouldPadTabRun( int tabPlacement, int run ) {
>>     return runCount > 1 && run < runCount - 1;
>> }
>>
>> Does anyone has some knowledge about this? If metal does not want pad 
>> that tab, my patch should be consider fixing the problem :-)
>>
> That strange line was introduced with fix of CR 4253906 (since 1999). 
> Looks strange indeed...
>
> The fix looks good for me. What about a test? I'm not sure automatic 
> test is possible here, so you can write manual test...
>
> Regards, Pavel
>
Hi Pavel,

Test case is attached. I am trying to make it in the webrev, but I am 
not quite understand "@run ****/manual=******". Should I use 
applet/manual? Should I provide a bug7026933.html?

PS:
CR 4253906 does not have enough info......

-- 
Yours Charles

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Test7026933.java
Type: text/x-java
Size: 2191 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120323/40ee5dec/Test7026933.java 

From pavel.porvatov at oracle.com  Fri Mar 23 06:23:24 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Fri, 23 Mar 2012 17:23:24 +0400
Subject: <Swing Dev> Fixes for sunbug 7026933 and 4310381
In-Reply-To: <4F6C306B.9010404@linux.vnet.ibm.com>
References: <4F69A290.7030907@linux.vnet.ibm.com> <4F69D46B.2090302@oracle.com>
	<4F6C306B.9010404@linux.vnet.ibm.com>
Message-ID: <4F6C794C.2010302@oracle.com>

Hi Charles,
> On 03/21/2012 09:15 PM, Pavel Porvatov wrote:
>> Hi Charles,
>>> Hi guys,
>>>
>>> I am trying to fix 7026933 and 4310381.
>>>
>>> Patch @ http://cr.openjdk.java.net/~littlee/7026933/webrev.00/ 
>>> <http://cr.openjdk.java.net/%7Elittlee/7026933/webrev.00/>
>>>
>>> The test case is @ 4310381 and 7026933.
>>>
>>> My patch fix the padding problem on all the tabs except the top tab. 
>>> The reason about this is Metal look and feel does not want to pad 
>>> the last one. Please check the code in MetalTabbedPaneUI:
>>>
>>> // Don't pad last run
>>> protected boolean shouldPadTabRun( int tabPlacement, int run ) {
>>>     return runCount > 1 && run < runCount - 1;
>>> }
>>>
>>> Does anyone has some knowledge about this? If metal does not want 
>>> pad that tab, my patch should be consider fixing the problem :-)
>>>
>> That strange line was introduced with fix of CR 4253906 (since 1999). 
>> Looks strange indeed...
>>
>> The fix looks good for me. What about a test? I'm not sure automatic 
>> test is possible here, so you can write manual test...
>>
>> Regards, Pavel
>>
> Hi Pavel,
>
> Test case is attached. I am trying to make it in the webrev, but I am 
> not quite understand "@run ****/manual=******". Should I use 
> applet/manual? Should I provide a bug7026933.html?
>
> PS:
> CR 4253906 does not have enough info......
>
I rewrote your test and committed the changes:
http://hg.openjdk.java.net/jdk8/awt/jdk/rev/1dd6fe680681

Thanks for your contribution!

Regards, Pavel

From littlee at linux.vnet.ibm.com  Sun Mar 25 23:10:31 2012
From: littlee at linux.vnet.ibm.com (Charles Lee)
Date: Mon, 26 Mar 2012 14:10:31 +0800
Subject: <Swing Dev> Fixes for sunbug 7026933 and 4310381
In-Reply-To: <4F6C794C.2010302@oracle.com>
References: <4F69A290.7030907@linux.vnet.ibm.com> <4F69D46B.2090302@oracle.com>
	<4F6C306B.9010404@linux.vnet.ibm.com> <4F6C794C.2010302@oracle.com>
Message-ID: <4F700857.8050105@linux.vnet.ibm.com>

Hi Pavel,

That's great. Thank you very much!

On 03/23/2012 09:23 PM, Pavel Porvatov wrote:
> Hi Charles,
>> On 03/21/2012 09:15 PM, Pavel Porvatov wrote:
>>> Hi Charles,
>>>> Hi guys,
>>>>
>>>> I am trying to fix 7026933 and 4310381.
>>>>
>>>> Patch @ http://cr.openjdk.java.net/~littlee/7026933/webrev.00/ 
>>>> <http://cr.openjdk.java.net/%7Elittlee/7026933/webrev.00/>
>>>>
>>>> The test case is @ 4310381 and 7026933.
>>>>
>>>> My patch fix the padding problem on all the tabs except the top 
>>>> tab. The reason about this is Metal look and feel does not want to 
>>>> pad the last one. Please check the code in MetalTabbedPaneUI:
>>>>
>>>> // Don't pad last run
>>>> protected boolean shouldPadTabRun( int tabPlacement, int run ) {
>>>>     return runCount > 1 && run < runCount - 1;
>>>> }
>>>>
>>>> Does anyone has some knowledge about this? If metal does not want 
>>>> pad that tab, my patch should be consider fixing the problem :-)
>>>>
>>> That strange line was introduced with fix of CR 4253906 (since 
>>> 1999). Looks strange indeed...
>>>
>>> The fix looks good for me. What about a test? I'm not sure automatic 
>>> test is possible here, so you can write manual test...
>>>
>>> Regards, Pavel
>>>
>> Hi Pavel,
>>
>> Test case is attached. I am trying to make it in the webrev, but I am 
>> not quite understand "@run ****/manual=******". Should I use 
>> applet/manual? Should I provide a bug7026933.html?
>>
>> PS:
>> CR 4253906 does not have enough info......
>>
> I rewrote your test and committed the changes:
> http://hg.openjdk.java.net/jdk8/awt/jdk/rev/1dd6fe680681
>
> Thanks for your contribution!
>
> Regards, Pavel
>


-- 
Yours Charles


From luchsh at linux.vnet.ibm.com  Mon Mar 26 01:29:12 2012
From: luchsh at linux.vnet.ibm.com (Jonathan Lu)
Date: Mon, 26 Mar 2012 16:29:12 +0800
Subject: <Swing Dev> Request for review 7155887: ComboBox does not paint
 focus correctly on GTK L&F
In-Reply-To: <4F6B3628.50707@oracle.com>
References: <4F6ACF28.5050102@linux.vnet.ibm.com> <4F6B3628.50707@oracle.com>
Message-ID: <4F7028D8.2000307@linux.vnet.ibm.com>

Hi Pavel,

Thanks for review, here's the new patch and my answers are inlined.
http://cr.openjdk.java.net/~luchsh/7155887_2/

On 03/22/2012 10:24 PM, Pavel Porvatov wrote:
> Hi Jonathan,
>> Hi Swing-dev,
>>
>> ComboBox on linux GTK L&F does not works as gtk native applications, 
>> when get focused, the apperance of Java ComboBox remains unchanged 
>> but native GTK ComboBox control will have a outline to indicate it 
>> has got focused.
>>
>> The problem seems similar to bug
>> 6947671 ( http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6947671),
>> except that I did not reproduced the problem on Nimbus L&F, so 
>> another bug
>> 7155887 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7155887)
>> was created for this issue,
>>
>> And here's the proposed patch to fix this problem,
>> http://cr.openjdk.java.net/~luchsh/7155887/
>>
>> Could anybody please help to take a look?
> I have several comments about the patch:
>
> 1. "c.getName().equals("ComboBox.renderer")": I think we can get NPE here
Yes, I've changed it to

"ComboBox.renderer".equals(c.getName())

>
> 2.
> +            for (Component comboBoxParent = c.getParent(); 
> comboBoxParent != null; comboBoxParent = comboBoxParent
> +                    .getParent()) {
> +                if (comboBoxParent instanceof JComboBox
> + && comboBoxParent.hasFocus()) {
> +                    comboBoxFocused = true;
> +                }
> +            }
>
> I'm not sure we should do such deep parent investigation. Why don't 
> you check first parent only?
>
javax.swing.CellRendererPane is inserted between the component and 
renderer, so if check only the first parent, it will retrieve a 
CellRendererPane object instead of JComboBox component. In the new 
patch, I added a break when JComboBox is encounterred so to make the 
effect similar to the first-parent-only approach.

> 3. "if (ENGINE.paintCachedImage(g, x, y, w, h, id, state) && 
> !comboBoxFocused)"
> If you are going to ignore ENGINE.paintCachedImage when 
> comboBoxFocused, then there is no need to invoke it at all
>
yes, in the new patch I've changed the order of these two checks.
> 4. "if (comboBoxFocused || focusSize > 0)"
> I'm not sure we should paint focus if focusSize == 0
>
I think there's no need to paint the focus if focusSize ==0, since the 
focus width and height arguements passed to JNI method 
native_paint_focus() will both be zero.
> Regards, Pavel

Regards
- Jonathan


From luchsh at linux.vnet.ibm.com  Mon Mar 26 03:17:57 2012
From: luchsh at linux.vnet.ibm.com (Jonathan Lu)
Date: Mon, 26 Mar 2012 18:17:57 +0800
Subject: <Swing Dev> Request for review 7155887: ComboBox does not paint
 focus correctly on GTK L&F
In-Reply-To: <4F7028D8.2000307@linux.vnet.ibm.com>
References: <4F6ACF28.5050102@linux.vnet.ibm.com> <4F6B3628.50707@oracle.com>
	<4F7028D8.2000307@linux.vnet.ibm.com>
Message-ID: <4F704255.3080708@linux.vnet.ibm.com>

Hi Pavel,

For the native_paint_focus imlementation, the underlying GTK 
implementation will just ignore the condition
|width <= 0 || height <= 0||

See |
||http://git.gnome.org/browse/gtk+/tree/gtk/gtkstylecontext.c:4133

So the excluding of focusSize == 0 seems reasonable to me.

Cheers!
- Jonathan

On 03/26/2012 04:29 PM, Jonathan Lu wrote:
> Hi Pavel,
>
> Thanks for review, here's the new patch and my answers are inlined.
> http://cr.openjdk.java.net/~luchsh/7155887_2/
>
> On 03/22/2012 10:24 PM, Pavel Porvatov wrote:
>> Hi Jonathan,
>>> Hi Swing-dev,
>>>
>>> ComboBox on linux GTK L&F does not works as gtk native applications, 
>>> when get focused, the apperance of Java ComboBox remains unchanged 
>>> but native GTK ComboBox control will have a outline to indicate it 
>>> has got focused.
>>>
>>> The problem seems similar to bug
>>> 6947671 ( http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6947671),
>>> except that I did not reproduced the problem on Nimbus L&F, so 
>>> another bug
>>> 7155887 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7155887)
>>> was created for this issue,
>>>
>>> And here's the proposed patch to fix this problem,
>>> http://cr.openjdk.java.net/~luchsh/7155887/
>>>
>>> Could anybody please help to take a look?
>> I have several comments about the patch:
>>
>> 1. "c.getName().equals("ComboBox.renderer")": I think we can get NPE 
>> here
> Yes, I've changed it to
>
> "ComboBox.renderer".equals(c.getName())
>
>>
>> 2.
>> +            for (Component comboBoxParent = c.getParent(); 
>> comboBoxParent != null; comboBoxParent = comboBoxParent
>> +                    .getParent()) {
>> +                if (comboBoxParent instanceof JComboBox
>> + && comboBoxParent.hasFocus()) {
>> +                    comboBoxFocused = true;
>> +                }
>> +            }
>>
>> I'm not sure we should do such deep parent investigation. Why don't 
>> you check first parent only?
>>
> javax.swing.CellRendererPane is inserted between the component and 
> renderer, so if check only the first parent, it will retrieve a 
> CellRendererPane object instead of JComboBox component. In the new 
> patch, I added a break when JComboBox is encounterred so to make the 
> effect similar to the first-parent-only approach.
>
>> 3. "if (ENGINE.paintCachedImage(g, x, y, w, h, id, state) && 
>> !comboBoxFocused)"
>> If you are going to ignore ENGINE.paintCachedImage when 
>> comboBoxFocused, then there is no need to invoke it at all
>>
> yes, in the new patch I've changed the order of these two checks.
>> 4. "if (comboBoxFocused || focusSize > 0)"
>> I'm not sure we should paint focus if focusSize == 0
>>
> I think there's no need to paint the focus if focusSize ==0, since the 
> focus width and height arguements passed to JNI method 
> native_paint_focus() will both be zero.
>> Regards, Pavel
>
> Regards
> - Jonathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120326/80d02f94/attachment.html 

From artem.ananiev at oracle.com  Mon Mar 26 06:04:11 2012
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Mon, 26 Mar 2012 17:04:11 +0400
Subject: <Swing Dev> [7u4] Review request for 7154480: [macosx] Not all
 popup menu items are visible
In-Reply-To: <950368AF-BBFB-4D96-A753-615198595F02@oracle.com>
References: <A598297D-351E-4DE7-8AC1-F2458FD97D21@oracle.com>
	<4F6CBD88.8070004@oracle.com>
	<2A93DB9F-83BA-479F-A4EA-6D05CF4E319D@oracle.com>
	<69FC6D44-8B81-4048-82BF-771321B83972@apple.com>
	<C54672C6-6B97-4334-906D-A49DF4D56482@oracle.com>
	<D0D07448-F687-41CF-96AF-2F4346F91820@apple.com>
	<950368AF-BBFB-4D96-A753-615198595F02@oracle.com>
Message-ID: <4F70694B.5080901@oracle.com>


The proposed fix implies the problem is only observed if no security 
manager is installed, is that correct? In that case, the fix looks fine...

On 3/24/2012 1:44 PM, Alexander Zuev wrote:
> Actually that was the behavior of popups till some time ago it was changed by the fix filled exactly about it - on Windows with the taskbar tall enough the popup populated off the tray icon were placed too far from the icon making it look unnatural. Just my $0.02

... but the whole approach in JPopupMenu when it's allowed to cover 
taskbar doesn't. What is "taskbar" here? Is Mac OS X dock area a 
taskbar? What if it's configured to be on the left/right side of the 
screen? Why JPopupMenu is related to tray icons, while native popups are 
expected to be used in this case?

Could anyone from the Swing group comment, please?

Thanks,

Artem

> With best regards,
> Alexander Zuev
>
> 23.03.2012, ? 23:25, Mike Swingler<swingler at apple.com>  ???????(?):
>
>> I agree that the proper fix is to make the popup code evade the screen insets?is there a bug tracking that?
>>
>> Regards,
>> Mike Swingler
>> Apple Inc
>>
>> On Mar 23, 2012, at 11:56 AM, Scott Kovatch wrote:
>>
>>> Looks like that's only true when the dock is on the side like you have it configured in that screen shot. I can't get it to happen when the Dock is at the bottom of the screen.
>>>
>>> That makes sense, though. This bug is about not being able to autoscroll the popup because you can't move the mouse into the auto-scroll area. That's not an issue when the dock is on the side.
>>>
>>> - Scott
>>>
>>> On Mar 23, 2012, at 11:49 AM, Mike Swingler wrote:
>>>
>>>> Actually, popups _can_ occlude the Dock, but it's very bad form for them to do so. Every effort should be taken to push the popup into the usable insets of the screen?but popups definitely overlap the menubar and the Dock when forced.
>>>>
>>>> <Screen Shot 2012-03-23 at 11.46.37 AM.png>
>>>>
>>>> ~Mike
>>>>
>>>> On Mar 23, 2012, at 11:36 AM, Scott Kovatch wrote:
>>>>
>>>>> No, that's not the right behavior on OS X. The Dock sits above everything else when it's visible -- popups never cover the Dock.  You can see this by taking just about any window and dragging it down so it goes behind the dock, then right-click on the window.  The context menu always gets pushed up so the bottom of the popup menu sits right above the dock.  I think this is the right fix.
>>>>>
>>>>> Out of curiosity, why is it necessary to look for SET_WINDOW_ALWAYS_ON_TOP_PERMISSION? Is it considered bad form or some kind of security issue to block a task bar on Windows?
>>>>>
>>>>> -- Scott
>>>>>
>>>>> On Mar 23, 2012, at 11:14 AM, Anthony Petrov wrote:
>>>>>
>>>>>> Hi Leonid,
>>>>>>
>>>>>> The code changes look good to me. I'm approving the fix given the emergency of the issue.
>>>>>>
>>>>>> However, I think that a more elegant solution for this bug would be to -setLevel: for always-on-top Java windows of the type POPUP to a value that pushes the windows above the dock. This way we wouldn't need an overridable method in the SunToolkit class. Could you file a CR to investigate this possibility in a future release please?
>>>>>>
>>>>>> --
>>>>>> best regards,
>>>>>> Anthony
>>>>>>
>>>>>> On 3/23/2012 9:48 PM, Leonid Romanov wrote:
>>>>>>> Hi,
>>>>>>> Release team has decided that we'd better fix 7154480 for 7u4 because of its high impact on users, so please review a fix for it. The fix prevents popups from overlapping with the Dock/menu bar on OS X, keeping the old behavior for other platforms.
>>>>>>> Bug:  http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7154480
>>>>>>> Webrev: http://cr.openjdk.java.net/~leonidr/7154480/webrev.00/
>>>>>>> Thanks,
>>>>>>> Leonid.
>>>>>
>>>>
>>>
>>

From alexander.zuev at oracle.com  Mon Mar 26 06:21:34 2012
From: alexander.zuev at oracle.com (Alexander Zuev)
Date: Mon, 26 Mar 2012 17:21:34 +0400
Subject: <Swing Dev> [7u4] Review request for 7154480: [macosx] Not all
 popup menu items are visible
In-Reply-To: <4F70694B.5080901@oracle.com>
References: <A598297D-351E-4DE7-8AC1-F2458FD97D21@oracle.com>
	<4F6CBD88.8070004@oracle.com>
	<2A93DB9F-83BA-479F-A4EA-6D05CF4E319D@oracle.com>
	<69FC6D44-8B81-4048-82BF-771321B83972@apple.com>
	<C54672C6-6B97-4334-906D-A49DF4D56482@oracle.com>
	<D0D07448-F687-41CF-96AF-2F4346F91820@apple.com>
	<950368AF-BBFB-4D96-A753-615198595F02@oracle.com>
	<4F70694B.5080901@oracle.com>
Message-ID: <4F706D5E.7010907@oracle.com>

On 3/26/12 17:04, Artem Ananiev wrote:
>
> The proposed fix implies the problem is only observed if no security 
> manager is installed, is that correct? In that case, the fix looks 
> fine...
>
> On 3/24/2012 1:44 PM, Alexander Zuev wrote:
>> Actually that was the behavior of popups till some time ago it was 
>> changed by the fix filled exactly about it - on Windows with the 
>> taskbar tall enough the popup populated off the tray icon were placed 
>> too far from the icon making it look unnatural. Just my $0.02
>
> ... but the whole approach in JPopupMenu when it's allowed to cover 
> taskbar doesn't. What is "taskbar" here? Is Mac OS X dock area a 
> taskbar? What if it's configured to be on the left/right side of the 
> screen? Why JPopupMenu is related to tray icons, while native popups 
> are expected to be used in this case?
I only pointed out why we don't obey screen insets when placing popup on 
the screen - the reason was taskbar on Windows (there is no such thing 
on Mac OS X) was counted as an screen inset and placing popup inside 
screen insets caused visual troubles for customers and this is exactly 
why this behavior (accounting screen insets when positioning popup on 
screen) was changed. I don't think that new behavior is correct for all 
platforms but OTOH it was not my fix.
>> With best regards,
>> Alexander Zuev
>>
>> 23.03.2012, ? 23:25, Mike Swingler<swingler at apple.com>  ???????(?):
>>
>>> I agree that the proper fix is to make the popup code evade the 
>>> screen insets?is there a bug tracking that?
>>>
>>> Regards,
>>> Mike Swingler
>>> Apple Inc
>>>
>>> On Mar 23, 2012, at 11:56 AM, Scott Kovatch wrote:
>>>
>>>> Looks like that's only true when the dock is on the side like you 
>>>> have it configured in that screen shot. I can't get it to happen 
>>>> when the Dock is at the bottom of the screen.
>>>>
>>>> That makes sense, though. This bug is about not being able to 
>>>> autoscroll the popup because you can't move the mouse into the 
>>>> auto-scroll area. That's not an issue when the dock is on the side.
>>>>
>>>> - Scott
>>>>
>>>> On Mar 23, 2012, at 11:49 AM, Mike Swingler wrote:
>>>>
>>>>> Actually, popups _can_ occlude the Dock, but it's very bad form 
>>>>> for them to do so. Every effort should be taken to push the popup 
>>>>> into the usable insets of the screen?but popups definitely overlap 
>>>>> the menubar and the Dock when forced.
>>>>>
>>>>> <Screen Shot 2012-03-23 at 11.46.37 AM.png>
>>>>>
>>>>> ~Mike
>>>>>
>>>>> On Mar 23, 2012, at 11:36 AM, Scott Kovatch wrote:
>>>>>
>>>>>> No, that's not the right behavior on OS X. The Dock sits above 
>>>>>> everything else when it's visible -- popups never cover the 
>>>>>> Dock.  You can see this by taking just about any window and 
>>>>>> dragging it down so it goes behind the dock, then right-click on 
>>>>>> the window.  The context menu always gets pushed up so the bottom 
>>>>>> of the popup menu sits right above the dock.  I think this is the 
>>>>>> right fix.
>>>>>>
>>>>>> Out of curiosity, why is it necessary to look for 
>>>>>> SET_WINDOW_ALWAYS_ON_TOP_PERMISSION? Is it considered bad form or 
>>>>>> some kind of security issue to block a task bar on Windows?
>>>>>>
>>>>>> -- Scott
>>>>>>
>>>>>> On Mar 23, 2012, at 11:14 AM, Anthony Petrov wrote:
>>>>>>
>>>>>>> Hi Leonid,
>>>>>>>
>>>>>>> The code changes look good to me. I'm approving the fix given 
>>>>>>> the emergency of the issue.
>>>>>>>
>>>>>>> However, I think that a more elegant solution for this bug would 
>>>>>>> be to -setLevel: for always-on-top Java windows of the type 
>>>>>>> POPUP to a value that pushes the windows above the dock. This 
>>>>>>> way we wouldn't need an overridable method in the SunToolkit 
>>>>>>> class. Could you file a CR to investigate this possibility in a 
>>>>>>> future release please?
>>>>>>>
>>>>>>> -- 
>>>>>>> best regards,
>>>>>>> Anthony
>>>>>>>
>>>>>>> On 3/23/2012 9:48 PM, Leonid Romanov wrote:
>>>>>>>> Hi,
>>>>>>>> Release team has decided that we'd better fix 7154480 for 7u4 
>>>>>>>> because of its high impact on users, so please review a fix for 
>>>>>>>> it. The fix prevents popups from overlapping with the Dock/menu 
>>>>>>>> bar on OS X, keeping the old behavior for other platforms.
>>>>>>>> Bug:  http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7154480
>>>>>>>> Webrev: http://cr.openjdk.java.net/~leonidr/7154480/webrev.00/
>>>>>>>> Thanks,
>>>>>>>> Leonid.
>>>>>>
>>>>>
>>>>
>>>


From artem.ananiev at oracle.com  Mon Mar 26 06:40:24 2012
From: artem.ananiev at oracle.com (Artem Ananiev)
Date: Mon, 26 Mar 2012 17:40:24 +0400
Subject: <Swing Dev> <AWT Dev> Request for review: 7155298 : Editable
 TextArea blocks GUI application from exit
In-Reply-To: <CAK6==_=NZBs418ixrPpKmBMWN_e6DuJKNHi7bACz4sqiMSwHeg@mail.gmail.com>
References: <CAOo=rxWoExdrCbp-iod4dyCG1kj47ZrMZgMJ4hPa1mbXbxVMUg@mail.gmail.com>
	<CAK6==_kghcdGRRbUXT37xAZRehbBKUn+6oJM_=dMnNtrFJbJRQ@mail.gmail.com>
	<CAOo=rxUo1rjzp4apeLULv6PN-MGWthRFYqmtsqS7Nrn1M++Mvg@mail.gmail.com>
	<CAK6==_m27G8CmniOACB3bnFZmnnDekE+dk16TR2G32jnZzOnyA@mail.gmail.com>
	<CAOo=rxUuWNFJJni=r+P5XQVRefNiw2mSZ+qzMobMvTM4AOLqug@mail.gmail.com>
	<CAK6==_kOyHjTEDpUdON=Vvhv4TtURLYb5k_Wuwg9ub4=wTk1QQ@mail.gmail.com>
	<4F6AFC94.4000809@oracle.com>
	<CAK6==_=OyVdr_aJ=2j-CnuwmjVi1atzVf5-j7r+w9B2BkrE8pQ@mail.gmail.com>
	<4F6B2F39.3060308@oracle.com>
	<CAK6==_mde=JC5Cj1C+DkZWN9=W_uCTrv6ACxtaAtaJk++iGXTQ@mail.gmail.com>
	<4F6B7478.4010103@oracle.com>
	<CAK6==_=NZBs418ixrPpKmBMWN_e6DuJKNHi7bACz4sqiMSwHeg@mail.gmail.com>
Message-ID: <4F7071C8.8020804@oracle.com>


Adding swing-dev back to CC since a question about JComponent has appeared.

Artem

On 3/22/2012 10:04 PM, Oleg Sukhodolsky wrote:
> On Thu, Mar 22, 2012 at 10:50 PM, Anton V. Tarasov
> <anton.tarasov at oracle.com>  wrote:
>> On 3/22/12 6:15 PM, Oleg Sukhodolsky wrote:
>>>
>>> On Thu, Mar 22, 2012 at 5:55 PM, Anton V. Tarasov
>>> <anton.tarasov at oracle.com>    wrote:
>>>>
>>>> On 22.03.2012 14:37, Oleg Sukhodolsky wrote:
>>>>>
>>>>> On Thu, Mar 22, 2012 at 2:19 PM, Anton V. Tarasov
>>>>> <anton.tarasov at oracle.com>      wrote:
>>>>>>
>>>>>> On 22.03.2012 12:47, Oleg Sukhodolsky wrote:
>>>>>>>
>>>>>>> On Thu, Mar 22, 2012 at 12:01 PM, Sean Chou<zhouyx at linux.vnet.ibm.com>
>>>>>>>   wrote:
>>>>>>>>
>>>>>>>> Hi Oleg,
>>>>>>>>
>>>>>>>>      Seem there are misunderstanding .
>>>>>>>>      DefaultCaret can receive FocusLostEvent when another control get
>>>>>>>> focused. But it
>>>>>>>> doesn't receive FocusLostEvent when disposing.
>>>>>>>>
>>>>>>>>      The reason is XTextAreaPeer doesn't receive FocusLostEvent when
>>>>>>>> disposing. But
>>>>>>>> I don't know if it is a rule that a FocusLostEvent must be sent to
>>>>>>>> the
>>>>>>>> focused>>>      component when the top-level window is disposed ?
>>>>>>>
>>>>>>> Well, for regular AWT component it is expected.  And I'd expect that
>>>>>>> this should also be true for peer.
>>>>>>
>>>>>>
>>>>>> That's right, focus_lost should be dispatched to a disposed focus
>>>>>> owner.
>>>>>
>>>>> So, now we need to figure out why the caret doesn't get the event.
>>>>>
>>>>> Oleg.
>>>>
>>>>
>>>> I ran the testcase provided in the webrev and debugged a little.
>>>> FOCUS_LOST
>>>> does come to the textarea on its disposal, though when the focus event is
>>>> being dispatched I see the peer is null.
>>>> This is quite expected actually. When Component.removeNotify() is called
>>>> on
>>>> EDT, it transfers focus further (appropriate focus events get queued) and
>>>> then nullifies the peer. The events come later.
>>>> Hope this helps.
>>>
>>> Thank you (I do not have Linux, so I can not debug this).
>>> So, now we know that the cause of the problem is that our internal
>>> AWTText(Field|Area) may be disposed while they think
>>> that they are focused, and, at the same time, we can not propogate
>>> real focus lost to them since peer is desposed
>>> before we receive the event.
>>> So, the suggested fix works fine for one particular problem (unstopped
>>> timer), but we may get some other
>>> problems due to the cause.
>>> For me it looks like better fix would be to pass synthetic focus lost
>>> when we dispose text peer, this way we guarantee
>>> that life-circle of our synthetic components will be similar to real
>>> ones and we will meet Swing's expectations.
>>>
>>> Does this sounds reasonable?
>>>
>>> Regards, Oleg.
>>
>>
>> This sounds reasonable, though I personally don't like the idea of yet
>> another synthetic focus event...
>
> well, (synthetic) focus events are your area of expertise ;)
>
>> I actually like the fix Sean suggested (after we see the whole picture).
>> Otherwise, we may follow your suggestion
>> to create AWTTextArea.removeNotify(). And even simpler, why not to put
>> getCaret().setVisible(false) right into JTextComponent.removeNotify()?
>
> well, the later is a question for Swing team.
> The former is reasonable fix (not the best one, but good enough).
> So, if everyone agree with this approach then I'm fine (hope this is
> the only problem we
> will have with invisible focused JTextXXX)
>
> Oleg.
>
>>
>> Either of these looks fine to me.
>>
>> Thanks,
>> Anton.
>>
>>

From pavel.porvatov at oracle.com  Mon Mar 26 06:38:27 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Mon, 26 Mar 2012 17:38:27 +0400
Subject: <Swing Dev> Review request for 7154030:
 java.awt.Component.hide() does not repaint parent container
In-Reply-To: <CAC-GWLcHxYxnOJPmmv0j2GOtahHwJJqntK43367R5YJi8xZJNA@mail.gmail.com>
References: <CAC-GWLe8d6mR+tyoEKOuSb4A8Caun-9_NcTePV7+i0McJjsO+w@mail.gmail.com>
	<4F67511F.5040109@oracle.com>
	<CAC-GWLenUzrra+P3_U3mQuho34Oj3OXRE+ievM44WarNYS4G7w@mail.gmail.com>
	<4F6845B3.1060506@oracle.com>
	<CAC-GWLcmkA_tbydcKLfvor_nGTAOiS1xboC0Ua3wiXou=d7vOw@mail.gmail.com>
	<4F688E2E.9080508@oracle.com>
	<CAC-GWLcHxYxnOJPmmv0j2GOtahHwJJqntK43367R5YJi8xZJNA@mail.gmail.com>
Message-ID: <4F707153.5060803@oracle.com>

Hi Jonathan,
> Hi Pavel,
>
> Thanks for your explanation.
>
> But this bug affects almost all Swing components, hide()'s presence 
> also helps to maintain backward compatibility, so is it possible to 
> put a fix in JComponent to help all the potential affected 
> applications to work correctly? 
Of course that's possible. Do you have final version of the fix? Please 
don't forget write an automatic test.
> if not, is it there any sunset plan for these deprecated APIs?
I don't now such plans.

Regards, Pavel

P.S. I removed <AWT Dev>, it seems only Swing will be affected in this fix
> Thanks and best regards!
>
> - Jonathan
>
> 2012/3/20 Pavel Porvatov <pavel.porvatov at oracle.com 
> <mailto:pavel.porvatov at oracle.com>>
>
>     Hi Jonathan,
>>     Hi Artem,
>>
>>     2012/3/20 Artem Ananiev <artem.ananiev at oracle.com
>>     <mailto:artem.ananiev at oracle.com>>
>>
>>         Hi, Jonathan,
>>
>>         I'm adding swing-dev to CC as we now consider changing Swing
>>         code.
>>
>>         What you propose sounds technically reasonable, but I don't
>>         think it is worth doing anyway as show() and hide() have been
>>         deprecated for years now.
>>
>>
>>     Although show() and hide() have been deprecated for years, in my
>>     opinion supporting these APIs will still benefit many
>>     applications and convince users that Java still has got strong
>>     backward compatibility :D. Any ideas from Swing group?
>     I don't see why the words "backward compatibility" are here. There
>     is a bug in deprecated methods "show" and "hide" (I've checked
>     that jdk5 has the same problem), and that's one additional reason
>     to use setVisible(). I agree with Artem that fixing deprecated API
>     is not a high priority task (but we should keep backward
>     compatibility, of course). I also think, that "to leave all as is"
>     is a good decision for the described problem
>
>     Regards, Pavel
>
>>
>>
>>         Even if we accept the change in JComponent.hide(), we should
>>         then override show() as well (lightweight component may be
>>         non-opaque, so we should repaint from its parent), so there
>>         will be code duplication. This is one more reason to leave
>>         all as is.
>>
>>
>>     Yes, I noticed that code duplication too and am trying to make a
>>     more compact patch for this problem.
>>
>>         This is my personal opinion, I'm not a Swing expert, though.
>>         Let anyone from the Swing group comment.
>>
>>         Thanks,
>>
>>         Artem
>>
>>         On 3/20/2012 12:28 PM, Jonathan Lu wrote:
>>
>>             Hi Artem,
>>
>>             Thanks for your time.
>>
>>             2012/3/19 Artem Ananiev <artem.ananiev at oracle.com
>>             <mailto:artem.ananiev at oracle.com>
>>             <mailto:artem.ananiev at oracle.com
>>             <mailto:artem.ananiev at oracle.com>>>
>>
>>                Hi, Jonathan,
>>
>>                given the code in java.awt.Component, your statement about
>>                difference between hide() and setVisible(false) looks
>>             pretty strange
>>                to me. Indeed, here is the implementation:
>>
>>
>>
>>                    public void show(boolean b) {
>>                        if (b) {
>>                            show();
>>                        } else {
>>                            hide();
>>                        }
>>                    }
>>
>>                and
>>
>>                    public void setVisible(boolean b) {
>>                        show(b);
>>                    }
>>
>>                In JComponent the latter method is overridden and adds
>>             exactly what
>>                you propose: parent.repaint(). This addition makes
>>             sense for
>>                lightweight components (e.g. Swing), but heavyweight
>>             AWT components
>>                shouldn't require this: repaint request is sent from
>>             the native system.
>>
>>
>>             Yes, lightweight and  heavyweight components differ in
>>             painting. The
>>             original test case only works for the conditions of
>>             lightweight
>>             components, with another test case for heavyweight
>>             components, I found
>>             that the problem could not be reproduced on AWT any more.
>>             I think the
>>             change is only applicable for Swing components, so how
>>             about repaint in
>>             JComponent.hide() like this?
>>
>>             diff -r cdbb33303ea3
>>             src/share/classes/javax/swing/JComponent.java
>>             --- a/src/share/classes/javax/swing/JComponent.java  
>>              Wed Mar 14
>>             13:50:37 2012 -0700 <tel:2012%20-0700> <tel:2012%20-0700>
>>             +++ b/src/share/classes/javax/swing/JComponent.java  
>>              Tue Mar 20
>>             16:24:09 2012 +0800
>>             @@ -5237,6 +5237,16 @@
>>                      }
>>                  }
>>
>>             +    public void hide() {
>>             +        super.hide();
>>             +        Container parent = getParent();
>>             +        if (parent != null) {
>>             +            Rectangle r = getBounds();
>>             +            parent.repaint(r.x, r.y, r.width, r.height);
>>             +            parent.invalidate();
>>             +        }
>>             +    }
>>             +
>>                  /**
>>                   * Returns whether or not the region of the
>>             specified component is
>>                   * obscured by a sibling.
>>
>>
>>
>>                Thanks,
>>
>>                Artem
>>
>>
>>                On 3/15/2012 12:24 PM, Jonathan Lu wrote:
>>
>>                    Hi awt-dev,
>>
>>                    java.awt.Component.hide() was declared as
>>             deprecation and
>>                    replaced by
>>                    setVisible(boolean), but in my tests, it does not
>>             works in the
>>                    same way
>>                    as setVisible(false). The reason of this failure
>>             is that
>>                    java.awt.Component.hide() does not repaint the
>>             special area it
>>                    used to
>>                    taken of parent container. Although this is
>>             deprecated method,
>>                    it may
>>                    still valuable for customers due to compatibility
>>             reason. Bug
>>                    7154030
>>                    created for this issue.
>>
>>                    Here's a simple test case to demonstrate this problem.
>>
>>                    /*
>>                      * Copyright (c) 2012 Oracle and/or its
>>             affiliates. All rights
>>                    reserved.
>>                      * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR
>>             THIS FILE HEADER.
>>                      *
>>                      * This code is free software; you can
>>             redistribute it and/or
>>                    modify it
>>                      * under the terms of the GNU General Public
>>             License version 2
>>                    only, as
>>                      * published by the Free Software Foundation.
>>                      *
>>                      * This code is distributed in the hope that it
>>             will be useful, but
>>                    WITHOUT
>>                      * ANY WARRANTY; without even the implied warranty of
>>                    MERCHANTABILITY or
>>                      * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>>             General
>>                    Public License
>>                      * version 2 for more details (a copy is included
>>             in the
>>                    LICENSE file that
>>                      * accompanied this code).
>>                      *
>>                      * You should have received a copy of the GNU
>>             General Public
>>                    License
>>                    version
>>                      * 2 along with this work; if not, write to the
>>             Free Software
>>                    Foundation,
>>                      * Inc., 51 Franklin St, Fifth Floor, Boston, MA
>>             02110-1301 USA.
>>                      *
>>                      * Please contact Oracle, 500 Oracle Parkway,
>>             Redwood Shores,
>>                    CA 94065 USA
>>                      * or visit www.oracle.com
>>             <http://www.oracle.com> <http://www.oracle.com> if you need
>>                    additional information or have any
>>                      * questions.
>>                      */
>>
>>                    /*
>>                      * Portions Copyright (c) 2012 IBM Corporation
>>                      */
>>
>>                    import javax.swing.*;
>>
>>                    /* @test 1.1 2012/03/15
>>                        @bug 7154030
>>                        @run main/manual ComponentHideShowTest.html */
>>
>>                    @SuppressWarnings("serial")
>>                    public class ComponetHideShowTest extends JFrame {
>>                         JInternalFrame internalFrame;
>>                         JButton btn;
>>                         JDesktopPane desktop;
>>
>>                         ComponetHideShowTest(String name) {
>>                             super(name);
>>                             desktop = new JDesktopPane();
>>                             setContentPane(desktop);
>>
>>                             setSize(600, 400);
>>                             setVisible(true);
>>
>>                             internalFrame = new JInternalFrame("Test
>>             Internal Frame");
>>                             internalFrame.setSize(100, 100);
>>                             internalFrame.setLocation(10, 10);
>>                             internalFrame.setVisible(true)__;
>>                             desktop.add(internalFrame);
>>
>>                             btn = new JButton("OK");
>>                             btn.setSize(100, 50);
>>                             btn.setLocation( 300, 300);
>>                             btn.setVisible(true);
>>                             desktop.add(btn);
>>
>>                            
>>             setDefaultCloseOperation(__JFrame.EXIT_ON_CLOSE);
>>                         }
>>
>>                         @SuppressWarnings("__deprecation")
>>                         public void runTest() throws Exception {
>>                             Object[] options = { "Yes, I saw it",
>>             "No, I did not
>>                    see it!" };
>>
>>                             int ret =
>>             JOptionPane.showOptionDialog(__this,
>>                    "Do you see the internal window?",
>>             "InternalFrmaeHideTest",
>>                                     JOptionPane.YES_NO_OPTION,
>>                    JOptionPane.QUESTION_MESSAGE, null,
>>                                     options, options[1]);
>>
>>                             if (ret == 1 || ret ==
>>             JOptionPane.CLOSED_OPTION) {
>>                                 throw new Exception("Failed to
>>             display internal
>>                    window");
>>                             }
>>
>>                             internalFrame.hide();
>>                             btn.hide();
>>
>>                             ret = JOptionPane.showOptionDialog(__this,
>>                    "Do you see the internal window?",
>>             "InternalFrmaeHideTest",
>>                                     JOptionPane.YES_NO_OPTION,
>>                    JOptionPane.QUESTION_MESSAGE, null,
>>                                     options, options[1]);
>>
>>                             if (ret == 0 || ret ==
>>             JOptionPane.CLOSED_OPTION) {
>>                                 throw new Exception("Failed to hide
>>             internal window");
>>                             }
>>
>>                             internalFrame.show();
>>                             btn.show();
>>
>>                             ret = JOptionPane.showOptionDialog(__this,
>>                    "Do you see the internal window?",
>>             "InternalFrmaeHideTest",
>>                                     JOptionPane.YES_NO_OPTION,
>>                    JOptionPane.QUESTION_MESSAGE, null,
>>                                     options, options[1]);
>>
>>                             if (ret == 1 || ret ==
>>             JOptionPane.CLOSED_OPTION) {
>>                                 throw new Exception("Failed to hide
>>             internal window");
>>                             }
>>                         }
>>
>>                         public static void main(String[] args) throws
>>             Exception {
>>                             ComponetHideShowTest test = null;
>>                             test = new
>>             ComponetHideShowTest("__InternalFrameHideTest");
>>                             test.runTest();
>>                         }
>>                    }
>>
>>                    And here's the patch
>>             http://cr.openjdk.java.net/~__littlee/7154030/
>>             <http://cr.openjdk.java.net/%7E__littlee/7154030/>
>>             <http://cr.openjdk.java.net/%7Elittlee/7154030/>
>>
>>                    Can anybody please help to take a look?
>>
>>                    Cheers!
>>                    - Jonathan
>>
>>
>>             Best regards!
>>             - Jonathan
>>
>>
>>     Thanks a lot !
>>
>>     - Jonathan
>
>

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

From luchsh at linux.vnet.ibm.com  Tue Mar 27 00:46:44 2012
From: luchsh at linux.vnet.ibm.com (Jonathan Lu)
Date: Tue, 27 Mar 2012 15:46:44 +0800
Subject: <Swing Dev> Review request for 7154030:
 java.awt.Component.hide() does not repaint parent container
In-Reply-To: <4F707153.5060803@oracle.com>
References: <CAC-GWLe8d6mR+tyoEKOuSb4A8Caun-9_NcTePV7+i0McJjsO+w@mail.gmail.com>
	<4F67511F.5040109@oracle.com>
	<CAC-GWLenUzrra+P3_U3mQuho34Oj3OXRE+ievM44WarNYS4G7w@mail.gmail.com>
	<4F6845B3.1060506@oracle.com>
	<CAC-GWLcmkA_tbydcKLfvor_nGTAOiS1xboC0Ua3wiXou=d7vOw@mail.gmail.com>
	<4F688E2E.9080508@oracle.com>
	<CAC-GWLcHxYxnOJPmmv0j2GOtahHwJJqntK43367R5YJi8xZJNA@mail.gmail.com>
	<4F707153.5060803@oracle.com>
Message-ID: <4F717064.9030803@linux.vnet.ibm.com>

Hello Pavel,

Here's the updated patch and automatic test for bug 7154030, could you 
please take another look?
http://cr.openjdk.java.net/~luchsh/7154030_2/

Thanks and best regards
- Jonathan Lu

On 03/26/2012 09:38 PM, Pavel Porvatov wrote:
> Hi Jonathan,
>> Hi Pavel,
>>
>> Thanks for your explanation.
>>
>> But this bug affects almost all Swing components, hide()'s presence 
>> also helps to maintain backward compatibility, so is it possible to 
>> put a fix in JComponent to help all the potential affected 
>> applications to work correctly? 
> Of course that's possible. Do you have final version of the fix? 
> Please don't forget write an automatic test.
>> if not, is it there any sunset plan for these deprecated APIs?
> I don't now such plans.
>
> Regards, Pavel
>
> P.S. I removed <AWT Dev>, it seems only Swing will be affected in this fix
>> Thanks and best regards!
>>
>> - Jonathan
>>
>> 2012/3/20 Pavel Porvatov <pavel.porvatov at oracle.com 
>> <mailto:pavel.porvatov at oracle.com>>
>>
>>     Hi Jonathan,
>>>     Hi Artem,
>>>
>>>     2012/3/20 Artem Ananiev <artem.ananiev at oracle.com
>>>     <mailto:artem.ananiev at oracle.com>>
>>>
>>>         Hi, Jonathan,
>>>
>>>         I'm adding swing-dev to CC as we now consider changing Swing
>>>         code.
>>>
>>>         What you propose sounds technically reasonable, but I don't
>>>         think it is worth doing anyway as show() and hide() have
>>>         been deprecated for years now.
>>>
>>>
>>>     Although show() and hide() have been deprecated for years, in my
>>>     opinion supporting these APIs will still benefit many
>>>     applications and convince users that Java still has got strong
>>>     backward compatibility :D. Any ideas from Swing group?
>>     I don't see why the words "backward compatibility" are here.
>>     There is a bug in deprecated methods "show" and "hide" (I've
>>     checked that jdk5 has the same problem), and that's one
>>     additional reason to use setVisible(). I agree with Artem that
>>     fixing deprecated API is not a high priority task (but we should
>>     keep backward compatibility, of course). I also think, that "to
>>     leave all as is" is a good decision for the described problem
>>
>>     Regards, Pavel
>>
>>>
>>>
>>>         Even if we accept the change in JComponent.hide(), we should
>>>         then override show() as well (lightweight component may be
>>>         non-opaque, so we should repaint from its parent), so there
>>>         will be code duplication. This is one more reason to leave
>>>         all as is.
>>>
>>>
>>>     Yes, I noticed that code duplication too and am trying to make a
>>>     more compact patch for this problem.
>>>
>>>         This is my personal opinion, I'm not a Swing expert, though.
>>>         Let anyone from the Swing group comment.
>>>
>>>         Thanks,
>>>
>>>         Artem
>>>
>>>         On 3/20/2012 12:28 PM, Jonathan Lu wrote:
>>>
>>>             Hi Artem,
>>>
>>>             Thanks for your time.
>>>
>>>             2012/3/19 Artem Ananiev <artem.ananiev at oracle.com
>>>             <mailto:artem.ananiev at oracle.com>
>>>             <mailto:artem.ananiev at oracle.com
>>>             <mailto:artem.ananiev at oracle.com>>>
>>>
>>>                Hi, Jonathan,
>>>
>>>                given the code in java.awt.Component, your statement
>>>             about
>>>                difference between hide() and setVisible(false) looks
>>>             pretty strange
>>>                to me. Indeed, here is the implementation:
>>>
>>>
>>>
>>>                    public void show(boolean b) {
>>>                        if (b) {
>>>                            show();
>>>                        } else {
>>>                            hide();
>>>                        }
>>>                    }
>>>
>>>                and
>>>
>>>                    public void setVisible(boolean b) {
>>>                        show(b);
>>>                    }
>>>
>>>                In JComponent the latter method is overridden and
>>>             adds exactly what
>>>                you propose: parent.repaint(). This addition makes
>>>             sense for
>>>                lightweight components (e.g. Swing), but heavyweight
>>>             AWT components
>>>                shouldn't require this: repaint request is sent from
>>>             the native system.
>>>
>>>
>>>             Yes, lightweight and  heavyweight components differ in
>>>             painting. The
>>>             original test case only works for the conditions of
>>>             lightweight
>>>             components, with another test case for heavyweight
>>>             components, I found
>>>             that the problem could not be reproduced on AWT any
>>>             more. I think the
>>>             change is only applicable for Swing components, so how
>>>             about repaint in
>>>             JComponent.hide() like this?
>>>
>>>             diff -r cdbb33303ea3
>>>             src/share/classes/javax/swing/JComponent.java
>>>             --- a/src/share/classes/javax/swing/JComponent.java  
>>>              Wed Mar 14
>>>             13:50:37 2012 -0700 <tel:2012%20-0700> <tel:2012%20-0700>
>>>             +++ b/src/share/classes/javax/swing/JComponent.java  
>>>              Tue Mar 20
>>>             16:24:09 2012 +0800
>>>             @@ -5237,6 +5237,16 @@
>>>                      }
>>>                  }
>>>
>>>             +    public void hide() {
>>>             +        super.hide();
>>>             +        Container parent = getParent();
>>>             +        if (parent != null) {
>>>             +            Rectangle r = getBounds();
>>>             +            parent.repaint(r.x, r.y, r.width, r.height);
>>>             +            parent.invalidate();
>>>             +        }
>>>             +    }
>>>             +
>>>                  /**
>>>                   * Returns whether or not the region of the
>>>             specified component is
>>>                   * obscured by a sibling.
>>>
>>>
>>>
>>>                Thanks,
>>>
>>>                Artem
>>>
>>>
>>>                On 3/15/2012 12:24 PM, Jonathan Lu wrote:
>>>
>>>                    Hi awt-dev,
>>>
>>>                    java.awt.Component.hide() was declared as
>>>             deprecation and
>>>                    replaced by
>>>                    setVisible(boolean), but in my tests, it does not
>>>             works in the
>>>                    same way
>>>                    as setVisible(false). The reason of this failure
>>>             is that
>>>                    java.awt.Component.hide() does not repaint the
>>>             special area it
>>>                    used to
>>>                    taken of parent container. Although this is
>>>             deprecated method,
>>>                    it may
>>>                    still valuable for customers due to compatibility
>>>             reason. Bug
>>>                    7154030
>>>                    created for this issue.
>>>
>>>                    Here's a simple test case to demonstrate this
>>>             problem.
>>>
>>>                    /*
>>>                      * Copyright (c) 2012 Oracle and/or its
>>>             affiliates. All rights
>>>                    reserved.
>>>                      * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR
>>>             THIS FILE HEADER.
>>>                      *
>>>                      * This code is free software; you can
>>>             redistribute it and/or
>>>                    modify it
>>>                      * under the terms of the GNU General Public
>>>             License version 2
>>>                    only, as
>>>                      * published by the Free Software Foundation.
>>>                      *
>>>                      * This code is distributed in the hope that it
>>>             will be useful, but
>>>                    WITHOUT
>>>                      * ANY WARRANTY; without even the implied
>>>             warranty of
>>>                    MERCHANTABILITY or
>>>                      * FITNESS FOR A PARTICULAR PURPOSE.  See the
>>>             GNU General
>>>                    Public License
>>>                      * version 2 for more details (a copy is
>>>             included in the
>>>                    LICENSE file that
>>>                      * accompanied this code).
>>>                      *
>>>                      * You should have received a copy of the GNU
>>>             General Public
>>>                    License
>>>                    version
>>>                      * 2 along with this work; if not, write to the
>>>             Free Software
>>>                    Foundation,
>>>                      * Inc., 51 Franklin St, Fifth Floor, Boston, MA
>>>             02110-1301 USA.
>>>                      *
>>>                      * Please contact Oracle, 500 Oracle Parkway,
>>>             Redwood Shores,
>>>                    CA 94065 USA
>>>                      * or visit www.oracle.com
>>>             <http://www.oracle.com> <http://www.oracle.com> if you need
>>>                    additional information or have any
>>>                      * questions.
>>>                      */
>>>
>>>                    /*
>>>                      * Portions Copyright (c) 2012 IBM Corporation
>>>                      */
>>>
>>>                    import javax.swing.*;
>>>
>>>                    /* @test 1.1 2012/03/15
>>>                        @bug 7154030
>>>                        @run main/manual ComponentHideShowTest.html */
>>>
>>>                    @SuppressWarnings("serial")
>>>                    public class ComponetHideShowTest extends JFrame {
>>>                         JInternalFrame internalFrame;
>>>                         JButton btn;
>>>                         JDesktopPane desktop;
>>>
>>>                         ComponetHideShowTest(String name) {
>>>                             super(name);
>>>                             desktop = new JDesktopPane();
>>>                             setContentPane(desktop);
>>>
>>>                             setSize(600, 400);
>>>                             setVisible(true);
>>>
>>>                             internalFrame = new JInternalFrame("Test
>>>             Internal Frame");
>>>                             internalFrame.setSize(100, 100);
>>>                             internalFrame.setLocation(10, 10);
>>>                             internalFrame.setVisible(true)__;
>>>                             desktop.add(internalFrame);
>>>
>>>                             btn = new JButton("OK");
>>>                             btn.setSize(100, 50);
>>>                             btn.setLocation( 300, 300);
>>>                             btn.setVisible(true);
>>>                             desktop.add(btn);
>>>
>>>                            
>>>             setDefaultCloseOperation(__JFrame.EXIT_ON_CLOSE);
>>>                         }
>>>
>>>                         @SuppressWarnings("__deprecation")
>>>                         public void runTest() throws Exception {
>>>                             Object[] options = { "Yes, I saw it",
>>>             "No, I did not
>>>                    see it!" };
>>>
>>>                             int ret =
>>>             JOptionPane.showOptionDialog(__this,
>>>                    "Do you see the internal window?",
>>>             "InternalFrmaeHideTest",
>>>                                     JOptionPane.YES_NO_OPTION,
>>>                    JOptionPane.QUESTION_MESSAGE, null,
>>>                                     options, options[1]);
>>>
>>>                             if (ret == 1 || ret ==
>>>             JOptionPane.CLOSED_OPTION) {
>>>                                 throw new Exception("Failed to
>>>             display internal
>>>                    window");
>>>                             }
>>>
>>>                             internalFrame.hide();
>>>                             btn.hide();
>>>
>>>                             ret = JOptionPane.showOptionDialog(__this,
>>>                    "Do you see the internal window?",
>>>             "InternalFrmaeHideTest",
>>>                                     JOptionPane.YES_NO_OPTION,
>>>                    JOptionPane.QUESTION_MESSAGE, null,
>>>                                     options, options[1]);
>>>
>>>                             if (ret == 0 || ret ==
>>>             JOptionPane.CLOSED_OPTION) {
>>>                                 throw new Exception("Failed to hide
>>>             internal window");
>>>                             }
>>>
>>>                             internalFrame.show();
>>>                             btn.show();
>>>
>>>                             ret = JOptionPane.showOptionDialog(__this,
>>>                    "Do you see the internal window?",
>>>             "InternalFrmaeHideTest",
>>>                                     JOptionPane.YES_NO_OPTION,
>>>                    JOptionPane.QUESTION_MESSAGE, null,
>>>                                     options, options[1]);
>>>
>>>                             if (ret == 1 || ret ==
>>>             JOptionPane.CLOSED_OPTION) {
>>>                                 throw new Exception("Failed to hide
>>>             internal window");
>>>                             }
>>>                         }
>>>
>>>                         public static void main(String[] args)
>>>             throws Exception {
>>>                             ComponetHideShowTest test = null;
>>>                             test = new
>>>             ComponetHideShowTest("__InternalFrameHideTest");
>>>                             test.runTest();
>>>                         }
>>>                    }
>>>
>>>                    And here's the patch
>>>             http://cr.openjdk.java.net/~__littlee/7154030/
>>>             <http://cr.openjdk.java.net/%7E__littlee/7154030/>
>>>             <http://cr.openjdk.java.net/%7Elittlee/7154030/>
>>>
>>>                    Can anybody please help to take a look?
>>>
>>>                    Cheers!
>>>                    - Jonathan
>>>
>>>
>>>             Best regards!
>>>             - Jonathan
>>>
>>>
>>>     Thanks a lot !
>>>
>>>     - Jonathan
>>
>>
>

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

From pavel.porvatov at oracle.com  Tue Mar 27 07:46:07 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Tue, 27 Mar 2012 18:46:07 +0400
Subject: <Swing Dev> Request for review 7155887: ComboBox does not paint
 focus correctly on GTK L&F
In-Reply-To: <4F7028D8.2000307@linux.vnet.ibm.com>
References: <4F6ACF28.5050102@linux.vnet.ibm.com> <4F6B3628.50707@oracle.com>
	<4F7028D8.2000307@linux.vnet.ibm.com>
Message-ID: <4F71D2AF.80307@oracle.com>

Hi Jonathan,

What do you think about another solution: can we set component state as 
SynthConstants.FOCUSED before paintTextBackground is invoked. Another 
solution is to set state as "focused" for ComboBox renderer like the 
following:

         if ("ComboBox.renderer".equals(c.getName())) {
             for (Component comboBoxParent = c.getParent(); 
comboBoxParent != null; comboBoxParent = comboBoxParent.getParent()) {
                 if (comboBoxParent instanceof JComboBox){
                     if(comboBoxParent.hasFocus()){
                         state |= SynthConstants.FOCUSED;
                     }
                     break;
                 }
             }
         }
without other changes in GTKPainter.java (actually there is some problem 
with "interiorFocus", but it could be resolved....)

See also my answers below.
> Hi Pavel,
>
> Thanks for review, here's the new patch and my answers are inlined.
> http://cr.openjdk.java.net/~luchsh/7155887_2/
>
> On 03/22/2012 10:24 PM, Pavel Porvatov wrote:
>> Hi Jonathan,
>>> Hi Swing-dev,
>>>
>>> ComboBox on linux GTK L&F does not works as gtk native applications, 
>>> when get focused, the apperance of Java ComboBox remains unchanged 
>>> but native GTK ComboBox control will have a outline to indicate it 
>>> has got focused.
>>>
>>> The problem seems similar to bug
>>> 6947671 ( http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6947671),
>>> except that I did not reproduced the problem on Nimbus L&F, so 
>>> another bug
>>> 7155887 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7155887)
>>> was created for this issue,
>>>
>>> And here's the proposed patch to fix this problem,
>>> http://cr.openjdk.java.net/~luchsh/7155887/
>>>
>>> Could anybody please help to take a look?
>> I have several comments about the patch:
>>
>> 1. "c.getName().equals("ComboBox.renderer")": I think we can get NPE 
>> here
> Yes, I've changed it to
>
> "ComboBox.renderer".equals(c.getName())
>
>>
>> 2.
>> +            for (Component comboBoxParent = c.getParent(); 
>> comboBoxParent != null; comboBoxParent = comboBoxParent
>> +                    .getParent()) {
>> +                if (comboBoxParent instanceof JComboBox
>> + && comboBoxParent.hasFocus()) {
>> +                    comboBoxFocused = true;
>> +                }
>> +            }
>>
>> I'm not sure we should do such deep parent investigation. Why don't 
>> you check first parent only?
>>
> javax.swing.CellRendererPane is inserted between the component and 
> renderer, so if check only the first parent, it will retrieve a 
> CellRendererPane object instead of JComboBox component. In the new 
> patch, I added a break when JComboBox is encounterred so to make the 
> effect similar to the first-parent-only approach.
I found out the following code (see 
com.sun.java.swing.plaf.gtk.GTKPainter#paintLabelBackground):
         if (c instanceof ListCellRenderer &&
                  container != null &&
                  container.getParent() instanceof JComboBox ) {
             ...
         }
I think we should use the same pattern
>
>> 3. "if (ENGINE.paintCachedImage(g, x, y, w, h, id, state) && 
>> !comboBoxFocused)"
>> If you are going to ignore ENGINE.paintCachedImage when 
>> comboBoxFocused, then there is no need to invoke it at all
>>
> yes, in the new patch I've changed the order of these two checks.
>> 4. "if (comboBoxFocused || focusSize > 0)"
>> I'm not sure we should paint focus if focusSize == 0
>>
> I think there's no need to paint the focus if focusSize ==0, since the 
> focus width and height arguements passed to JNI method 
> native_paint_focus() will both be zero.
That's what I meant! (may be my phrase was not clear enough)
Your condition "if (comboBoxFocused || focusSize > 0)" allows to paint 
focus even if focusSize == 0...

Regards, Pavel

From pavel.porvatov at oracle.com  Tue Mar 27 08:58:49 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Tue, 27 Mar 2012 19:58:49 +0400
Subject: <Swing Dev> Review request for 7154030:
 java.awt.Component.hide() does not repaint parent container
In-Reply-To: <4F717064.9030803@linux.vnet.ibm.com>
References: <CAC-GWLe8d6mR+tyoEKOuSb4A8Caun-9_NcTePV7+i0McJjsO+w@mail.gmail.com>
	<4F67511F.5040109@oracle.com>
	<CAC-GWLenUzrra+P3_U3mQuho34Oj3OXRE+ievM44WarNYS4G7w@mail.gmail.com>
	<4F6845B3.1060506@oracle.com>
	<CAC-GWLcmkA_tbydcKLfvor_nGTAOiS1xboC0Ua3wiXou=d7vOw@mail.gmail.com>
	<4F688E2E.9080508@oracle.com>
	<CAC-GWLcHxYxnOJPmmv0j2GOtahHwJJqntK43367R5YJi8xZJNA@mail.gmail.com>
	<4F707153.5060803@oracle.com> <4F717064.9030803@linux.vnet.ibm.com>
Message-ID: <4F71E3B9.9090103@oracle.com>

Hi Jonathan,
> Hello Pavel,
>
> Here's the updated patch and automatic test for bug 7154030, could you 
> please take another look?
> http://cr.openjdk.java.net/~luchsh/7154030_2/
I have several comments:

1. What about the following comment from Artem:
"Even if we accept the change in JComponent.hide(), we should then 
override show() as well (lightweight component may be non-opaque, so we 
should repaint from its parent)"
?

2. Could you please clarify your changes in setVisible method?
As I see in comments
             // Some (all should) LayoutManagers do not consider components
             // that are not visible. As such we need to revalidate when the
             // visible bit changes.
             revalidate();
but now this code is invoked only for setVisible(true)

3. Could you please follow our code conventions?  (see 
http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-141388.html#475)

4. Your test is not automatic one. I think you could use 
java.awt.Robot#createScreenCapture and analyze result of hide method.

Regards, Pavel
>
> Thanks and best regards
> - Jonathan Lu
>
> On 03/26/2012 09:38 PM, Pavel Porvatov wrote:
>> Hi Jonathan,
>>> Hi Pavel,
>>>
>>> Thanks for your explanation.
>>>
>>> But this bug affects almost all Swing components, hide()'s presence 
>>> also helps to maintain backward compatibility, so is it possible to 
>>> put a fix in JComponent to help all the potential affected 
>>> applications to work correctly? 
>> Of course that's possible. Do you have final version of the fix? 
>> Please don't forget write an automatic test.
>>> if not, is it there any sunset plan for these deprecated APIs?
>> I don't now such plans.
>>
>> Regards, Pavel
>>
>> P.S. I removed <AWT Dev>, it seems only Swing will be affected in 
>> this fix
>>> Thanks and best regards!
>>>
>>> - Jonathan
>>>
>>> 2012/3/20 Pavel Porvatov <pavel.porvatov at oracle.com 
>>> <mailto:pavel.porvatov at oracle.com>>
>>>
>>>     Hi Jonathan,
>>>>     Hi Artem,
>>>>
>>>>     2012/3/20 Artem Ananiev <artem.ananiev at oracle.com
>>>>     <mailto:artem.ananiev at oracle.com>>
>>>>
>>>>         Hi, Jonathan,
>>>>
>>>>         I'm adding swing-dev to CC as we now consider changing
>>>>         Swing code.
>>>>
>>>>         What you propose sounds technically reasonable, but I don't
>>>>         think it is worth doing anyway as show() and hide() have
>>>>         been deprecated for years now.
>>>>
>>>>
>>>>     Although show() and hide() have been deprecated for years, in
>>>>     my opinion supporting these APIs will still benefit many
>>>>     applications and convince users that Java still has got strong
>>>>     backward compatibility :D. Any ideas from Swing group?
>>>     I don't see why the words "backward compatibility" are here.
>>>     There is a bug in deprecated methods "show" and "hide" (I've
>>>     checked that jdk5 has the same problem), and that's one
>>>     additional reason to use setVisible(). I agree with Artem that
>>>     fixing deprecated API is not a high priority task (but we should
>>>     keep backward compatibility, of course). I also think, that "to
>>>     leave all as is" is a good decision for the described problem
>>>
>>>     Regards, Pavel
>>>
>>>>
>>>>
>>>>         Even if we accept the change in JComponent.hide(), we
>>>>         should then override show() as well (lightweight component
>>>>         may be non-opaque, so we should repaint from its parent),
>>>>         so there will be code duplication. This is one more reason
>>>>         to leave all as is.
>>>>
>>>>
>>>>     Yes, I noticed that code duplication too and am trying to make
>>>>     a more compact patch for this problem.
>>>>
>>>>         This is my personal opinion, I'm not a Swing expert,
>>>>         though. Let anyone from the Swing group comment.
>>>>
>>>>         Thanks,
>>>>
>>>>         Artem
>>>>
>>>>         On 3/20/2012 12:28 PM, Jonathan Lu wrote:
>>>>
>>>>             Hi Artem,
>>>>
>>>>             Thanks for your time.
>>>>
>>>>             2012/3/19 Artem Ananiev <artem.ananiev at oracle.com
>>>>             <mailto:artem.ananiev at oracle.com>
>>>>             <mailto:artem.ananiev at oracle.com
>>>>             <mailto:artem.ananiev at oracle.com>>>
>>>>
>>>>                Hi, Jonathan,
>>>>
>>>>                given the code in java.awt.Component, your statement
>>>>             about
>>>>                difference between hide() and setVisible(false)
>>>>             looks pretty strange
>>>>                to me. Indeed, here is the implementation:
>>>>
>>>>
>>>>
>>>>                    public void show(boolean b) {
>>>>                        if (b) {
>>>>                            show();
>>>>                        } else {
>>>>                            hide();
>>>>                        }
>>>>                    }
>>>>
>>>>                and
>>>>
>>>>                    public void setVisible(boolean b) {
>>>>                        show(b);
>>>>                    }
>>>>
>>>>                In JComponent the latter method is overridden and
>>>>             adds exactly what
>>>>                you propose: parent.repaint(). This addition makes
>>>>             sense for
>>>>                lightweight components (e.g. Swing), but heavyweight
>>>>             AWT components
>>>>                shouldn't require this: repaint request is sent from
>>>>             the native system.
>>>>
>>>>
>>>>             Yes, lightweight and  heavyweight components differ in
>>>>             painting. The
>>>>             original test case only works for the conditions of
>>>>             lightweight
>>>>             components, with another test case for heavyweight
>>>>             components, I found
>>>>             that the problem could not be reproduced on AWT any
>>>>             more. I think the
>>>>             change is only applicable for Swing components, so how
>>>>             about repaint in
>>>>             JComponent.hide() like this?
>>>>
>>>>             diff -r cdbb33303ea3
>>>>             src/share/classes/javax/swing/JComponent.java
>>>>             --- a/src/share/classes/javax/swing/JComponent.java  
>>>>              Wed Mar 14
>>>>             13:50:37 2012 -0700 <tel:2012%20-0700> <tel:2012%20-0700>
>>>>             +++ b/src/share/classes/javax/swing/JComponent.java  
>>>>              Tue Mar 20
>>>>             16:24:09 2012 +0800
>>>>             @@ -5237,6 +5237,16 @@
>>>>                      }
>>>>                  }
>>>>
>>>>             +    public void hide() {
>>>>             +        super.hide();
>>>>             +        Container parent = getParent();
>>>>             +        if (parent != null) {
>>>>             +            Rectangle r = getBounds();
>>>>             +            parent.repaint(r.x, r.y, r.width, r.height);
>>>>             +            parent.invalidate();
>>>>             +        }
>>>>             +    }
>>>>             +
>>>>                  /**
>>>>                   * Returns whether or not the region of the
>>>>             specified component is
>>>>                   * obscured by a sibling.
>>>>
>>>>
>>>>
>>>>                Thanks,
>>>>
>>>>                Artem
>>>>
>>>>
>>>>                On 3/15/2012 12:24 PM, Jonathan Lu wrote:
>>>>
>>>>                    Hi awt-dev,
>>>>
>>>>                    java.awt.Component.hide() was declared as
>>>>             deprecation and
>>>>                    replaced by
>>>>                    setVisible(boolean), but in my tests, it does
>>>>             not works in the
>>>>                    same way
>>>>                    as setVisible(false). The reason of this failure
>>>>             is that
>>>>                    java.awt.Component.hide() does not repaint the
>>>>             special area it
>>>>                    used to
>>>>                    taken of parent container. Although this is
>>>>             deprecated method,
>>>>                    it may
>>>>                    still valuable for customers due to
>>>>             compatibility reason. Bug
>>>>                    7154030
>>>>                    created for this issue.
>>>>
>>>>                    Here's a simple test case to demonstrate this
>>>>             problem.
>>>>
>>>>                    /*
>>>>                      * Copyright (c) 2012 Oracle and/or its
>>>>             affiliates. All rights
>>>>                    reserved.
>>>>                      * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR
>>>>             THIS FILE HEADER.
>>>>                      *
>>>>                      * This code is free software; you can
>>>>             redistribute it and/or
>>>>                    modify it
>>>>                      * under the terms of the GNU General Public
>>>>             License version 2
>>>>                    only, as
>>>>                      * published by the Free Software Foundation.
>>>>                      *
>>>>                      * This code is distributed in the hope that it
>>>>             will be useful, but
>>>>                    WITHOUT
>>>>                      * ANY WARRANTY; without even the implied
>>>>             warranty of
>>>>                    MERCHANTABILITY or
>>>>                      * FITNESS FOR A PARTICULAR PURPOSE.  See the
>>>>             GNU General
>>>>                    Public License
>>>>                      * version 2 for more details (a copy is
>>>>             included in the
>>>>                    LICENSE file that
>>>>                      * accompanied this code).
>>>>                      *
>>>>                      * You should have received a copy of the GNU
>>>>             General Public
>>>>                    License
>>>>                    version
>>>>                      * 2 along with this work; if not, write to the
>>>>             Free Software
>>>>                    Foundation,
>>>>                      * Inc., 51 Franklin St, Fifth Floor, Boston,
>>>>             MA 02110-1301 USA.
>>>>                      *
>>>>                      * Please contact Oracle, 500 Oracle Parkway,
>>>>             Redwood Shores,
>>>>                    CA 94065 USA
>>>>                      * or visit www.oracle.com
>>>>             <http://www.oracle.com> <http://www.oracle.com> if you need
>>>>                    additional information or have any
>>>>                      * questions.
>>>>                      */
>>>>
>>>>                    /*
>>>>                      * Portions Copyright (c) 2012 IBM Corporation
>>>>                      */
>>>>
>>>>                    import javax.swing.*;
>>>>
>>>>                    /* @test 1.1 2012/03/15
>>>>                        @bug 7154030
>>>>                        @run main/manual ComponentHideShowTest.html */
>>>>
>>>>                    @SuppressWarnings("serial")
>>>>                    public class ComponetHideShowTest extends JFrame {
>>>>                         JInternalFrame internalFrame;
>>>>                         JButton btn;
>>>>                         JDesktopPane desktop;
>>>>
>>>>                         ComponetHideShowTest(String name) {
>>>>                             super(name);
>>>>                             desktop = new JDesktopPane();
>>>>                             setContentPane(desktop);
>>>>
>>>>                             setSize(600, 400);
>>>>                             setVisible(true);
>>>>
>>>>                             internalFrame = new
>>>>             JInternalFrame("Test Internal Frame");
>>>>                             internalFrame.setSize(100, 100);
>>>>                             internalFrame.setLocation(10, 10);
>>>>                             internalFrame.setVisible(true)__;
>>>>                             desktop.add(internalFrame);
>>>>
>>>>                             btn = new JButton("OK");
>>>>                             btn.setSize(100, 50);
>>>>                             btn.setLocation( 300, 300);
>>>>                             btn.setVisible(true);
>>>>                             desktop.add(btn);
>>>>
>>>>                            
>>>>             setDefaultCloseOperation(__JFrame.EXIT_ON_CLOSE);
>>>>                         }
>>>>
>>>>                         @SuppressWarnings("__deprecation")
>>>>                         public void runTest() throws Exception {
>>>>                             Object[] options = { "Yes, I saw it",
>>>>             "No, I did not
>>>>                    see it!" };
>>>>
>>>>                             int ret =
>>>>             JOptionPane.showOptionDialog(__this,
>>>>                    "Do you see the internal window?",
>>>>             "InternalFrmaeHideTest",
>>>>                                     JOptionPane.YES_NO_OPTION,
>>>>                    JOptionPane.QUESTION_MESSAGE, null,
>>>>                                     options, options[1]);
>>>>
>>>>                             if (ret == 1 || ret ==
>>>>             JOptionPane.CLOSED_OPTION) {
>>>>                                 throw new Exception("Failed to
>>>>             display internal
>>>>                    window");
>>>>                             }
>>>>
>>>>                             internalFrame.hide();
>>>>                             btn.hide();
>>>>
>>>>                             ret = JOptionPane.showOptionDialog(__this,
>>>>                    "Do you see the internal window?",
>>>>             "InternalFrmaeHideTest",
>>>>                                     JOptionPane.YES_NO_OPTION,
>>>>                    JOptionPane.QUESTION_MESSAGE, null,
>>>>                                     options, options[1]);
>>>>
>>>>                             if (ret == 0 || ret ==
>>>>             JOptionPane.CLOSED_OPTION) {
>>>>                                 throw new Exception("Failed to hide
>>>>             internal window");
>>>>                             }
>>>>
>>>>                             internalFrame.show();
>>>>                             btn.show();
>>>>
>>>>                             ret = JOptionPane.showOptionDialog(__this,
>>>>                    "Do you see the internal window?",
>>>>             "InternalFrmaeHideTest",
>>>>                                     JOptionPane.YES_NO_OPTION,
>>>>                    JOptionPane.QUESTION_MESSAGE, null,
>>>>                                     options, options[1]);
>>>>
>>>>                             if (ret == 1 || ret ==
>>>>             JOptionPane.CLOSED_OPTION) {
>>>>                                 throw new Exception("Failed to hide
>>>>             internal window");
>>>>                             }
>>>>                         }
>>>>
>>>>                         public static void main(String[] args)
>>>>             throws Exception {
>>>>                             ComponetHideShowTest test = null;
>>>>                             test = new
>>>>             ComponetHideShowTest("__InternalFrameHideTest");
>>>>                             test.runTest();
>>>>                         }
>>>>                    }
>>>>
>>>>                    And here's the patch
>>>>             http://cr.openjdk.java.net/~__littlee/7154030/
>>>>             <http://cr.openjdk.java.net/%7E__littlee/7154030/>
>>>>             <http://cr.openjdk.java.net/%7Elittlee/7154030/>
>>>>
>>>>                    Can anybody please help to take a look?
>>>>
>>>>                    Cheers!
>>>>                    - Jonathan
>>>>
>>>>
>>>>             Best regards!
>>>>             - Jonathan
>>>>
>>>>
>>>>     Thanks a lot !
>>>>
>>>>     - Jonathan
>>>
>>>
>>
>

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

From alexandr.scherbatiy at oracle.com  Wed Mar 28 08:36:17 2012
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 28 Mar 2012 19:36:17 +0400
Subject: <Swing Dev> Review request for 7093156: NLS: Please change the
 mnemonic assignment system to avoid translation issue (Swing files)
Message-ID: <4F732FF1.3060908@oracle.com>


bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7093156
webrev: http://cr.openjdk.java.net/~alexsch/7093156/webrev.00/

The properties in the swing resources files are changed from the
   xxxText=ABC
   xxxMnemonic=B
to
   xxxTextAndMnemonic=A&BC

where Text suffix can be one of the following: "NameText", "nameText", 
"Text" and  "Title"


The hashmap in UIDefaults class is extended to return the correct values 
for the keys xxxText and xxxMnemonic from the stored xxxTextAndMnemonic 
string.

There is no html text in the swing resource files so this case is not 
considered.
The fix covers only the swing resource files in the JDK:
   src/share/classes/com/sun/swing/internal/plaf
   src/share/classes/com/sun/java/swing/plaf

The demo resources will be fixed in the separated issue.

Thanks,
Alexandr.


From pavel.porvatov at oracle.com  Thu Mar 29 02:19:22 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Thu, 29 Mar 2012 13:19:22 +0400
Subject: <Swing Dev> Review request for 7093156: NLS: Please change the
 mnemonic assignment system to avoid translation issue (Swing files)
In-Reply-To: <4F732FF1.3060908@oracle.com>
References: <4F732FF1.3060908@oracle.com>
Message-ID: <4F74291A.5020702@oracle.com>

Hi Alexander,

I have several questions about the patch.

File TextAndMnemonicHashMap:
1. MNEMONIC_SUFFIX[] = {"Mnemonic", "mnemonic", "Mnemonic", "Mnemonic",}
what's the reason have three "Mnemonic" values?

2. TEXT_SUFFIX[] = {"NameText", "nameText", "Text", "Title"}
What is the reason to have "NameText", "nameText". It looks there is no 
need in that because that's a particular case of "Text"

3. Could you pleas use "for each" loops (if possible), they are more 
compact and readable

4. Integer.toString((int) Character.toUpperCase(c)) looks a little bit 
tricky. Can we use something like this:
String.valueOf(Character.toUpperCase(c)) ?

5. What is the reason to have the second loop? Can we just check
stringKey.endsWith("mnemonic") || stringKey.endsWith("Mnemonic")?

Regards, Pavel

> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7093156
> webrev: http://cr.openjdk.java.net/~alexsch/7093156/webrev.00/
>
> The properties in the swing resources files are changed from the
>   xxxText=ABC
>   xxxMnemonic=B
> to
>   xxxTextAndMnemonic=A&BC
>
> where Text suffix can be one of the following: "NameText", "nameText", 
> "Text" and  "Title"
>
>
> The hashmap in UIDefaults class is extended to return the correct 
> values for the keys xxxText and xxxMnemonic from the stored 
> xxxTextAndMnemonic string.
>
> There is no html text in the swing resource files so this case is not 
> considered.
> The fix covers only the swing resource files in the JDK:
>   src/share/classes/com/sun/swing/internal/plaf
>   src/share/classes/com/sun/java/swing/plaf
>
> The demo resources will be fixed in the separated issue.
>
> Thanks,
> Alexandr.
>


From alexandr.scherbatiy at oracle.com  Thu Mar 29 03:25:43 2012
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 29 Mar 2012 14:25:43 +0400
Subject: <Swing Dev> Review request for 7093156: NLS: Please change the
 mnemonic assignment system to avoid translation issue (Swing files)
In-Reply-To: <4F74291A.5020702@oracle.com>
References: <4F732FF1.3060908@oracle.com> <4F74291A.5020702@oracle.com>
Message-ID: <4F7438A7.2040904@oracle.com>

On 3/29/2012 1:19 PM, Pavel Porvatov wrote:
> Hi Alexander,
>
> I have several questions about the patch.
>
> File TextAndMnemonicHashMap:
> 1. MNEMONIC_SUFFIX[] = {"Mnemonic", "mnemonic", "Mnemonic", "Mnemonic",}
> what's the reason have three "Mnemonic" values?
>
> 2. TEXT_SUFFIX[] = {"NameText", "nameText", "Text", "Title"}
> What is the reason to have "NameText", "nameText". It looks there is 
> no need in that because that's a particular case of "Text"

      The reason to have two arrays is because there are several 
patterns that are used for the text and mnemonic declaration.
      They are (xxxNameText, xxxMnemonic), (xxx.nameText, 
xxx.mnemonic),(xxxText, xxxMnemonic) and (xxxTitle, xxxMnemonic).

>
> 3. Could you pleas use "for each" loops (if possible), they are more 
> compact and readable

     In the second loop the i index is used to add a TEXT_SUFFIX after 
cutting a MNEMONIC_SUFFIX.
     So the first loop can use the "for each" loop.

    May be it is better to have a TextAndMnemonic class that holds 
values for the corresponded text and mnemonic suffixes?

>
> 4. Integer.toString((int) Character.toUpperCase(c)) looks a little bit 
> tricky. Can we use something like this:
> String.valueOf(Character.toUpperCase(c)) ?
      For example  there is the property:
        ColorChooser.rgbRedTextAndMnemonic=Re&d
     The code that needs a mnemonic expect that it gets the integer 
value |68| in the string instead of  char D.
     So the right mnemonic value should be
        ColorChooser.rgbRedMnemonic=68

>
> 5. What is the reason to have the second loop? 
      The first loop checks is it a request to a text value. The second 
loop checks is it a request to a mnemonic value.

> Can we just check
> stringKey.endsWith("mnemonic") || stringKey.endsWith("Mnemonic")?
      There might be collisions. It is better to explicitly check that a 
text suffix from a pattern have the certain suffix from the mnemonic 
pattern.

    Thanks,
    Alexandr.

>
> Regards, Pavel
>
>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7093156
>> webrev: http://cr.openjdk.java.net/~alexsch/7093156/webrev.00/
>>
>> The properties in the swing resources files are changed from the
>>   xxxText=ABC
>>   xxxMnemonic=B
>> to
>>   xxxTextAndMnemonic=A&BC
>>
>> where Text suffix can be one of the following: "NameText", 
>> "nameText", "Text" and  "Title"
>>
>>
>> The hashmap in UIDefaults class is extended to return the correct 
>> values for the keys xxxText and xxxMnemonic from the stored 
>> xxxTextAndMnemonic string.
>>
>> There is no html text in the swing resource files so this case is not 
>> considered.
>> The fix covers only the swing resource files in the JDK:
>>   src/share/classes/com/sun/swing/internal/plaf
>>   src/share/classes/com/sun/java/swing/plaf
>>
>> The demo resources will be fixed in the separated issue.
>>
>> Thanks,
>> Alexandr.
>>
>


From pavel.porvatov at oracle.com  Thu Mar 29 06:28:35 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Thu, 29 Mar 2012 17:28:35 +0400
Subject: <Swing Dev> Review request for 7093156: NLS: Please change the
 mnemonic assignment system to avoid translation issue (Swing files)
In-Reply-To: <4F7438A7.2040904@oracle.com>
References: <4F732FF1.3060908@oracle.com> <4F74291A.5020702@oracle.com>
	<4F7438A7.2040904@oracle.com>
Message-ID: <4F746383.2050204@oracle.com>

Hi Alexander,
> On 3/29/2012 1:19 PM, Pavel Porvatov wrote:
>> Hi Alexander,
>>
>> I have several questions about the patch.
>>
>> File TextAndMnemonicHashMap:
>> 1. MNEMONIC_SUFFIX[] = {"Mnemonic", "mnemonic", "Mnemonic", "Mnemonic",}
>> what's the reason have three "Mnemonic" values?
>>
>> 2. TEXT_SUFFIX[] = {"NameText", "nameText", "Text", "Title"}
>> What is the reason to have "NameText", "nameText". It looks there is 
>> no need in that because that's a particular case of "Text"
>
>      The reason to have two arrays is because there are several 
> patterns that are used for the text and mnemonic declaration.
>      They are (xxxNameText, xxxMnemonic), (xxx.nameText, 
> xxx.mnemonic),(xxxText, xxxMnemonic) and (xxxTitle, xxxMnemonic).
I'll try explain what I meant below...

Lets take the first loop:
+                for (int i = 0; i < TEXT_SUFFIX.length; i++) {
+                    String suffix = TEXT_SUFFIX[i];
+                    if (stringKey.endsWith(suffix)) {
+                        value = super.get(stringKey + AND_MNEMONIC);
+                        if (value != null) {
+                            return getText(value.toString());
+                        }
+                    }
+                }
and lets stringKey = BlaBlaBlaNameText. Then you'll invoke super.get() 
twice and the loop will have 4 iterations. So if you will use for the 
first loop only "Text", "Title" you will have only 2 loop iterations and 
no unnecessary super.get() invocations.

About "They are (xxxNameText, xxxMnemonic), (xxx.nameText, 
xxx.mnemonic),(xxxText, xxxMnemonic) and (xxxTitle, xxxMnemonic)": can 
we don't use "Name" for pair (xxxNameText, xxxMnemonic), like 
xxxTextAndMnemonic? For consistency we could  use for pair 
(xxx.nameText, xxx.mnemonic) xxx.textAndMnemonic...

>
>>
>> 3. Could you pleas use "for each" loops (if possible), they are more 
>> compact and readable
>
>     In the second loop the i index is used to add a TEXT_SUFFIX after 
> cutting a MNEMONIC_SUFFIX.
>     So the first loop can use the "for each" loop.
Yep! That's what I meant...
>
>    May be it is better to have a TextAndMnemonic class that holds 
> values for the corresponded text and mnemonic suffixes?
>
>>
>> 4. Integer.toString((int) Character.toUpperCase(c)) looks a little 
>> bit tricky. Can we use something like this:
>> String.valueOf(Character.toUpperCase(c)) ?
>      For example  there is the property:
>        ColorChooser.rgbRedTextAndMnemonic=Re&d
>     The code that needs a mnemonic expect that it gets the integer 
> value |68| in the string instead of  char D.
>     So the right mnemonic value should be
>        ColorChooser.rgbRedMnemonic=68
>
Ok. BTW: I think "return null" will be more correct in the getMnemonic 
method
>>
>> 5. What is the reason to have the second loop? 
>      The first loop checks is it a request to a text value. The second 
> loop checks is it a request to a mnemonic value.
>
>> Can we just check
>> stringKey.endsWith("mnemonic") || stringKey.endsWith("Mnemonic")?
>      There might be collisions. It is better to explicitly check that 
> a text suffix from a pattern have the certain suffix from the mnemonic 
> pattern.

Regards, Pavel
>
>    Thanks,
>    Alexandr.
>
>>
>> Regards, Pavel
>>
>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7093156
>>> webrev: http://cr.openjdk.java.net/~alexsch/7093156/webrev.00/
>>>
>>> The properties in the swing resources files are changed from the
>>>   xxxText=ABC
>>>   xxxMnemonic=B
>>> to
>>>   xxxTextAndMnemonic=A&BC
>>>
>>> where Text suffix can be one of the following: "NameText", 
>>> "nameText", "Text" and  "Title"
>>>
>>>
>>> The hashmap in UIDefaults class is extended to return the correct 
>>> values for the keys xxxText and xxxMnemonic from the stored 
>>> xxxTextAndMnemonic string.
>>>
>>> There is no html text in the swing resource files so this case is 
>>> not considered.
>>> The fix covers only the swing resource files in the JDK:
>>>   src/share/classes/com/sun/swing/internal/plaf
>>>   src/share/classes/com/sun/java/swing/plaf
>>>
>>> The demo resources will be fixed in the separated issue.
>>>
>>> Thanks,
>>> Alexandr.
>>>
>>
>


From alexlamsl at gmail.com  Thu Mar 29 12:48:51 2012
From: alexlamsl at gmail.com (Alex Lam S.L.)
Date: Thu, 29 Mar 2012 20:48:51 +0100
Subject: <Swing Dev> JSeparator rendered incorrectly on Windows 7
Message-ID: <CAGpACNtx4nJZ9ZMYyKphb1AvCMZtyvaeW7C9ak688hbKRYeOKw@mail.gmail.com>

Hi there,

I noticed that in some cases JSeparator would render differently (see
attached photo - first one from the top, left window).

It is repeatable - I can quit and re-run the app and the same
JSeparator would be wrong. Curiously, I use the preview feature from
NetBeans for the project code which generates this window, and the
problem does not appear there.


Confused,
Alex.

---------------

Microsoft Windows [Version 6.1.7601]

java version "1.7.0_02"
Java(TM) SE Runtime Environment (build 1.7.0_02-b13)
Java HotSpot(TM) 64-Bit Server VM (build 22.0-b10, mixed mode)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: JSeparator.png
Type: image/png
Size: 70872 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20120329/5849201a/JSeparator-0001.png 

From alexandr.scherbatiy at oracle.com  Fri Mar 30 01:56:20 2012
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 30 Mar 2012 12:56:20 +0400
Subject: <Swing Dev> Review request for 7093156: NLS: Please change the
 mnemonic assignment system to avoid translation issue (Swing files)
In-Reply-To: <4F746383.2050204@oracle.com>
References: <4F732FF1.3060908@oracle.com> <4F74291A.5020702@oracle.com>
	<4F7438A7.2040904@oracle.com> <4F746383.2050204@oracle.com>
Message-ID: <4F757534.3040802@oracle.com>


webrev: http://cr.openjdk.java.net/~alexsch/7093156/webrev.01/

There is the updated webrev  which is used the TextAndMnemonicPattern 
class and separate getTextProperty and getMnemonicProperty methods. The 
getMnemonicFromProperty returns null in case if a mnemonic has not been 
found.

  See other comments inline...

On 3/29/2012 5:28 PM, Pavel Porvatov wrote:
> I'll try explain what I meant below...
>
> Lets take the first loop:
> +                for (int i = 0; i < TEXT_SUFFIX.length; i++) {
> +                    String suffix = TEXT_SUFFIX[i];
> +                    if (stringKey.endsWith(suffix)) {
> +                        value = super.get(stringKey + AND_MNEMONIC);
> +                        if (value != null) {
> +                            return getText(value.toString());
> +                        }
> +                    }
> +                }
> and lets stringKey = BlaBlaBlaNameText. Then you'll invoke super.get() 
> twice and the loop will have 4 iterations. So if you will use for the 
> first loop only "Text", "Title" you will have only 2 loop iterations 
> and no unnecessary super.get() invocations.

   I have added the TextAndMnemonicPattern class and updated the code to 
use the following patterns:
   ( texts: { "NameText", "Text", "Title"} , mnemonic: "Mnemonic")
   ( texts: { "nameText" } , mnemonic: "mnemonic")

   Now the "for each" loop is used and for each mnemonic there is only 
one iteration of the text.

>
> About "They are (xxxNameText, xxxMnemonic), (xxx.nameText, 
> xxx.mnemonic),(xxxText, xxxMnemonic) and (xxxTitle, xxxMnemonic)": can 
> we don't use "Name" for pair (xxxNameText, xxxMnemonic), like 
> xxxTextAndMnemonic? For consistency we could  use for pair 
> (xxx.nameText, xxx.mnemonic) xxx.textAndMnemonic...

   1)   There are real collisions if we will use the same suffix like 
xxx.textAndMnemonic for all properties. For example see the gtk.properties:
    FileChooser.renameFileErrorTitle=Error
    FileChooser.renameFileErrorText=Error renaming file "{0}" to "{1}"

   Changing it to the same suffix will lead to:
      FileChooser.renameFileError.textAndMnemonic=Error
      FileChooser.renameFileError.textAndMnemonic=Error renaming file 
"{0}" to "{1}"

    So one value will be lost.

   2)  We really need to check all these text suffixes.

     There are 3 examples from the swing property files:
      ColorChooser.hsvNameText=HSV
      ColorChooser.hsvMnemonic=72
      FileChooser.helpButtonText=Help
      FileChooser.helpButtonMnemonic=72
      GTKColorChooserPanel.nameText=GTK Color Chooser
      GTKColorChooserPanel.mnemonic=71

     which are converted to the new format:
     FileChooser.helpButtonTextAndMnemonic=&Help
     ColorChooser.hsvNameTextAndMnemonic=&HSV
     GTKColorChooserPanel.nameTextAndMnemonic=&GTK Color Chooser

      Now on the left side there are requests and on the right side are 
our actions:
         ColorChooser.hsvNameText  |  check that it is request to the 
text (has NameText suffix) and convert to new format 
ColorChooser.hsvNameTextAndMnemonic (add AndMnemonic  suffix)
         GTKColorChooserPanel.nameText | check that it is request to the 
text (has nameText) and convert to new format 
GTKColorChooserPanel.nameTextAndMnemonicadd AndMnemonic  suffix)
         FileChooser.helpButtonMnemonic | check that it is a request to 
the mnemonic (has Mnemonic  suffix) and convert to new format (remove 
Mnemonic suffix and add TextAndMnemonic suffix)
         GTKColorChooserPanel.mnemonic | check that it is a request to 
the mnemonic (has mnemonic  suffix) and convert to new format (remove 
mnemonic suffix and add nameTextAndMnemonic suffix)

     The suffixes for the text can be Text and Title as well.
     So the "NameText", "Text", "Title" and "nameText" suffixes are 
already used in swing components and their unification requires to 
updating a lot of java code.
>
>>
>>>
>>> 3. Could you pleas use "for each" loops (if possible), they are more 
>>> compact and readable
>>
>>     In the second loop the i index is used to add a TEXT_SUFFIX after 
>> cutting a MNEMONIC_SUFFIX.
>>     So the first loop can use the "for each" loop.
> Yep! That's what I meant...
>>
>>    May be it is better to have a TextAndMnemonic class that holds 
>> values for the corresponded text and mnemonic suffixes?
>>
>>>
>>> 4. Integer.toString((int) Character.toUpperCase(c)) looks a little 
>>> bit tricky. Can we use something like this:
>>> String.valueOf(Character.toUpperCase(c)) ?
>>      For example  there is the property:
>>        ColorChooser.rgbRedTextAndMnemonic=Re&d
>>     The code that needs a mnemonic expect that it gets the integer 
>> value |68| in the string instead of  char D.
>>     So the right mnemonic value should be
>>        ColorChooser.rgbRedMnemonic=68
>>
> Ok. BTW: I think "return null" will be more correct in the getMnemonic 
> method

     Updated the method to return null if a mnemonic has not been found.

    Thanks,
   Alexandr.

>>>
>>> 5. What is the reason to have the second loop? 
>>      The first loop checks is it a request to a text value. The 
>> second loop checks is it a request to a mnemonic value.
>>
>>> Can we just check
>>> stringKey.endsWith("mnemonic") || stringKey.endsWith("Mnemonic")?
>>      There might be collisions. It is better to explicitly check that 
>> a text suffix from a pattern have the certain suffix from the 
>> mnemonic pattern.
>
> Regards, Pavel
>>
>>    Thanks,
>>    Alexandr.
>>
>>>
>>> Regards, Pavel
>>>
>>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7093156
>>>> webrev: http://cr.openjdk.java.net/~alexsch/7093156/webrev.00/
>>>>
>>>> The properties in the swing resources files are changed from the
>>>>   xxxText=ABC
>>>>   xxxMnemonic=B
>>>> to
>>>>   xxxTextAndMnemonic=A&BC
>>>>
>>>> where Text suffix can be one of the following: "NameText", 
>>>> "nameText", "Text" and  "Title"
>>>>
>>>>
>>>> The hashmap in UIDefaults class is extended to return the correct 
>>>> values for the keys xxxText and xxxMnemonic from the stored 
>>>> xxxTextAndMnemonic string.
>>>>
>>>> There is no html text in the swing resource files so this case is 
>>>> not considered.
>>>> The fix covers only the swing resource files in the JDK:
>>>>   src/share/classes/com/sun/swing/internal/plaf
>>>>   src/share/classes/com/sun/java/swing/plaf
>>>>
>>>> The demo resources will be fixed in the separated issue.
>>>>
>>>> Thanks,
>>>> Alexandr.
>>>>
>>>
>>
>



From pavel.porvatov at oracle.com  Fri Mar 30 02:24:55 2012
From: pavel.porvatov at oracle.com (Pavel Porvatov)
Date: Fri, 30 Mar 2012 13:24:55 +0400
Subject: <Swing Dev> JSeparator rendered incorrectly on Windows 7
In-Reply-To: <CAGpACNtx4nJZ9ZMYyKphb1AvCMZtyvaeW7C9ak688hbKRYeOKw@mail.gmail.com>
References: <CAGpACNtx4nJZ9ZMYyKphb1AvCMZtyvaeW7C9ak688hbKRYeOKw@mail.gmail.com>
Message-ID: <4F757BE7.5040800@oracle.com>

Hi Alex,

Can you sent a small separated test? I used SwingSet2 demo with the same 
Windows and jdk versions and the problem is not reproducible...

Thanks, Pavel

> Hi there,
>
> I noticed that in some cases JSeparator would render differently (see
> attached photo - first one from the top, left window).
>
> It is repeatable - I can quit and re-run the app and the same
> JSeparator would be wrong. Curiously, I use the preview feature from
> NetBeans for the project code which generates this window, and the
> problem does not appear there.
>
>
> Confused,
> Alex.
>
> ---------------
>
> Microsoft Windows [Version 6.1.7601]
>
> java version "1.7.0_02"
> Java(TM) SE Runtime Environment (build 1.7.0_02-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 22.0-b10, mixed mode)


From neugens.limasoftware at gmail.com  Fri Mar 30 08:14:58 2012
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Fri, 30 Mar 2012 17:14:58 +0200
Subject: <Swing Dev> Force JPopup to be always heavyweight
Message-ID: <CAGUMyaSsn1Lpibu=tUfJ8amBF0o56mJoYwkvRMGSbHNfSwVamg@mail.gmail.com>

Hi all,

Recently I came across this bug on our bug database:

https://bugzilla.redhat.com/show_bug.cgi?id=658654

This is actually a long standing issue that bothered me too for quite
some time, since the net result is that Java applications look weird
in some situation (specifically with the native LAF, but also with the
default ones).

I think a quick and easy solution that would preserve backward
compatibility would be to add a system property that allows forcing
heavy weight rather then medium weight behaviour for popup windows.

Most of the code is already in place, so probably the changes could
either go in JPopupMenu.getPopup with the additional advantage of
being quite circumscribed, for example:

        PopupFactory popupFactory = PopupFactory.getSharedInstance();

        if (isLightWeightPopupEnabled()) {
            popupFactory.setPopupType(PopupFactory.LIGHT_WEIGHT_POPUP);
        }
        else if (forceAlwaysHWMenues()) {
            popupFactory.setPopupType(PopupFactory.HEAVY_WEIGHT_POPUP);
        }
        else {
            popupFactory.setPopupType(PopupFactory.MEDIUM_WEIGHT_POPUP);
        }

or in a more general place forcing this to all the popup components to
be HW. This change could be for example in JPopupFactory.getPopupType,
right before the beginning of the method, for example:

        if (owner == null || invokerInHeavyWeightPopup(owner) ||
            getProperty(PopupFactory_FORCE_HEAVYWEIGHT_POPUP) {
            popupType = HEAVY_WEIGHT_POPUP;
        } else if (popupType == LIGHT_WEIGHT_POPUP &&
                 !(contents instanceof JToolTip) &&
                 !(contents instanceof JPopupMenu)) {
            popupType = MEDIUM_WEIGHT_POPUP;
        }

I personally don't see much risk for either, but the latter has
definitely more impact, so having things local to JPopupMenu seems
better (disclaimer, I didn't try those changes, so maybe more tweaking
is needed).

What do you think?

I would propose those changes for JKD8 of course.

Cheers,
Mario

P.S. I'm not sure if I should include the AWT team in the loop too.
-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA? FC7C 4086 63E3 80F2 40CF

IcedRobot: www.icedrobot.org
Proud GNU Classpath developer: http://www.classpath.org/
Read About us at: http://planet.classpath.org
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

From swingler at apple.com  Fri Mar 30 11:55:56 2012
From: swingler at apple.com (Mike Swingler)
Date: Fri, 30 Mar 2012 11:55:56 -0700
Subject: <Swing Dev> Force JPopup to be always heavyweight
In-Reply-To: <CAGUMyaSsn1Lpibu=tUfJ8amBF0o56mJoYwkvRMGSbHNfSwVamg@mail.gmail.com>
References: <CAGUMyaSsn1Lpibu=tUfJ8amBF0o56mJoYwkvRMGSbHNfSwVamg@mail.gmail.com>
Message-ID: <8170B559-E8A0-40CF-8EA8-CD06C799DCFC@apple.com>

On Mar 30, 2012, at 8:14 AM, Mario Torre wrote:

> Hi all,
> 
> Recently I came across this bug on our bug database:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=658654
> 
> This is actually a long standing issue that bothered me too for quite
> some time, since the net result is that Java applications look weird
> in some situation (specifically with the native LAF, but also with the
> default ones).
> 
> I think a quick and easy solution that would preserve backward
> compatibility would be to add a system property that allows forcing
> heavy weight rather then medium weight behaviour for popup windows.
> 
> Most of the code is already in place, so probably the changes could
> either go in JPopupMenu.getPopup with the additional advantage of
> being quite circumscribed, for example:
> 
>        PopupFactory popupFactory = PopupFactory.getSharedInstance();
> 
>        if (isLightWeightPopupEnabled()) {
>            popupFactory.setPopupType(PopupFactory.LIGHT_WEIGHT_POPUP);
>        }
>        else if (forceAlwaysHWMenues()) {
>            popupFactory.setPopupType(PopupFactory.HEAVY_WEIGHT_POPUP);
>        }
>        else {
>            popupFactory.setPopupType(PopupFactory.MEDIUM_WEIGHT_POPUP);
>        }
> 
> or in a more general place forcing this to all the popup components to
> be HW. This change could be for example in JPopupFactory.getPopupType,
> right before the beginning of the method, for example:
> 
>        if (owner == null || invokerInHeavyWeightPopup(owner) ||
>            getProperty(PopupFactory_FORCE_HEAVYWEIGHT_POPUP) {
>            popupType = HEAVY_WEIGHT_POPUP;
>        } else if (popupType == LIGHT_WEIGHT_POPUP &&
>                 !(contents instanceof JToolTip) &&
>                 !(contents instanceof JPopupMenu)) {
>            popupType = MEDIUM_WEIGHT_POPUP;
>        }
> 
> I personally don't see much risk for either, but the latter has
> definitely more impact, so having things local to JPopupMenu seems
> better (disclaimer, I didn't try those changes, so maybe more tweaking
> is needed).
> 
> What do you think?
> 
> I would propose those changes for JKD8 of course.
> 
> Cheers,
> Mario
> 
> P.S. I'm not sure if I should include the AWT team in the loop too.

This is also something that should be done with the Aqua Look and Feel on the Mac. It is never appropriate to use a lightweight popup when Aqua is installed, because there is no way that Java can create the appropriate shadow around the popup, correctly layered with other windows (for example, Command-clicking on a partially obscured JComboBox window that is in the background).

I think the Look and Feel should be able to mandate that heavyweights should be used at all times, without slamming a system property, since that is always a valid fallback case that user code has to deal with.

Regards,
Mike Swingler
Apple Inc.


From neugens.limasoftware at gmail.com  Fri Mar 30 12:28:58 2012
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Fri, 30 Mar 2012 21:28:58 +0200
Subject: <Swing Dev> Force JPopup to be always heavyweight
In-Reply-To: <8170B559-E8A0-40CF-8EA8-CD06C799DCFC@apple.com>
References: <CAGUMyaSsn1Lpibu=tUfJ8amBF0o56mJoYwkvRMGSbHNfSwVamg@mail.gmail.com>
	<8170B559-E8A0-40CF-8EA8-CD06C799DCFC@apple.com>
Message-ID: <86571A59-AF30-419F-9DAC-3F8E437CBF91@gmail.com>

Il giorno 30/mar/2012, alle ore 20:55, Mike Swingler ha scritto:

> This is also something that should be done with the Aqua Look and Feel on the Mac. It is never appropriate to use a lightweight popup when Aqua is installed, because there is no way that Java can create the appropriate shadow around the popup, correctly layered with other windows (for example, Command-clicking on a partially obscured JComboBox window that is in the background).
> 
> I think the Look and Feel should be able to mandate that heavyweights should be used at all times, without slamming a system property, since that is always a valid fallback case that user code has to deal with.


HI Mike,

I actually agree with you completely.

I would make this the default setting, as I see no harm as well.

Mario
---
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

http://www.ladybug-studio.com

IcedRobot: www.icedrobot.org
Proud GNU Classpath developer: http://www.classpath.org/
Read About us at: http://planet.classpath.org
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/




From luchsh at linux.vnet.ibm.com  Sat Mar 31 20:16:22 2012
From: luchsh at linux.vnet.ibm.com (Jonathan Lu)
Date: Sun, 01 Apr 2012 11:16:22 +0800
Subject: <Swing Dev> Request for review 7155887: ComboBox does not paint
 focus correctly on GTK L&F
In-Reply-To: <4F71D2AF.80307@oracle.com>
References: <4F6ACF28.5050102@linux.vnet.ibm.com> <4F6B3628.50707@oracle.com>
	<4F7028D8.2000307@linux.vnet.ibm.com> <4F71D2AF.80307@oracle.com>
Message-ID: <4F77C886.10507@linux.vnet.ibm.com>

Hi Pavel,

Here's the updated patch, including proposed solution for interior focus.
http://cr.openjdk.java.net/~luchsh/7155887_3/

In the orginal code as I understood, focus is only paint when 
!interiorFocus, in which case the background shadow and flatBox will 
shrink a bit to corperate with the outer focus whose size is same as the 
original component. My proposed solution is to shirink focus line for 
interior focus, but keep the same way of !interorFocus.

could you pls take a look?

On 03/27/2012 10:46 PM, Pavel Porvatov wrote:
> Hi Jonathan,
>
> What do you think about another solution: can we set component state 
> as SynthConstants.FOCUSED before paintTextBackground is invoked. 
> Another solution is to set state as "focused" for ComboBox renderer 
> like the following:
>
>         if ("ComboBox.renderer".equals(c.getName())) {
>             for (Component comboBoxParent = c.getParent(); 
> comboBoxParent != null; comboBoxParent = comboBoxParent.getParent()) {
>                 if (comboBoxParent instanceof JComboBox){
>                     if(comboBoxParent.hasFocus()){
>                         state |= SynthConstants.FOCUSED;
>                     }
>                     break;
>                 }
>             }
>         }
> without other changes in GTKPainter.java (actually there is some 
> problem with "interiorFocus", but it could be resolved....)
>
> See also my answers below.
>> Hi Pavel,
>>
>> Thanks for review, here's the new patch and my answers are inlined.
>> http://cr.openjdk.java.net/~luchsh/7155887_2/
>>
>> On 03/22/2012 10:24 PM, Pavel Porvatov wrote:
>>> Hi Jonathan,
>>>> Hi Swing-dev,
>>>>
>>>> ComboBox on linux GTK L&F does not works as gtk native 
>>>> applications, when get focused, the apperance of Java ComboBox 
>>>> remains unchanged but native GTK ComboBox control will have a 
>>>> outline to indicate it has got focused.
>>>>
>>>> The problem seems similar to bug
>>>> 6947671 ( http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6947671),
>>>> except that I did not reproduced the problem on Nimbus L&F, so 
>>>> another bug
>>>> 7155887 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7155887)
>>>> was created for this issue,
>>>>
>>>> And here's the proposed patch to fix this problem,
>>>> http://cr.openjdk.java.net/~luchsh/7155887/
>>>>
>>>> Could anybody please help to take a look?
>>> I have several comments about the patch:
>>>
>>> 1. "c.getName().equals("ComboBox.renderer")": I think we can get NPE 
>>> here
>> Yes, I've changed it to
>>
>> "ComboBox.renderer".equals(c.getName())
>>
>>>
>>> 2.
>>> +            for (Component comboBoxParent = c.getParent(); 
>>> comboBoxParent != null; comboBoxParent = comboBoxParent
>>> +                    .getParent()) {
>>> +                if (comboBoxParent instanceof JComboBox
>>> + && comboBoxParent.hasFocus()) {
>>> +                    comboBoxFocused = true;
>>> +                }
>>> +            }
>>>
>>> I'm not sure we should do such deep parent investigation. Why don't 
>>> you check first parent only?
>>>
>> javax.swing.CellRendererPane is inserted between the component and 
>> renderer, so if check only the first parent, it will retrieve a 
>> CellRendererPane object instead of JComboBox component. In the new 
>> patch, I added a break when JComboBox is encounterred so to make the 
>> effect similar to the first-parent-only approach.
> I found out the following code (see 
> com.sun.java.swing.plaf.gtk.GTKPainter#paintLabelBackground):
>         if (c instanceof ListCellRenderer &&
>                  container != null &&
>                  container.getParent() instanceof JComboBox ) {
>             ...
>         }
> I think we should use the same pattern
>>
>>> 3. "if (ENGINE.paintCachedImage(g, x, y, w, h, id, state) && 
>>> !comboBoxFocused)"
>>> If you are going to ignore ENGINE.paintCachedImage when 
>>> comboBoxFocused, then there is no need to invoke it at all
>>>
>> yes, in the new patch I've changed the order of these two checks.
>>> 4. "if (comboBoxFocused || focusSize > 0)"
>>> I'm not sure we should paint focus if focusSize == 0
>>>
>> I think there's no need to paint the focus if focusSize ==0, since 
>> the focus width and height arguements passed to JNI method 
>> native_paint_focus() will both be zero.
> That's what I meant! (may be my phrase was not clear enough)
> Your condition "if (comboBoxFocused || focusSize > 0)" allows to paint 
> focus even if focusSize == 0...
>
Oh, sorry for my misunderstanding, the previous patch indeed got such a 
problem, but it may not be in the new patch.
> Regards, Pavel

Thanks and best regards!

- Jonathan