the same in project properties dialog in Sources, again for encoding...

PHP uses ProjectCustomizer.encodingRenderer() from Project UI API.

Please evaluate, thanks.

Created attachment 119361 [details]
The many looks of a combo box

Shows what a non-editable JComboBox looks like in various places. All taken using JDK 6u32 on Ubuntu 12.04 with GNOME 3 Shell in GTK L&F.

1. Two combo boxes from a j2seproject's Sources tab.
2. From the Run tab.
3. From the Formatting tab.
4. A plain combo box with no special renderer or other code in a sample app.

My experiments suggest that there is just no reasonable way to make a JComboBox with a nontrivial custom model - one in which toString() is not the appropriate conversion for model elements - to look right when creating a ListCellRenderer out of context, the way our current helper APIs (such as ProjectCustomizer.encodingRenderer) do. The one thing that _does_ seem to work is to delegate to the original renderer installed by the L&F:

final ListCellRenderer orig = combo.getRenderer();
combo.setRenderer(new ListCellRenderer() {
  public Component getListCellRendererComponent(JList l, Object v, int i, boolean sel, boolean foc) {
    return orig.getListCellRendererComponent(l, "* " + v, i, sel, foc);
  }
});

The one drawback I can see here is that (since this is not a UIResource) if the L&F changes, the combo will still be displayed in the original delegate. I do not think this matters for usage in NetBeans, since we do not change L&F on the fly (and I hope GTK L&F when responding to GNOME theme changes does not set a new renderer but just adjusts the behavior of the existing one).

The next question is compatibility - whether it is possible to find the original renderer (or an equivalent) given the JComboBox on which setRenderer has already been set.

PlatformUiSupport.createSourceLevelListCellRenderer is a special hurdle because it delegates to HtmlRenderer.createRenderer() to highlight unsupported values, and thus looks wrong in a different way than all the rest (first combo in screenshot).

(In reply to comment #4)
> find the original renderer given the JComboBox on which setRenderer was set

It would be, with some reflection and such tricks. But even that information is not available inside getListCellRendererComponent: the renderer is only given the JList which is held in the BasicComboPopup. So we need to look for UI default ComboBoxUI subclass, and then try to construct it directly rather than calling createUI. Even that does not work for SynthLookAndFeel, which returns itself rather than SynthComboBoxUI as expected. Tricky.

Created attachment 119375 [details]
Initial patch for feedback

Fixes problems observable in j2seproject Properties dialog under GTK. Need to check other project types and forms, and confirm that everything looks normal on other L&Fs.

apichanges and more to come, but I would like to start getting feedback on this. Was the approach I have taken considered in the past and rejected, or it just was not discovered yet?


Not clear to me if defaultComboBoxRenderer() as written is the best approach, or if I should just use e.g.

ListCellRenderer r = new JComboBox().getRenderer();
return r != null ? r : new BasicComboBoxRenderer.UIResource();

(In reply to comment #7)

> 
> ListCellRenderer r = new JComboBox().getRenderer();
> return r != null ? r : new BasicComboBoxRenderer.UIResource();
This looks better to me - but I haven't tried if it actually works...


There might be another problem when switching L&F at runtime. L&f-native renderers tend to cast various objects to their expected l&f subclasses. The combo box should actually override updateUI() method to set the renderer.

(In reply to comment #4)
> PlatformUiSupport.createSourceLevelListCellRenderer is a special hurdle because
> it delegates to HtmlRenderer.createRenderer() to highlight unsupported values,
> and thus looks wrong in a different way than all the rest

Note that the current patch avoids the issue by using the delegate for regular values ("JDK 6"), only using the problematic HTML renderer for broken values ("Broken platform: 1.7"). I have no idea how HtmlRenderer could be used in such a way as to look just like the native renderer for text that happens to contain no markup.

(In reply to comment #7)
> Not clear to me if defaultComboBoxRenderer() as written is the best approach

...or another alternative is to not introduce Renderers at all, but rather deprecate existing API methods like ProjectCustomizer.encodingRenderer in favor of overloads which take an original renderer. This would make for a somewhat bigger API change but might be considered cleaner.

(In reply to comment #8)
> There might be another problem when switching L&F at runtime.

Is this an issue for NetBeans code? We provide no UI control to switch L&F dynamically.

> The combo box should actually override updateUI() method to set the renderer.

Definitely this would be more cumbersome for callers - typically Matisse-built forms, which would need custom initialization code to create an anonymous JComboBox subclass.

(In reply to comment #9)
> (In reply to comment #8)
> > There might be another problem when switching L&F at runtime.
> 
> Is this an issue for NetBeans code? We provide no UI control to switch L&F
> dynamically.
On Windows it is possible to switch to 'windows classic' appearance and back to 'windows vista/7' look. But it's not a frequent operation I'd guess.

> 
> > The combo box should actually override updateUI() method to set the renderer.
> 
> Definitely this would be more cumbersome for callers - typically Matisse-built
> forms, which would need custom initialization code to create an anonymous
> JComboBox subclass.
Sure, I was just thinking we could override updateUI() of combo boxes at well known screens in NetBeans, e.g. project properties window.

(In reply to comment #10)
> On Windows it is possible to switch to 'windows classic' appearance and back to
> 'windows vista/7' look.

Right, but will these operations actually update Swing UI delegates, or merely alter the behavior of the existing WindowsLookAndFeel? I can try to find a working version of Vista to check.

(In reply to comment #11)
> (In reply to comment #10)
> > On Windows it is possible to switch to 'windows classic' appearance and back to
> > 'windows vista/7' look.
> 
> Right, but will these operations actually update Swing UI delegates, or merely
> alter the behavior of the existing WindowsLookAndFeel? I can try to find a
> working version of Vista to check.

Yes, updateUI() is called when switching to/from Windows Classic appearance. We install new UI delegates for window tabs during that time.

(In reply to comment #4)
> final ListCellRenderer orig = combo.getRenderer();
> combo.setRenderer(new ListCellRenderer() {
>   public Component getListCellRendererComponent(JList l, Object v, int i,
> boolean sel, boolean foc) {
>     return orig.getListCellRendererComponent(l, "* " + v, i, sel, foc);
>   }
> });

Another problem is that the above code does not type well in JDK 7 - cannot be written without @SuppressWarnings("unchecked"). Which I guess is a logical flaw in Swing - for a JComboBox<Integer>, getRenderer() returns ListCellRender<? super Integer>, but in fact the default renderer can render any Object since it just calls toString(), and you _need_ it to render String.

Created attachment 120171 [details]
Demonstration of using original renderer

Apparently contrary to comment #10, this seems to work in XP even switching between "Windows Classic" and "Windows XP" themes.

Created attachment 120753 [details]
Reworked patch, no Renderers, API changes in projectuiapi & java.api.common

More straightforward patch. Missing apichanges/versioning, and missing usages in various other project types, but demonstrates the concept.

Withdrawing from API review in 7.2; just did not have enough time to review and test properly.

This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue.

Thanks for your cooperation,
NetBeans IDE 8.2 Release Boss