From slkom at sao.ru  Tue Aug  7 17:12:52 2007
From: slkom at sao.ru (Serj)
Date: Tue, 7 Aug 2007 21:12:52 +0400
Subject: <Swing Dev> Fwd: TreeModel: err???
In-Reply-To: <198428482.20070806170254@sao.ru>
References: <198428482.20070806170254@sao.ru>
Message-ID: <72343102.20070807211252@sao.ru>



        class SimpleModel_bad implements TreeModel {
                
                private String root = "root";
                private String 
                        colors = "color",
                        food = "food";
                private ArrayList rootList = new ArrayList(),
                        colorsList = new ArrayList(),
                        foodList = new ArrayList();
                public SimpleModel_bad() {
                        rootList.add(colors);
                        rootList.add(food);
                        colorsList.add("red");
                        colorsList.add("red"); // eq first string! error || ok if use StringBuffer("red")
                        foodList.add("pie");
                        foodList.add("pie");// eq first string! error
                                                  // || ok if use StringBuffer("pie") ok
                }




http://slkom.mylivepage.ru, http://fviz.narod.ru , http://www.sao.ru/hq/slkom/ , http://www.bukovo.net
??????????? ??????????????? ???????????? (???)
SAO RAS
7 ??????? 2007 ?.
                
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ok.rar
Type: application/octet-stream
Size: 16208 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20070807/0c110441/ok.rar>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ok.jar
Type: application/octet-stream
Size: 4142 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20070807/0c110441/ok.jar>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bad.rar
Type: application/octet-stream
Size: 16072 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20070807/0c110441/bad.rar>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bad.jar
Type: application/octet-stream
Size: 4213 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20070807/0c110441/bad.jar>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SimpleTreeModel.gif
Type: image/gif
Size: 6123 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20070807/0c110441/SimpleTreeModel.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SimpleTreeModel_bad.gif
Type: image/gif
Size: 5867 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20070807/0c110441/SimpleTreeModel_bad.gif>

From linuxhippy at gmail.com  Thu Aug 16 17:24:10 2007
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Thu, 16 Aug 2007 19:24:10 +0200
Subject: <Swing Dev> Updating a JComboBox's values at popup-opening-time
Message-ID: <194f62550708161024t7f4991au8c58a5baa0ac4524@mail.gmail.com>

Hello,

This is both a question and (if its really a problem) maybe an idea
for enhancement.

I've a JComboBox which should update its values at the time it is
opened (because the come from a source which changes from time to time
during the life of the JComboBox and I don't want to update it
periodically).
What I did was to register a PopupListener and changed the item of the
ComboBox but the problem was that the Popup already existed - and
although its values were updated its size was not.
If I e.g. had 1 entry before the update and 4 afterwards I got a list
with the size of 1 entry with very small scrollbars.

The root of the problem seems to be that there is no legal way to
access the BasicComboPopup (or whatever its called), as far as I've
seen.

Could my stuff be done in another way which would not cause the
problems mentioned above? I currently did a hack which calls
showPopup/hidePopup in the listener so that the too small list is
hidden and afterwards the larger list appears but thats really a hack.

I wonder wether it would be ok to work on that stuff so that the list
re-calculates its size also when items are removed/added when the
popup is already visible? Do you think that could break something?

Please feel free to send commend, I would be really happy about suggestions.

lg Clemens


From Alexander.Potochkin at Sun.COM  Thu Aug 16 18:16:23 2007
From: Alexander.Potochkin at Sun.COM (Alexander Potochkin)
Date: Thu, 16 Aug 2007 22:16:23 +0400
Subject: <Swing Dev> Updating a JComboBox's values at popup-opening-time
In-Reply-To: <194f62550708161024t7f4991au8c58a5baa0ac4524@mail.gmail.com>
References: <194f62550708161024t7f4991au8c58a5baa0ac4524@mail.gmail.com>
Message-ID: <46C49477.5040501@sun.com>

Hello Clemens

It sounds very similar to the bug 4743225

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4743225

As far as I know there is no any good workaround for this problem, sorry

alexp


> Hello,
> 
> This is both a question and (if its really a problem) maybe an idea
> for enhancement.
> 
> I've a JComboBox which should update its values at the time it is
> opened (because the come from a source which changes from time to time
> during the life of the JComboBox and I don't want to update it
> periodically).
> What I did was to register a PopupListener and changed the item of the
> ComboBox but the problem was that the Popup already existed - and
> although its values were updated its size was not.
> If I e.g. had 1 entry before the update and 4 afterwards I got a list
> with the size of 1 entry with very small scrollbars.
> 
> The root of the problem seems to be that there is no legal way to
> access the BasicComboPopup (or whatever its called), as far as I've
> seen.
> 
> Could my stuff be done in another way which would not cause the
> problems mentioned above? I currently did a hack which calls
> showPopup/hidePopup in the listener so that the too small list is
> hidden and afterwards the larger list appears but thats really a hack.
> 
> I wonder wether it would be ok to work on that stuff so that the list
> re-calculates its size also when items are removed/added when the
> popup is already visible? Do you think that could break something?
> 
> Please feel free to send commend, I would be really happy about suggestions.
> 
> lg Clemens



From kirillcool at yahoo.com  Thu Aug 16 18:51:08 2007
From: kirillcool at yahoo.com (Kirill Grouchnikov)
Date: Thu, 16 Aug 2007 11:51:08 -0700 (PDT)
Subject: <Swing Dev> Updating a JComboBox's values at popup-opening-time
Message-ID: <841868.14004.qm@web52712.mail.re2.yahoo.com>

Actually, there are three options.

The first is to use reflection on the UI delegate to get the protected popup field. The second is to wrap the original UI delegate and delegate all the calls to it. Then, you can override the createPopup method and store the reference to it in your code. 

Both are very unlikely to break in the future JDK versions since both popup field and createPopup method are protected and as such are contract between Swing and third-party LAFs. The first will break under a strict security manager (JNLP, applets, ...). The second requires much more work to track LAF changes and delegate all the public and protected methods.

Yet another option is to call BasicComboBoxUI.getAccessibleChild() passing 0 as the second parameter. Here you don't have any guarantees that it won't break under the future JDK versions, but that would be also highly unlikely.

Kirill

----- Original Message ----
From: Alexander Potochkin <Alexander.Potochkin at Sun.COM>
To: swing-dev at openjdk.java.net
Sent: Thursday, August 16, 2007 11:16:23 AM
Subject: Re: <Swing Dev> Updating a JComboBox's values at popup-opening-time

Hello Clemens

It sounds very similar to the bug 4743225

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4743225

As far as I know there is no any good workaround for this problem, sorry

alexp


> Hello,
> 
> This is both a question and (if its really a problem) maybe an idea
> for enhancement.
> 
> I've a JComboBox which should update its values at the time it is
> opened (because the come from a source which changes from time to time
> during the life of the JComboBox and I don't want to update it
> periodically).
> What I did was to register a PopupListener and changed the item of the
> ComboBox but the problem was that the Popup already existed - and
> although its values were updated its size was not.
> If I e.g. had 1 entry before the update and 4 afterwards I got a list
> with the size of 1 entry with very small scrollbars.
> 
> The root of the problem seems to be that there is no legal way to
> access the BasicComboPopup (or whatever its called), as far as I've
> seen.
> 
> Could my stuff be done in another way which would not cause the
> problems mentioned above? I currently did a hack which calls
> showPopup/hidePopup in the listener so that the too small list is
> hidden and afterwards the larger list appears but thats really a hack.
> 
> I wonder wether it would be ok to work on that stuff so that the list
> re-calculates its size also when items are removed/added when the
> popup is already visible? Do you think that could break something?
> 
> Please feel free to send commend, I would be really happy about suggestions.
> 
> lg Clemens








       
____________________________________________________________________________________
Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games.
http://sims.yahoo.com/  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20070816/175803ae/attachment.html>

From Alexander.Potochkin at Sun.COM  Fri Aug 17 08:52:13 2007
From: Alexander.Potochkin at Sun.COM (Alexander Potochkin)
Date: Fri, 17 Aug 2007 12:52:13 +0400
Subject: <Swing Dev> Updating a JComboBox's values at popup-opening-time
In-Reply-To: <194f62550708161024t7f4991au8c58a5baa0ac4524@mail.gmail.com>
References: <194f62550708161024t7f4991au8c58a5baa0ac4524@mail.gmail.com>
Message-ID: <46C561BD.8010309@sun.com>

Hello Clemens

It sounds very similar to the bug 4743225

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4743225

As far as I know there is no any good workaround for this problem, sorry

alexp


> Hello,
> 
> This is both a question and (if its really a problem) maybe an idea
> for enhancement.
> 
> I've a JComboBox which should update its values at the time it is
> opened (because the come from a source which changes from time to time
> during the life of the JComboBox and I don't want to update it
> periodically).
> What I did was to register a PopupListener and changed the item of the
> ComboBox but the problem was that the Popup already existed - and
> although its values were updated its size was not.
> If I e.g. had 1 entry before the update and 4 afterwards I got a list
> with the size of 1 entry with very small scrollbars.
> 
> The root of the problem seems to be that there is no legal way to
> access the BasicComboPopup (or whatever its called), as far as I've
> seen.
> 
> Could my stuff be done in another way which would not cause the
> problems mentioned above? I currently did a hack which calls
> showPopup/hidePopup in the listener so that the too small list is
> hidden and afterwards the larger list appears but thats really a hack.
> 
> I wonder wether it would be ok to work on that stuff so that the list
> re-calculates its size also when items are removed/added when the
> popup is already visible? Do you think that could break something?
> 
> Please feel free to send commend, I would be really happy about suggestions.
> 
> lg Clemens



From linuxhippy at gmail.com  Fri Aug 17 10:19:50 2007
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Fri, 17 Aug 2007 12:19:50 +0200
Subject: <Swing Dev> Updating a JComboBox's values at popup-opening-time
In-Reply-To: <841868.14004.qm@web52712.mail.re2.yahoo.com>
References: <841868.14004.qm@web52712.mail.re2.yahoo.com>
Message-ID: <194f62550708170319i4623414evcbe3e77ddb7e129d@mail.gmail.com>

Hello again,

> It sounds very similar to the bug 4743225
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4743225
> As far as I know there is no any good workaround for this problem,
Oha 68 votes ... thats some kind of funny and sad too. But yes it
seems many people are fighting with this problem.

I also asked to this list because I would like to fix it, when I asked
first I didn't know that there are already some fixes available, but
none of them was compatible enough.
And regarding to the evaluation-statement well ... now its the perfect
time "after mustang" ;)

I wonder which type of compatibility problems could arise? Do you
think some people depend on the behaviour of the not-resizing list?
Is it so risky to simply run the size calculation after the popup
listeners (nobody has access to the popup anyway), or do a
double-calculation (which would be even save for reflection).

lg Clemens


> Actually, there are three options.
>
> The first is to use reflection on the UI delegate to get the protected popup
> field. The second is to wrap the original UI delegate and delegate all the
> calls to it. Then, you can override the createPopup method and store the
> reference to it in your code.
>
> Both are very unlikely to break in the future JDK versions since both popup
> field and createPopup method are protected and as such are contract between
> Swing and third-party LAFs. The first will break under a strict security
> manager (JNLP, applets, ...). The second requires much more work to track
> LAF changes and delegate all the public and protected methods.
>
> Yet another option is to call
> BasicComboBoxUI.getAccessibleChild() passing 0 as the
> second parameter. Here you don't have any guarantees that it won't break
> under the future JDK versions, but that would be also highly unlikely.
>
> Kirill
>
>
> ----- Original Message ----
> From: Alexander Potochkin <Alexander.Potochkin at Sun.COM>
> To: swing-dev at openjdk.java.net
> Sent: Thursday, August 16, 2007 11:16:23 AM
> Subject: Re: <Swing Dev> Updating a JComboBox's values at popup-opening-time
>
> Hello Clemens
>
> It sounds very similar to the bug 4743225
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4743225
>
> As far as I know there is no any good workaround for this problem, sorry
>
> alexp
>
>
> > Hello,
> >
> > This is both a question and (if its really a problem) maybe an idea
> > for enhancement.
> >
> > I've a JComboBox which should update its values at the time it is
> > opened (because the come from a source which changes from time to time
> > during the life of the JComboBox and I don't want to update it
> > periodically).
> > What I did was to register a PopupListener and changed the item of the
> > ComboBox but the problem was that the Popup already existed - and
> > although its values were updated its size was not.
> > If I e.g. had 1 entry before the update and 4 afterwards I got a list
> > with the size of 1 entry with very small scrollbars.
> >
> > The root of the problem seems to be that there is no legal way to
> > access the BasicComboPopup (or whatever its called), as far as I've
> > seen.
> >
> > Could my stuff be done in another way which would not cause the
> > problems mentioned above? I currently did a hack which calls
> > showPopup/hidePopup in the listener so that the too small list is
> > hidden and afterwards the larger list appears but thats really a hack.
> >
> > I wonder wether it would be ok to work on that stuff so that the list
> > re-calculates its size also when items are removed/added when the
> > popup is already visible? Do you think that could break something?
> >
> > Please feel free to send commend, I would be really happy about
> suggestions.
> >
> > lg Clemens
>
>
>
>  ________________________________
> Choose the right car based on your needs. Check out Yahoo! Autos new Car
> Finder tool.


From Alexander.Potochkin at Sun.COM  Fri Aug 17 11:19:50 2007
From: Alexander.Potochkin at Sun.COM (Alexander Potochkin)
Date: Fri, 17 Aug 2007 15:19:50 +0400
Subject: <Swing Dev> Updating a JComboBox's values at popup-opening-time
In-Reply-To: <194f62550708170319i4623414evcbe3e77ddb7e129d@mail.gmail.com>
References: <841868.14004.qm@web52712.mail.re2.yahoo.com>
	<194f62550708170319i4623414evcbe3e77ddb7e129d@mail.gmail.com>
Message-ID: <46C58456.5040104@sun.com>

Hello Clemens

> Hello again,
> 
>> It sounds very similar to the bug 4743225
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4743225
>> As far as I know there is no any good workaround for this problem,
> Oha 68 votes ... thats some kind of funny and sad too. But yes it
> seems many people are fighting with this problem.
> 
> I also asked to this list because I would like to fix it, when I asked
> first I didn't know that there are already some fixes available, but
> none of them was compatible enough.
> And regarding to the evaluation-statement well ... now its the perfect
> time "after mustang" ;)
> 
> I wonder which type of compatibility problems could arise? Do you
> think some people depend on the behaviour of the not-resizing list?
> Is it so risky to simply run the size calculation after the popup
> listeners (nobody has access to the popup anyway), or do a
> double-calculation (which would be even save for reflection).

Actually this bug has always been a pain for us

because we didn't find any workaround better than
showing popup and hiding it again
which is ugly and cause to popup flickering

combobox is just not ready that its data is changed inside popupListener

you can find my favorite workaround ever in comments for this bug
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4743225

the idea is to open the combobox and close it after that
with help of awt.Robot
:-)

By the way if you find a reasonable fix I'll be happy to review it

If you are subscribed to the peabody forum,
you can also look to the proposed fixes from Brian Harry for this problem

https://jdk-collaboration.dev.java.net/servlets/ProjectForumMessageView?messageID=12475&forumID=1463

Thanks
alexp


> lg Clemens
> 
> 
>> Actually, there are three options.
>>
>> The first is to use reflection on the UI delegate to get the protected popup
>> field. The second is to wrap the original UI delegate and delegate all the
>> calls to it. Then, you can override the createPopup method and store the
>> reference to it in your code.
>>
>> Both are very unlikely to break in the future JDK versions since both popup
>> field and createPopup method are protected and as such are contract between
>> Swing and third-party LAFs. The first will break under a strict security
>> manager (JNLP, applets, ...). The second requires much more work to track
>> LAF changes and delegate all the public and protected methods.
>>
>> Yet another option is to call
>> BasicComboBoxUI.getAccessibleChild() passing 0 as the
>> second parameter. Here you don't have any guarantees that it won't break
>> under the future JDK versions, but that would be also highly unlikely.
>>
>> Kirill
>>
>>
>> ----- Original Message ----
>> From: Alexander Potochkin <Alexander.Potochkin at Sun.COM>
>> To: swing-dev at openjdk.java.net
>> Sent: Thursday, August 16, 2007 11:16:23 AM
>> Subject: Re: <Swing Dev> Updating a JComboBox's values at popup-opening-time
>>
>> Hello Clemens
>>
>> It sounds very similar to the bug 4743225
>>
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4743225
>>
>> As far as I know there is no any good workaround for this problem, sorry
>>
>> alexp
>>
>>
>>> Hello,
>>>
>>> This is both a question and (if its really a problem) maybe an idea
>>> for enhancement.
>>>
>>> I've a JComboBox which should update its values at the time it is
>>> opened (because the come from a source which changes from time to time
>>> during the life of the JComboBox and I don't want to update it
>>> periodically).
>>> What I did was to register a PopupListener and changed the item of the
>>> ComboBox but the problem was that the Popup already existed - and
>>> although its values were updated its size was not.
>>> If I e.g. had 1 entry before the update and 4 afterwards I got a list
>>> with the size of 1 entry with very small scrollbars.
>>>
>>> The root of the problem seems to be that there is no legal way to
>>> access the BasicComboPopup (or whatever its called), as far as I've
>>> seen.
>>>
>>> Could my stuff be done in another way which would not cause the
>>> problems mentioned above? I currently did a hack which calls
>>> showPopup/hidePopup in the listener so that the too small list is
>>> hidden and afterwards the larger list appears but thats really a hack.
>>>
>>> I wonder wether it would be ok to work on that stuff so that the list
>>> re-calculates its size also when items are removed/added when the
>>> popup is already visible? Do you think that could break something?
>>>
>>> Please feel free to send commend, I would be really happy about
>> suggestions.
>>> lg Clemens
>>
>>
>>  ________________________________
>> Choose the right car based on your needs. Check out Yahoo! Autos new Car
>> Finder tool.



From linuxhippy at gmail.com  Fri Aug 17 13:25:09 2007
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Fri, 17 Aug 2007 15:25:09 +0200
Subject: <Swing Dev> Updating a JComboBox's values at popup-opening-time
In-Reply-To: <46C58456.5040104@sun.com>
References: <841868.14004.qm@web52712.mail.re2.yahoo.com>
	<194f62550708170319i4623414evcbe3e77ddb7e129d@mail.gmail.com>
	<46C58456.5040104@sun.com>
Message-ID: <194f62550708170625g3d1cbfble2427d5d409ec650@mail.gmail.com>

Hello again,

Sorry for wasting your time again :-/

As far as I've seen leouser already submitted tons of patches, and he
even had the same ideas what I've had (simply to re-calculate size
after the PopupListener has been called) and as it seems it turned out
to be not as easy ;)
I did not see many comments regarding problems or critics of the
current patches.

If I would know whats wrong, I could work on improving it.

Thanks for all the time and patience, lg Clemens

2007/8/17, Alexander Potochkin <Alexander.Potochkin at sun.com>:
> Hello Clemens
>
> > Hello again,
> >
> >> It sounds very similar to the bug 4743225
> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4743225
> >> As far as I know there is no any good workaround for this problem,
> > Oha 68 votes ... thats some kind of funny and sad too. But yes it
> > seems many people are fighting with this problem.
> >
> > I also asked to this list because I would like to fix it, when I asked
> > first I didn't know that there are already some fixes available, but
> > none of them was compatible enough.
> > And regarding to the evaluation-statement well ... now its the perfect
> > time "after mustang" ;)
> >
> > I wonder which type of compatibility problems could arise? Do you
> > think some people depend on the behaviour of the not-resizing list?
> > Is it so risky to simply run the size calculation after the popup
> > listeners (nobody has access to the popup anyway), or do a
> > double-calculation (which would be even save for reflection).
>
> Actually this bug has always been a pain for us
>
> because we didn't find any workaround better than
> showing popup and hiding it again
> which is ugly and cause to popup flickering
>
> combobox is just not ready that its data is changed inside popupListener
>
> you can find my favorite workaround ever in comments for this bug
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4743225
>
> the idea is to open the combobox and close it after that
> with help of awt.Robot
> :-)
>
> By the way if you find a reasonable fix I'll be happy to review it
>
> If you are subscribed to the peabody forum,
> you can also look to the proposed fixes from Brian Harry for this problem
>
> https://jdk-collaboration.dev.java.net/servlets/ProjectForumMessageView?messageID=12475&forumID=1463
>
> Thanks
> alexp
>
>
> > lg Clemens
> >
> >
> >> Actually, there are three options.
> >>
> >> The first is to use reflection on the UI delegate to get the protected popup
> >> field. The second is to wrap the original UI delegate and delegate all the
> >> calls to it. Then, you can override the createPopup method and store the
> >> reference to it in your code.
> >>
> >> Both are very unlikely to break in the future JDK versions since both popup
> >> field and createPopup method are protected and as such are contract between
> >> Swing and third-party LAFs. The first will break under a strict security
> >> manager (JNLP, applets, ...). The second requires much more work to track
> >> LAF changes and delegate all the public and protected methods.
> >>
> >> Yet another option is to call
> >> BasicComboBoxUI.getAccessibleChild() passing 0 as the
> >> second parameter. Here you don't have any guarantees that it won't break
> >> under the future JDK versions, but that would be also highly unlikely.
> >>
> >> Kirill
> >>
> >>
> >> ----- Original Message ----
> >> From: Alexander Potochkin <Alexander.Potochkin at Sun.COM>
> >> To: swing-dev at openjdk.java.net
> >> Sent: Thursday, August 16, 2007 11:16:23 AM
> >> Subject: Re: <Swing Dev> Updating a JComboBox's values at popup-opening-time
> >>
> >> Hello Clemens
> >>
> >> It sounds very similar to the bug 4743225
> >>
> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4743225
> >>
> >> As far as I know there is no any good workaround for this problem, sorry
> >>
> >> alexp
> >>
> >>
> >>> Hello,
> >>>
> >>> This is both a question and (if its really a problem) maybe an idea
> >>> for enhancement.
> >>>
> >>> I've a JComboBox which should update its values at the time it is
> >>> opened (because the come from a source which changes from time to time
> >>> during the life of the JComboBox and I don't want to update it
> >>> periodically).
> >>> What I did was to register a PopupListener and changed the item of the
> >>> ComboBox but the problem was that the Popup already existed - and
> >>> although its values were updated its size was not.
> >>> If I e.g. had 1 entry before the update and 4 afterwards I got a list
> >>> with the size of 1 entry with very small scrollbars.
> >>>
> >>> The root of the problem seems to be that there is no legal way to
> >>> access the BasicComboPopup (or whatever its called), as far as I've
> >>> seen.
> >>>
> >>> Could my stuff be done in another way which would not cause the
> >>> problems mentioned above? I currently did a hack which calls
> >>> showPopup/hidePopup in the listener so that the too small list is
> >>> hidden and afterwards the larger list appears but thats really a hack.
> >>>
> >>> I wonder wether it would be ok to work on that stuff so that the list
> >>> re-calculates its size also when items are removed/added when the
> >>> popup is already visible? Do you think that could break something?
> >>>
> >>> Please feel free to send commend, I would be really happy about
> >> suggestions.
> >>> lg Clemens
> >>
> >>
> >>  ________________________________
> >> Choose the right car based on your needs. Check out Yahoo! Autos new Car
> >> Finder tool.
>
>


From fbrunnerlist at gmx.ch  Sun Aug 26 18:33:15 2007
From: fbrunnerlist at gmx.ch (Florian Brunner)
Date: Sun, 26 Aug 2007 20:33:15 +0200
Subject: <Swing Dev> 6179357: Request interface javax.swing.tree.TreeModel
	to have a generic type for nodes
Message-ID: <200708262033.16074.fbrunnerlist@gmx.ch>

Hi,

I'm interessted in the RFE "6179357: Request interface 
javax.swing.tree.TreeModel to have a generic type for nodes". Is there 
already someone working on this issue? If not I would like to help there.

I want to address following issues:
- add generics support to the Swing framework
- provide support for new language features like varargs
- provide better support for the collection framework
- optimize code where reasonable

Do you think this is a good idea? How probable will such a change make its way 
to the "official" jdk? 

I sent the signed SCA to Sun. So what would be the next steps? I want my 
progress to be visible by the public. So what is the best strategy? Work at 
openjdk.org? Work at SwingLabs? Start a new project at java.net?

Should I work on a branch of openjdk? Or should I copy the current revision to 
a new repository? What is the easiest/ best way to get the source back to 
openjdk?

Is a JSR needed for such a change? Note: the suggested changes should be 
backwards compatible (eg. thanks to the "raw type feature" of generics), as 
far as I can see up to now. (The only exception is of course reflection, 
which can always break if you change an API). 

Thanks for your help.

-Florian


From Alexander.Potochkin at Sun.COM  Mon Aug 27 13:01:50 2007
From: Alexander.Potochkin at Sun.COM (Alexander Potochkin)
Date: Mon, 27 Aug 2007 17:01:50 +0400
Subject: <Swing Dev> 6179357: Request interface
 javax.swing.tree.TreeModel to have a generic type for nodes
In-Reply-To: <200708262033.16074.fbrunnerlist@gmx.ch>
References: <200708262033.16074.fbrunnerlist@gmx.ch>
Message-ID: <46D2CB3E.6000900@sun.com>


Hello Florian

Welcome to the swing-dev

The RFE #6179357 is definitely worth investigating
we was going to generify Swing for 1.6
but unfortunately didn't have enough time

Your fixes are welcome

Here is the information how to contribute:
http://openjdk.java.net/contribute/

For now the process is:

Become a contributor
download openJDK
make the fix
ask any related questions on this list
submit a patch
we'll assign a sponsor who we'll review your fix
and put it back when it is done

The whole process will be simplified when we complete moving to 
Mercurial repository

For this RFE you don't need to file JSR
as you mentioned changes should as backward compatible as possible

but we'll need the request to the special committee which keeps track of 
the Java public API, the sponsor will do it for you

Please note that we prefer to make the incremental fixes which fix the 
particular problem, I mean, not to mix e.g. generifying and optimization
in one fix but split it to two ones.

 >I want my
 > progress to be visible by the public. So what is the best strategy? 
Work at
 > openjdk.org? Work at SwingLabs? Start a new project at java.net?

The current process doesn't seem to provide much visibility for the 
public. To make it visible I personally would do the following things:

- start a project on java.net
(not sure it helps for this particular case)
- blog about your progress and discuss it with the community
(this is the best way to make your work visible)

Thanks
alexp


> Hi,
> 
> I'm interessted in the RFE "6179357: Request interface 
> javax.swing.tree.TreeModel to have a generic type for nodes". Is there 
> already someone working on this issue? If not I would like to help there.
> 
> I want to address following issues:
> - add generics support to the Swing framework
> - provide support for new language features like varargs
> - provide better support for the collection framework
> - optimize code where reasonable
> 
> Do you think this is a good idea? How probable will such a change make its way 
> to the "official" jdk? 
> 
> I sent the signed SCA to Sun. So what would be the next steps? I want my 
> progress to be visible by the public. So what is the best strategy? Work at 
> openjdk.org? Work at SwingLabs? Start a new project at java.net?
> 
> Should I work on a branch of openjdk? Or should I copy the current revision to 
> a new repository? What is the easiest/ best way to get the source back to 
> openjdk?
> 
> Is a JSR needed for such a change? Note: the suggested changes should be 
> backwards compatible (eg. thanks to the "raw type feature" of generics), as 
> far as I can see up to now. (The only exception is of course reflection, 
> which can always break if you change an API). 
> 
> Thanks for your help.
> 
> -Florian