I propose to create new API class called JDKBug_6505565_WorkaroundRenderer.
Clients with custom renderers in combo boxes will subclass in order to get the
right look on GTK. Change has no visual effects on other known LFs.

Created attachment 36841 [details]
diff of API

Created attachment 36842 [details]
example API usage in projects UI (two cases)

Hello api reviews, I'm asking for fast track review of this issue. All materials
are attached as diffs, both API + javadoc and its example usages.

I don't think we should make a permanent API addition to work around a bug in
one JDK release! There must be some other solution that does not involve a
public API.


BTW please do not use the IDE's diff tool for generating patches for review. It
cannot produce -u diffs.

Jesse, of course there is a way without API - copy & paste workaround code
(10-15 lines of code) into 50+ places in NetBeans where we are using custom
renderers for combo boxes. Is that right solution? I'm not sure...

Maybe I should rename API renderer class to NbDefaultListCellRenderer. That way,
only minimal change is needed on these 50+ places. And moreover, current code in
cvs won't work even after the fix from JDK team. Today, most custom renderers
extends from DefaultListCellRenderer, but it won't be enough. You will have to
extend from DefaultListCellRenderer.UIResource to say GTK LF: "paint the borders
and dimensions and style for me as it is in default case".
NbDefaultListCellRenderer will work the same way as
DefaultListCellRenderer.UIResource in future JDK versions (1.6.0 update 2 and
higher). Kirill Kirichenko from JDK team can provide details.

Note that we would like to show nice Netbeans running on GTK LF on JavaOne 2007,
and only 1.6 update 1 will be released at that time - that't why this is important.

What do you think? 

I think with the name NbDefaultListCellRenderer it is OK *if* this is intended
as a permanent change (even after a fix of the JDK bug). I would first like some
clearer confirmation from the Swing team that there is no safe, portable, simple
way to write a list cell renderer, i.e. that a custom NB support API would
really be needed in perpetuity. DLCR.UIResource's Javadoc says

"DefaultListCellRenderer doesn't implement UIResource directly so that
applications can safely override the cellRenderer property with
DefaultListCellRenderer subclasses."

but I really can't figure out what that is supposed to mean.

If after the bugfix code should simply be subclassing DLCR.UIR (or something),
then I think introducing a new API as a workaround for a transient bug is a
mistake. We could create custom builds with the GTK support patch, or modify
source files and then revert the modifications after 6.0u2 is released, or
(perhaps) add the API as initially @Deprecated and then delete it later.

JDKBug_6505565_WorkaroundRenderer will definitely work with further update
releases. I'll take care of it.
Swing tutorial show the correct way of creating custom renderers: implement
ListCellRenderer and extend JLabel. Of course it's possible to use
DefaultListCellRenderer here but it the Default and it sets up specific borders
and isOpaque policy which makes it look different than your implementation of
ListCellRenderer and extending JLabel.
Yesterday I had a talk with Scott Violet about using DefaultListCellRendrerer in
ComboBoxes (unfortunately he's leaving Sun soon) and we ended up with a way how
to fix it but it is not a preferable way.
And yes you should always implement UIResource in your custom renderers if want
them look like GTK native - it's Synth policy which we inherit in GTK L&F.
Otherwise you'll have to implement all painting bu yourself.

Forgotten?

bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6505565 is already fixed.
i also tried the latest build and it looks ok to me running either with 1.6 or 1.7

closing