<Swing Dev> Background/Foreground colors and Gtk Look and Feel

[Elliott Hughes]

Stijn Debruyckere <stijn.debruyckere at luciad.com> wrote:
> Continuing the discussion of Jan 22, 2009, people seem to think there is
> no need to adapt the foreground/background colors of say a text field. But
> how about validation?  For example, the background of the 'find' text
> field of Firefox colors red when the text can't be found.  As far as I
> know, this simple yet powerful feature can't be implemented in Swing if
> one wants to support multiple look&feels, such as GTK or Nimbus (as
> setBackground is ignored).

yeah, in similar "invalid find" situations, i change the text field's
foreground instead. (which does work.)

somewhat relatedly, i have several application where i'd like a
"selectable label". with the other LAFs, i can use JTextField, but with
the GTK LAF, i can't stop it painting its white background and focus ring.
(i can get rid of the border, but arguably that looks worse.)

real GTK+ applications allow selectable labels (choose "Properties" on any
file in Nautilus, for example, and see that you can select the non-bold
text in that dialog), though i think it's done by making a label
selectable rather than fiddling with a text field to make it look like a
label. but in the absence of JLabel.setSelectable, it would be nice to at
least be able to make JTextField behave on all platforms.

here's my current best effort:

public class UneditableTextField extends JTextField {
    public UneditableTextField() {
        this("");
    }

    public UneditableTextField(String initialValue) {
        super(initialValue);
        // Text fields with setEditable(false) don't look very different
on any platform but Win32.
        // Win32 is the only platform that clearly distinguishes between
all the combinations of editable and enabled.
        // It's sadly unclear that those responsible for the other
platforms even understand the distinction.
        // Although Cocoa makes a overly-subtle visual distinction,
Apple's Java doesn't reproduce it.
        // As a work-around, we use a trick various Mac OS programs use:
make the uneditable text fields look like labels.
        // You lose the visual clue that you can select and copy the text,
but that's less important than obscuring the visual clue on
editable fields that they're editable.
        // FIXME: at the moment, we're far too wide when there are lots of
processes with access to the terminal.
        // FIXME: a PTextArea would retain the selection behavior but add
wrapping, but we need to change FormPanel first because
GridBagLayout won't let us do the right thing when (say) the
"dimensions" and "processes" need one line-height each, but "log
filename" needs two line-heights.
        // FIXME: because of the way the GTK+ LAF renders text fields,
this looks awful. setOpaque has no effect. See getName for a
partial work-around.
        setBorder(new EmptyBorder(getBorder().getBorderInsets(this)));
        setOpaque(false);
        setEditable(false);
    }

    public String getName() {
        // The GTK+ LAF insists on rendering a border unless we're a tree
cell editor. So pretend to be a tree cell editor.
        // This still doesn't look quite right, but it's the best I know
how to do, and it's significantly better than doing nothing.
        return GuiUtilities.isGtk() ? "Tree.cellEditor" : super.getName();
    }
}

-- 
Elliott Hughes, http://www.jessies.org/~enh/