Posted by editor on September 25, 2008 at 6:50 AM PDT
Spiffing up your LWUIT application... also:
Feature Article: Using Styles, Themes, and Painters with LWUIT
Java Today: New text widgets for Caciocavallo, Apple updates Java for Leopard and Tiger, and using Java Deployment Toolkit for JavaFX applets
Weblogs: GlassFish in Brazil, more GlassFish in Brazil, and defining cloud computing
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.
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.
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."
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 and Collection
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Participation.