:: ClearLook ::
ClearLook is an add-on to the JGoodies l&fs that ships with the Looks package.
It can automatically correct the most critical
and typical Swing misuse.
This is work in progress, and currently I don't advocate to use it
in production systems. Nevertheless, it can improve finished products
that you cannot easily overhaul.
Anyway, I recommend to switch on the debug
mode and check whether ClearLook detects and marks any decorations.
You should then remove visual clutter by hand so that your
app will look clean, even without the JGoodies looks.
Setting the ClearLook Mode
Although ClearLook will typlically improve the
appearance of your application, it may lead to
incompatible layout, and so, it is switched off by default.
You can switch it on, enable a verbose mode,
which will log reports about the performed
modifications to the console or use the debug mode.
In debug mode, ClearLook will mark decorations that
it has identified as visual clutter using saturated colors.
ClearLookManager.setMode(ClearLookMode.DEBUG);
Setting a ClearLook Policy
ClearLook comes with a prebuilt policy, that is used by default
and that can detect several misuse situations.
In addition ClearLook allows to use custom ClearLook policies,
that implement the ClearLookPolicy interface,
which you can set using an instance or class name:
ClearLookManager.setPolicy(new JoesClearLookPolicy());
ClearLookManager.setPolicy("com.joe.JoesClearLookPolicy");
How ClearLook Works
I have just started to identify a general set of rules for
finding and replacing obsolete borders, etc.,
where each single rule defines when and how to remove
or replace obsolete decorations and visual clutter,
for example nested beveled borders, and nested splitpane borders.
ClearLook works as follows: a UI delegate asks
the ClearLookManager to check for available
modifications, which in turn asks the current ClearLook
policy to do the job.
An implementation of ClearLookPolicy
comprises a set of modification rules.
Firstly, it checks whether one of these rules applies to the
component's context, i. e. the component state and component tree.
If so, it looks up a replacement decoration for the choosen rule,
and finally installs a replacement or modifies the component tree.
I have prebuilt the DefaultClearLookPolicy which
comprises a foundation of rules, behavior to identify
common component states, and a lookup mechanism,
that involves the current look&feel to get modifications.
One can extend or replace the default policy with a custom policy.
For example, I have extended the default policy to add
a set of custom rules for the NetBeans IDE, which has become
kind-of reference application for testing.
I have tested it against different NetBeans versions -
and I'm quite satisfied with the results.
|