Editor's Daily Blog

Colorful

Spiffing up your LWUIT application

Last month, author Biswajit Sarkar offered An Introduction to the Lightweight User Interface Toolkit, offering a bird's eye view of the major concepts of LWUIT, its goals, design, and features. Of course, a high-level overview can only do so much, so given the interest in LWUIT, we decided to start digging further into the toolkit with a followup article.

You may recall from the first article that LWUIT shares a lot of concepts with Swing, particularly in the concept of using lightweight rendering to achieve a consistent look-and-feel across devices (which, given that the devices' native L&Fs aren't as well-known or beloved as the Mac or Windows interfaces, might make LWUIT's value-proposition even more appealing than Swing's). What's even more remarkable is that LWUIT borrows some ideas that have been kicking around the Swing realm for years, like SwingX's painters, that haven't yet made it into Swing itself.

Biswajit focuses on some of these widget-customization features in today's Feature Article, Using Styles, Themes, and Painters with LWUIT.

The concept of style is the foundation on which theming is built. The idea behind style is to centrally define the visual attributes for each component. In addition to its physical design, such as its shape, the appearance of a widget can be defined in terms of a number of common features.

In the article, you'll learn about those features, how you assemble combinations of colors, fonts, images and opacity into styles and themes, and have GUI elements use those settings. And if you need not just consistent graphic attributes but also need to use the same custom painting code across multiple components, that's where LWUIT's painters come in to play.

In Java Today, Roman Kennke is reporting further progress on OpenJDK's Caciocavallo project, which seeks to improve the portability of AWT/Java2D backends. In Caciocavallo for the masses, he discusses two new widgets for AWT peers, the TextFieldPeer and a prototype of a TextAreaPeer. "I also continued with The Big Font Refactoring in Caciocavallo. The plan is to enable replacing of the font implementation, which is currently not at all possible."

Apple has announced updates for its Java runtime on Leopard and Tiger. Java for Mac OS X 10.5 Update 2 updates Java SE 6 (64-bit Intel only), J2SE 5.0, and J2SE 1.4.2 with security, performance and compatibility for Leopard users. Similarly, Java for Mac OS X 10.4, Release 7 "delivers improved reliability and compatibility" for J2SE 5.0 and J2SE 1.4.2 on Tiger. Both runtimes are also available via Software Update.

Jim Weaver's latest JavaFX tutorial in JavaLobby introduces the clever technique of Using the Java Deployment Toolkit with JavaFX Applets. "In a nutshell, the Java Deployment Toolkit is a JavaScript library maintained by Sun and always available at runtime by your HTML code. This library has several methods that perform tasks such as sensing Java-related infrastructure and installing the JRE on client machines. We'll use one of these methods, namely runApplet, to run a JavaFX applet with a specified minimum JRE version."

Today's Weblogs feature two blogs about GlassFish's adventures in Brazil, starting with Arun Gupta description of GlassFish @ DF JUG in Brasilia. "Daniel deOliveira, a Java Champion and DF JUG (oldest & biggest with 33,000 member Java User Group) founder and leader picked me up at the airport. He demonstrated true welcoming spirit by taking me around the city and showing the key places. And again he volunteered to take me to the venue of JUG."

Kohsuke Kawaguchi also blogs about the Brazil tour. "I've been to Brazil to talk about Hudson and GlassFish v3 for the past two weeks, and this is my brief trip report."

Elsewhere, Rich Unger takes a crack at Defining Cloud Computing. "Okay, so what is "cloud computing"? Much like "rich internet application" or "service-oriented application", the terminology has been co-opted by so many companies as to almost completely lose its meaning. But, since this is my blog, I'll define cloud computing as it pleases me."

In today's Forums, cbare asks about strategies for Drawing to an off screen buffer. "I'm trying to build a little program that draws complicated time-consuming plots. I'd like to avoid having my UI freeze up while I'm rendering, so I don't want to do the rendering on the event dispatch thread. So, what's the modern (well, Java 5 level of modern) way of doing this? First, should I be drawing on a Canvas or a JPanel? I'm using Swing components in the rest of my app and I've read that you're not supposed to mix Swing and AWT, but I can switch if there's good reason. Next, do I want to use VolatileImage, BufferStrategy, or something else? Can you even get a BufferStrategy for a JPanel? I'd like to get hardware double buffering, if possible."

tarbo reminds us of the implementations details of Generics in the reply Re: Generics and getting the actual type programmatically. "Information on generics or, more specifically, instances of types is not available at runtime. You may try to work one way or the other, but the information is simply not there at runtime; generics are purely a tool for the compiler to help you limit the number of casts and possible programming errors. This leads to some curiosities. Collection<String> and Collection<Object> represent the exact same class. And a Collection<K> is clueless as to what this K is, exactly; the compiler did static analysis of the code and enforced that only Ks could be supplied, and automagically added casts when you iterate over the collection's contents."

Finally, robjd notices that Javascript Number is converted to a java String with trailing ".0". "I have a Javascript variable containing an integer value e,g. x = Number("3") which is passed to an applet method expecting a String parameter. In version 1.6.0_07 and prior versions the String would be converted to "3", but in 1.6.0_10-rc2-b32 it is converted to "3.0". We can workaround this issue by applying the String() function before calling the applet or overloading our applet methods to receive an int and then explicitly converting to a String, but this will involve coding and re-testing. Does anyone know if this new behaviour is what we should expect by a JavaScript Number to java String conversion? Should this be raised as a bug or do we need to make the necessary application code changes? "

Current and upcoming Java Events :

• September 23-26 - Java Power Tools Bootcamp in Melbourne
• September 26-28 - Western Canada Software Symposium 2008
• September 29-October 1 - The Ajax Experience
• September 29-October 2 - Java Power Tools Bootcamp in Sydney
• September 29-October 3 - JavaEE Training Philippines
• October 5-9 - JAX - it's all about Technology, Architecture, Agility
• October 6-9 - Java Power Tools Bootcamp in Brisbane
• October 10-12 - Twin Cities Software Symposium 2008: Fall Edition
• October 17-19 - Gateway Software Symposium 2008: Fall Edition
• October 24-26 - Greater Atlanta Software Symposium 2008: Fall

Registered users can submit event listings for the java.net Events Page using our events submission form. All submissions go through an editorial review before being posted to the site.

Archives and Subscriptions: This blog is delivered weekdays as the Java Today RSS feed. Also, once this page is no longer featured as the front page of java.net it will be archived along with other past issues in the java.net Archive.

Comments

This work is licensed under a Creative Commons License.