Java Windows 11 Look And Feel
Alesha Canant
The architecture of Swing is designed so that you may change the "look and feel" (L&F) of your application's GUI (see A Swing Architecture Overview). "Look" refers to the appearance of GUI widgets (more formally, JComponents) and "feel" refers to the way the widgets behave.
Most developers never need to interact with the UI delegate directly. For the most part, the UI delegate is used internally by the JComponent subclass for crucial functionality, with cover methods provided by the JComponent subclass for all access to the UI delegate. For example, all painting in JComponent subclasses is delegated to the UI delegate. By delegating painting, the 'look' can vary depending upon the L&F.
All of Sun's L&Fs have a great deal of commonality. This commonality is defined in the Basic look and feel in the API (javax.swing.plaf.basic). The Motif and Windows L&Fs are each built by extending the UI delegate classes in javax.swing.plaf.basic (a custom L&F can be built by doing the same thing). The "Basic" L&F is not used without being extended.
You aren't limited to the L&Fs supplied with the Java platform. You can use any L&F that is in your program's class path. External L&Fs are usually provided in one or more JAR files that you add to your program's class path at runtime. For example:
The L&F that Swing components use is specified by way of the UIManager class in the javax.swing package. Whenever a Swing component is created,the component asks the UI manager for the UI delegate that implements the component's L&F. For example, each JLabel constructor queries the UI manager for the UI delegate object appropriate for the label. It then uses that UI delegate object to implement all of its drawing and event handling.
To programmatically specify a L&F, use the UIManager.setLookAndFeel() method with the fully qualified name of the appropriate subclass of LookAndFeel as its argument. For example, the bold code in the following snippet makes the program use the cross-platform Java L&F:
Yet another way to specify the current L&F is to use the swing.properties file to set the swing.defaultlaf property. This file, which you may need to create, is located in the lib directory of Sun's Java release (other vendors of Java may use a different location). For example, if you're using the Java interpreter in javaHomeDirectory\bin, then the swing.properties file (if it exists) is in javaHomeDirectory\lib. Here is an example of the contents of a swing.properties file:
You can change the L&F with setLookAndFeel even after the program's GUI is visible. To make existing components reflect the new L&F, invoke the SwingUtilities updateComponentTreeUI method once per top-level container. Then you might wish to resize each top-level container to reflect the new sizes of its contained components. For example:
In the following example, LookAndFeelDemo.java, you can experiment with different Look and Feels. The program creates a simple GUI with a button and a label. Every time you click the button, the label increments.
Themes were introduced as a way of easily changing the colors and fonts of the cross-platform Java (Metal) Look and Feel. In the sample program, LookAndfeelDemo.java, listed above, you can change the theme of the Metal L&F by setting the THEME constant on line 23 to one of three values:
Ocean, which is a bit softer than the pure Metal look, has been the default theme for the Metal (Java) L&F since Java SE 5. Despite its name, DefaultMetal is not the default theme for Metal (it was before Java SE 5, which explains its name). The Test theme is a theme defined in TestTheme.java, which you must compile with LookAndfeelDemo.java. As it is written, TestTheme.java sets the three primary colors (with somewhat bizarre results). You can modify TestTheme.java to test any colors you like.
When you download theJDK and JavaFX Demos and Samples bundle and open it up, there is a demo\jfc folder that contains a demonstration program called SwingSet2. This program has a graphically rich GUI and allows you to change the Look and Feel from the menu. Further, if you are using the Java (Metal) Look and Feel, you can choose a variety of different themes. The files for the various themes (for example, RubyTheme.java) are found in the SwingSet2\src folder.
I have four clients running on identical machines but one has a different look and feel.
This is affecting the power tables, specifically the header height and color, which causes layout issues in some windows.
The other three clients are displaying the power tables exactly as in designer.
I tried the methods provided in the wiki, attempted using the swing.properties file, even running it with java directly(with the options enabled) and all of them have absolutely no effect whatsoever, I still get the default "metal" theme in all java windows except for eclipse.
I confirm that following the instructions in the wiki on this subject does not have the expected result. Running the NetX control panel (itweb-settings) from the icedtea-web-java7 package with _JAVA_OPTIONS set as described does enable anti-aliases fonts, but doesn't switch from Metal to GTK. I haven't tested any other Java stack besides jre7-openjdk (and I'm not going to do so, since switching Java installs is disruptive).
It appears the GeoGebra ignores the default property, and forces the Metal Look and Feel by calling UIManager.getCrossPlatformLookAndFeelClassName() to get the look and feel. Luckily java lets you set the cross platform look and feel name with a property.
This approach does look interesting, as it reduces considerably the burden required to get a LAF up-and-running, and is more analogous to skinnable applications like Winamp. There are of course performance issues to think about: a GUI consisting of images could well require additional resources, memory wise, although, with the improved graphics pipeline in the forthcoming Java release, this may not be an issue. A good example of a Synth-based LAF is Synthetica.
About the author:
Andrew Roberts is a computer science graduate from the University of Leeds, UK. He remained at Leeds to study further towards a PhD in Natural Language Processing. He has been using Linux for almost 8 years, and Java has been his language of choice for advanced language processing and machine learning during the last three years.
I understand your concern. The fact is developing a Swing application does not give you good performances for free. You have to know how Swing works. When you do, then you can use it wisely. The most common problem is related to event handling and the Event Dispatcher Thread (EDT). When you click on a button, your code runs in the EDT and if you perform long operations in this thread, you block the whole app. There are dozens of good documentation about how to work around this problem and it is very easy. When you do that correctly, 90% of the responsiveness problems disappear.
The anti aliased text provided by Java until version 1.5 is awful because it does not allow to do subpixel anti aliasing (or ClearType or whatever). It should be available in Java 1.6 though and this will definitely help.
Java applications do not run slowly, they APPEAR to run slowly when they have a GUI, because of some misunderstanding of the Swing API (which, I reckon, is sometimes hard to use). Seriously this is due to how the toolkit is used.
Java applications do not run slowly, they APPEAR to run slowly when they have a GUI, because of some misunderstanding of the Swing API (which, I reckon, is sometimes hard to use). Seriously this is due to how the toolkit is used.
finally, i jumped out of the train and i went back to my good old habits and im so happy today. i am a windows developer and i love programming directly with win32 apis. alot of people tell me that i waste some precious time doing everything by myself but i personally think that they are all wrong.
I rather appreciate the fact that we are moving to a java client though, for the reason that we will theoritically be free to deploy on other operating systems if desired at some point in the future. We could mix client machines, even have a few Macs in there and the application should still work, even though it may look a little funky.
Right click on a textbox in explorer. Right click a text box in WMP. Right click a textbox in Office. Right click a text VS.NET. They look slightly different, but they all work the same. Now right click a XUL textbox. Java textbox? All out of place. Completely incosistent context menus. File Browser control? Same problem.
This kind of disparity is very evident when working with unicode and multiple languages. Native widgets that perform the same kind of task work the same way, have the same options. But Java? XUL? Oh no.
Java is the language of choice at my university, so I have fair experience with using Swing. All three (major) platforms are available to develop on, and I take the trouble to see that things work nicely on all three.
Where I work we used to provide both xpdf and the older adobe acrobat reader 5.0. This in the context of gnome-2.8 desktop with mozilla and openoffice. As such my users were forced to come to terms with 5 different sets of interfaces and this was the source of so many errors and so much frustation on the part of my users. The actual applications themselves were not that problematic-the widgets sets/toolkits in use by these application were each quite different but the the users had little difficulty adjusting to differing fonts, colors, icons etc. The problems were all caused by these differing interfaces.
Occassionally I would take a look inside /tmp and find that people had been storing their documents there not understanding that each time the server booted the contents of /tmp were being deleted. Then there was the issue of the print dialogue. This issue was compounded by the fact that not only do openoffice, mozilla, acroread and xpdf but also too many of the gnome-2.8 apps each have wildly different print dialogues with apparently contradictory and contra-intuitive options.
d3342ee215