# :: 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.
(c) 2004 JGoodies |  |