Since before it was a NetBeans RCP based application, Praxis had its own Swing look-and-feel – a (minimal) fork of the lovely NimROD. Well, when I was transitioning to the NetBeans platform, I was determined to keep this look-and-feel. Unfortunately, this being a dark (white on black) look-and-feel, a small amount of hackery was required to get NetBeans to play nicely. I thought I’d document three of these here. What follows may be of use to any NetBeans developer working with non-default look and feels; it may not make much sense to a non-NetBeans developer!
Hack #1
I install the Praxis LAF within a ModuleInstall class’s restored() method. This makes the build process nice and simple, but it does have its drawbacks.
Here you can see an early attempt at installing the Praxis look and feel. hmm … the look and feel doesn’t have any green in it, so where did that green tab come from?
NetBeans has some code (in the org.netbeans.swing.plaf module) that handles changing the look and feel at runtime, switching out values from the old look and feel. Unfortunately, a few values set in AllLFCustoms are never removed and are set using a class called GuaranteedValue. Most of the GuaranteedValues delegate to another value in the UI table – unfortunately, they only delegate at creation time, which means the old values (in this case the green from my GTK theme) hangs about.
So, what do I do about it? In the code below from my ModuleInstall I take the nuclear option, completely clearing the UIDefaults table before installing my look and feel, then make sure all the necessary values are set in my LFCustoms subclass.
public void restored() {
try {
EventQueue.invokeAndWait(new Runnable() {
@Override
public void run() {
UIManager.getDefaults().clear();
ClassLoader cl = Lookup.getDefault().lookup(ClassLoader.class);
UIManager.put("ClassLoader", cl);
UIManager.put("Nb.PraxisLFCustoms", new PraxisLFCustoms());
try {
LookAndFeel laf = new PraxisLookAndFeel();
UIManager.setLookAndFeel(laf);
} catch (UnsupportedLookAndFeelException ex) {}
}
});
} catch (Exception ex) {}
}
Hack #2
So, now the main text and tabs in my look and feel are looking OK. However, there are still a few issues. Firstly, notice the help pane in the Property component here -
This isn’t used much in Praxis yet, but that text that currently says “Unrecognized File” is not meant to be black and barely readable! This component is a JEditorPane, and unfortunately JEditorPane’s don’t care much about your default colour scheme. There is a client property for JEditorPane to get it to play ball, but how to get access to this component in order to set it when it’s hidden inside non-public code?
Well, to do this I create a custom UI delegate for JEditorPanes and register it in my LFCustoms class (from #1). In this I set the required client property.
public class HonorDisplayEditorPaneUI extends BasicEditorPaneUI {
public static ComponentUI createUI(JComponent c) {
c.putClientProperty(JEditorPane.HONOR_DISPLAY_PROPERTIES, Boolean.TRUE);
return new HonorDisplayEditorPaneUI();
}
}
Problem solved!
Hack #3
The third and final hack I’m going to demonstrate is with the Options dialog. Here you can see the problem – the Options dialog buttons along the top have colours and borders hard-coded in that don’t fit well with our colour scheme.
So, apart from wanting to scream why, why, why, why, why??? 
what can be done about it? The buttons are a hidden inner class, which is inaccessible, and subclass JLabel – ah, there’s our answer, in similar fashion to #2 we can create a custom UI delegate and override some of the behaviour.
In this class I create a custom UI delegate just for JLabel subclasses from the Options module, and listen in and override properties being set. I also make sure the parent JPanel has its background set to black.
public class OptionsAwareLabelUI extends MetalLabelUI {
private static final Color oldHighlighted = new Color(224, 232, 246);
private final Color fgNormal = MetalLookAndFeel.getBlack();
private final Color bgNormal = MetalLookAndFeel.getWhite();
private final Color bgSelected = MetalLookAndFeel.getPrimaryControlShadow();
private final Color bgHighlighted = bgSelected.darker().darker();
private final Border normalBorder = new EmptyBorder(6, 8, 6, 8);
private final Border highlightBorder = new CompoundBorder(
new CompoundBorder(
new LineBorder(bgNormal),
new BevelBorder(BevelBorder.LOWERED)),
new EmptyBorder(3, 5, 3, 5));
private boolean ignoreChanges;
@Override
public void propertyChange(PropertyChangeEvent e) {
if (ignoreChanges) {
super.propertyChange(e);
return;
}
if (!(e.getSource() instanceof JLabel)) {
super.propertyChange(e);
return;
}
JLabel c = (JLabel) e.getSource();
checkParent(c);
if ("background".equals(e.getPropertyName())) {
ignoreChanges = true;
Color bgCurrent = c.getBackground();
if (Color.WHITE.equals(bgCurrent)) {
c.setBackground(bgNormal);
} else if (oldHighlighted.equals(bgCurrent)) {
c.setBackground(bgHighlighted);
} else if (!bgNormal.equals(bgCurrent)) {
c.setBackground(bgSelected);
}
ignoreChanges = false;
} else if ("foreground".equals(e.getPropertyName())) {
ignoreChanges = true;
if (!fgNormal.equals(c.getForeground())) {
c.setForeground(fgNormal);
}
ignoreChanges = false;
} else if ("border".equals(e.getPropertyName())) {
ignoreChanges = true;
Border current = c.getBorder();
if (current instanceof EmptyBorder) {
c.setBorder(normalBorder);
} else {
c.setBorder(highlightBorder);
}
ignoreChanges = false;
} else {
super.propertyChange(e);
}
}
private void checkParent(JComponent c) {
Component parent = c.getParent();
if (parent instanceof JPanel) {
if (!bgNormal.equals(parent.getBackground())) {
parent.setBackground(bgNormal);
}
}
}
public static ComponentUI createUI(JComponent c) {
if (c.getClass().getName().startsWith("org.netbeans.modules.options")) {
return new OptionsAwareLabelUI();
} else {
return MetalLabelUI.createUI(c);
}
}
}
And now we get this – not perfect yet, but at least it’s the right colour-scheme!
Conclusion
Well, a rather long first post about NetBeans but hopefully this is of use to someone else. Just remember, they’re hacks and rely on underlying behaviour of non-public code so will need checking against new versions of the NetBeans platform.
You can find all this code in LAF module in the Praxis LIVE repository.
Now, I’m off to write some RFE’s so hopefully these hacks won’t be needed in future!
Simply put, a couple of blog posts I’ve read over the last month or so have convinced me that the whole alpha, beta, whatever cycle is just not right for a project like Praxis / Praxis LIVE that is continually evolving. Different features are at a different stage of evolution – some are what I’d consider release quality, some are beta, and some are quite definitely temperamental, anti-social, and marked as such! The important thing is that it’s usable, the basic architecture is complete, and the framework (Praxis) and visual editor (Praxis LIVE) are now in sync and developing concurrently. So, from now on there will be frequent incremental releases on a 4-6 week timetable.
