This post originated from an RSS feed registered with Java Buzz by Scott Delap. Original Post: Interview with TableLayout creator Daniel Barbalace Feed Title: ClientJava.com Feed URL: http://www.clientjava.com/archives/wireless_mobile.rdf Feed Description: Client/Desktop Related Java Development Latest Java Buzz Posts Latest Java Buzz Posts by Scott Delap Latest Posts From ClientJava.com

The layout managers chapter of Desktop Java Live builds on the standard JDK layout managers by presenting three open source alternatives that I think are better suited for day to day development. Among these is TableLayout by Daniel Barbalace. In an effort to make Desktop Java Live the most complete book possible, I've contacted the various layout manager authors. Daniel was happy to not only talk about TableLayout for the book but to also respond to a few interview questions for ClientJava.com. His responses follow:

Q1. Tell us a little about yourself?

I grew up at the time that PCs first became available. I started programming when I was nine and enjoyed it ever since. Programming is the perfect blend of science and art. I was one of those who decided to enter the software field for love of developing new software. Luckily, it turned out that you can also make a living at it.

I've always enjoyed the clarity of thought that comes with working through a mathematics, physics, or software problem. So when I started to use email and the Internet, I chose the handle Clearthought, eventually using it in the package name for TableLayout.

Q2. What caused you to write TableLayout?

Perhaps the best explanation of why I wrote TableLayout can be found in a funny cartoon that illustrates what many Java developers have gone through. The cartoon is Totally GridBag.

Before TableLayout, the only layout managers available were the standard layout managers in the java.awt package. If you wanted to make any real GUIs, you had only two practical choices. You could nest containers or spend many frustrating hours working with GridBagLayout.

Nesting containers is awkward. Even after mastering GridBagLayout, I found it to be needlessly difficult to use and the code produced to be ugly and hard to read. I thought to myself that there has to be a better way of laying out components. What was needed was a conceptual breakthrough.

So one afternoon I made the decision that I was going to write my own layout manager from scratch. The way I approach problems is to start with a blank slate and think about the most fundamental issues. This is important to do even before you research a topic because only with a blank slate can you escape preconceptions and mindsets that you will aquire once you do research a topic.

I asked myself the simplest and more fundamental question one can ask about layouts. How do "I" perceive a layout when I am visualizing or viewing one? In about two minutes I determined that my natural way of thinking about layouts is like a grid whose cells contain components and whose rows and columns can be resized.

An image intuitively came into my mind. It was a spreadsheet. 1f40 In a spreadsheet, you can resize rows and columns. Doing so will resize the cells contained by those rows and columns. I imagined that instead of containing text or formulas, those cells would contain components. Each cell would have a unique address like A3. In spreadsheets, columns are specified first so A3 is the first column, third row. I decided to use this analogy when designing TableLayout. The grid used by TableLayout essentially acts like a spreadsheet's grid. That's why columns are specified before rows in the string representation of constraints. You can also think of the column number as an X coordinate and the row number as a Y coordinate. For alignments I took the four standard horizontal justifications found in both spreadsheets are word processors: left, center, right, and full. Word processors also support three standard vertical justifications: left, center, and right. I realized that the full justification would apply in the vertical as well as the horizontal for a layout manager.

This was the conceptual breakthrough needed. An intuitive and familiar idea like a spreadsheet being applied to a layout manager. It was this idea that made TableLayout different from the old java.awt layout managers, the newer swing layouts, and the few third-party layout managers that existed in the nineties. The new third-party layout managers like FormLayout and HigLayout are based on TableLayout and this basic idea.

Q3. Walk us through the history of TableLayout?

I wrote the first version of TableLayout in 1996 basing it on JDK 1.0 and JDK 1.1. I was writing a lot of generic classes for lightweight components, linked-lists, sets, etc. Most of those classes were similar to what Sun would later introduce under Swing and the collections framework. However, at this time those Sun classes didn't exist. So TableLayout was part of a generic library that I was building up for my own use.

In 2001 I rewrote TableLayout to use only standard Java classes included in the JDK. Then I packaged TableLayout into a single jar file that contained only its own classes (plus one bonus class called SingleFiledLayout which is like Flowlayout without wrapping).

I contacted Sun and submitted my layout manager to them for a review. Arthur van Hoff, a principle architect and implementer of the java.awt package including the layout interface, was impressed with TableLayout and asked me to write an article about it for Sun's Java website. Evidentially, GridBagLayout are put together quickly for the purpose of demonstrating that the AWT framework allowed for the creation of powerful, general purpose layout managers. The Java team originally thought that developers would come up with much better layout managers, but up to that time no one had published a good, general purpose layout manager.

So I wrote a detailed article, which was read by some other members of the Sun Java team. They offered some suggestions on how to make TableLayout's API more like the JDK API for consistency. I updated TableLayout and the article, which was soon afterwards published on Sun's site.

Immediately after that I started receiving much email from developers who read the article and started using TableLayout. Much of it was praise and thanks for delivering them from nested-panels and GridBagLayout. Some of it was suggestions for feature enhancements. Some enhancements like supporting components that span cells I implemented in later versions of TableLayout. Other suggestions I declined to implement because they were unnecessary or too specific to be in a general purpose layout manager.

Over the past few years I have kept TableLayout up-to-date with the latest JDK features like persistent delegation and component orientation without compromising backwards compatibility with the original publication.

Q4. What was the most difficult part of writing TableLayout?

A layout manager essentially has just two responsibilities. The first is to layout components based on the container's current size and the constraints applied to the components. The second is to determine the preferred and minimum sizes of a container based on the components it contains and their constraints.

Neither task is trivial for a sophisticated layout manager like TableLayout. However, the first task is a bit more difficult. Essentially, all work for this task is done in a layout manager's layoutContainer method.

In TableLayout the layoutContainer method contains the heart of the layout algorithm. The essence of this algorithm is:

- Get the container's size
- Determine the sizes of the rows and columns

- Get the container's insets
- Get the size of the container's available space
- Compensate for horizontal and vertical gaps
- Create an array to hold actual sizes in pixels
- Assign absolute sizes (must be done before assigning preferred or minimum sizes)
- Assign preferred and minimum sizes (must be done after assigning absolute sizes)
- Assign relative sizes
- Assign fill sizes
- Calculate column and row offsets for efficiency
- Indicate that the size of the cells are known for the container's current size

- Layout each component based on the row and column sizes

The hardest part of designing and implementing this algorithm was determining exactly how to assign actual row and column sizes based on the specified sizes in pixels and percentages, and the preferred sizes of components that occupy one or more cells.

Q5. What feature are you most proud of?

I don't know of a single feature that stands out the most, but I'm most proud of the algorithm that determines the sizes of rows and columns and the algorithm that determines the preferred size of the container. Both of these tasks are very complex because there is a great variety of ways in which components can be laid out with TableLayout. Yet both algorithms implement a sensible and surprisingly non-arbitrary deterministic result to both problems. The preferred size of the container isn't a guess; it is exactly the only sensible preferred size for a given layout.

Q6. Why would you recommend TableLayout compared to other layout managers like ExplicitLayout and FormLayout?

The word "best" ultimately describes an opinion, not a fact. Opinions are to some extend matters of taste and personal preferences. Certainly authors of classes tend to be biased towards their own classes over competing ones. Both Karsten Lentzsch, author of FormLayout, and I are predisposed to prefer our own layout manager over the others. After all, if Karsten didn't want anything to be different, he wouldn't have written FormLayout. And if I agreed with all of Karsten's changes, I would have incorporated them into TableLayout.

But first, let's understand what is similar in the layouts. FormLayout, HigLayout, and ExplicitLayout are based on the concepts and behavior introduced by TableLayout. I don't know if any of these layouts used actual code from TableLayout, but the concepts are clearly descended from TableLayout. So it is not surprising that nearly all the functionality is identical to TableLayout.

TableLayout and its "children" are general purpose Cartesian layout managers. By this, I mean that all of these layout managers essential use a Cartesian coordinate system (think x-y coordinates) with a c0 super-imposed grid. It is possible to have a layout manager that is non-Cartesian. For example, a layout manager could use polar coordinates to arrange components in a ring or curve pattern 1f40 . In general, though most layouts that you want to make for real applications are Cartesian because the Cartesian system is the most efficient way of using screen real estate.

Barbalace's Cartesian Layout Theorem states, "Any layout that can be accomplished by any proper general purpose Cartesian layout manager can be accomplished by every general purpose Cartesian layout manager." This means that layout that you can make with GridBagLayout, TableLayout, or FormLayout can also be made with each of the others. Perhaps Karsten disagrees with this statement, but I challenge him or anyone else to produce a concrete example of a layout in FormLayout that cannot be done in TableLayout or (given enough time and aspirin) GridBagLayout. The three layout managers have equivalent basic functionality. This is not a matter of opinion, but of mathematics.

However, clearly it is easier to use TableLayout or FormLayout than it is to use GridBagLayout. Also, both TableLayout and FormLayout add functionality above and beyond the actual laying out of a container. TableLayout adds the ability to dynamically insert and remove rows and columns like a spreadsheet. FormLayout adds the concept of dialog units. These are bells and whistles that do not change the fact that all Cartesian layouts can be accomplished by any of the general purpose Cartesian layout managers.

Ultimately, which layout manager the developer likes best is determined by his coding style, which bells and whistles he likes or dislikes, and subjective personal preferences. The developer should consider the following when choosing.

ExplicitLayout adds support for some non-Cartesian placement of components. It is not a general purpose non-Cartesian layout manager, in that there are an infinite number of non-Cartesian layouts not addressed in ExplicitLayout. I do not think it is possible for a layout manager to address all possible layouts in all possible spaces. This is related to Turing's Unsolvability Theorem. Basically, a general purpose layout manager can only handle a first order of infinity number of layouts, whereas, there are a second order of infinity number of possible non-Cartesian layouts.

From what I have seen, ExplicitLayout does seem to meet the definition of a general purpose Cartesian layout manager. So it can implement any layout that TableLayout, FormLayout, or GridBagLayout can. However, its additional functionality comes at a heavy price. The code required to use ExplicitLayout is more complicated than the code needed for TableLayout or even FormLayout. Unless a developer is using the non-Cartesian features, I would recommend against using ExplicitLayout.

There are a number of objective advantages that TableLayout still maintains over FormLayout, HigsLayout, and ExplicitLayout.

1. Ported to Eclipse SWT.
TableLayout was ported to Eclipse's Standard Widget Toolkit or SWT under the name LatticeLayout by Craig Raw. SWT is an alternative to the Java AWT framework (including Swing). SWT does not use the AWT framework, so AWT layout manager cannot be used to layout SWT controls in SWT containers. The class hierarchy is completely different. So using TableLayout gives the developer the option of using SWT instead of AWT.

2. Persistent Delegation
The persistent delegation mechanism was introduced in JDK 1.4 to save and load frames as XML files. To my best knowledge TableLayout is the only layout manager that implements this functionality. GridBagLayout does not even implement this.

3. Component Orientation
Component orientation is used to support bi-directional text. Language like Hebrew are written right-to-left. At first you may think this should only affect text controls like labels and input boxes. However, the Java platform does provide a framework that layout managers should use to support component orientation. Basically, components may have to be laid out in right-to-left order. So your OK button may have to move to the right side of you cancel button if the user switching component orientation. To my knowledge only FlowLayout and TableLayout support this feature.

TableLayout has two new justifications, leading and trailing, to accommodate component orientation. Leading justification means that a component is aligned on the leading edge (left for left-oriented languages, right for right-oriented languages). Trailing justification has the opposite effect: right for left-oriented language and left for right-oriented ones. TableLayout will dynamically adjust the layout of a container at runtime if the component orientation changes. Furthermore, this support was added without compromising backward compatibility with older versions of the JDK that do not have the concept of component orientation.

4. Proper handling of cell-spanning components
TableLayout uses preferred and minimum sizes of components that span multiple rows or columns in the calculation of the sizes of those columns/rows. So when components span cells, TableLayout still can calculate the proper preferred and minimum size of the container. Karsten wrote that his FormLayout does function properly in this area.

Karsten wrote, "There's a weakness in the FormLayout that may require an API extension. Components that span multiple columns or rows do not affect the column width or row height resp., but can in some cases expand the container. I'm looking for a means to let the layout grid honor these components that is both powerful and easy to understand. See item #3.5 in the accompanying FAQ for details and a workaround."

To be fair, this was a problem I had to think hard about when I decided to allow components to span cells. It was not a trivial problem to solve because some columns a component occupy may have a relative constraint. Furthermore, component A may occupy columns 1, 2, and 3 while component B occupies columns 2, 3, and 4. Complications like this makes the task of finding a non-arbitrary solution that works for all cases difficult. If the guts of FormLayout is derived from the guts of TableLayout, Karsten may be able to apply my solution to FormLayout. If not, I would advise caution when applying a fix and testing extensively because this problem has some very subtle and important consequences that are not obvious.

5. Simple API
TableLayout's API is much simpler and has far fewer classes to understand than FormLayout.

6. Smaller Footprint
TableLayout is distributed in a much smaller jar file: 10.1 KB TableLayout vs 1.07 MB FormLayout. This is important for Internet applications, wireless networks, hand-held devices, and other areas where bandwidth or memory is constricted.

7. Easier to Use
Both TableLayout and FormLayout have a constraint class for specifying constraints in verbose and being use for RAD builders. Both layout managers allow the developer to specify this constraints with strings in a form of short-hand. This is particularly important for developers not using RAD builders. TableLayout's string specification is simpler than FormLayout's.

I have found five features that Karsten wrote that FormLayout supports that TableLayout does not. I will address each of those features and why it did not make the cut into TableLayout. I apologize in advance to Karsten if I misinterpret anything he wrote.

1. Default column/row alignments
FormLayout allows a column/row to have a default alignment that is specified to each component whose alignment is not set. I believe this goes against the Java philosophy of having only the best method.

In TableLayout, a component has the default alignment of full in each axis. I believe this is more consistent with the Java core classes. Objects tend to have default properties specified in their class. In the case of components, a null property means use the parent's value for that property (e.g., font). A column is not the parent of a component. The component's getParent() method returns its container.

Using a default alignment assigned to a column/row is just another way of assigning an orientation. Minor convenience at the cost of needless complexity.

2. Cell Insets
FormLayout supports cell insets, whereas TableLayout does not.

There is nothing that cell insets gives you that cell spacing does not. Any layout you can accomplish with cell insets, you can also easily accomplish without them. I believe this is also a needless feature that bloats a layout manager and makes the developer have to deal with another trick.

3. Different Constraints Specification
In regards to TableLayout, Karsten wrote, "Column and row specifications are encoded with numbers that are categorized by their type to express different specification types whereas FormLayout uses implementations of Size or a string encoding." Karsten considers this to be "a weaker layout specification."

I disagree with this statement. Both TableLayout and FormLayout have nearly identical constraint classes. com.jgoodies.forms.layout.CellConstraints looks like it was copy and pasted from info.clearthought.layout.TableLayoutConstraints.

There are only three differences between CellConstraints and TableLayoutConstraints:

- CellConstraints has cell insets
- CellConstraints does not have leading and trailing justification
- CellConstraints renames full justification to fill

However, Karsten appears to be writing about the string short-hand for constraints. I agree that TableLayout's string short-hand is simpler, but not weaker. I would say it is more readable. In any case, the constraint classes are nearly identical.

4. Column/Row Groups
This is the feature of FormLayout that I have given serious thought to implementing in TableLayout. But I'm not quite sold yet. The idea is that the developer might want to have rows 1, 3, and 5 all the same height even thought they have different classes of components.

In the case where you have the same kinds of components, like a Label followed by a textfield, a row group would give you nothing. Just set the row size to be TableLayout.PREFERRED.

A row group would only come into play if you have different kinds of components or components using different fonts in two rows that you want to be the same height, but you did not want to use a fix height. Let's say you have one row with a label and textfield and another row with a textfield and pushbutton.

The question becomes what do you want the common height to be? One answer is to make the height equal to the maximum of the preferred heights of the two rows. But that is indeed a fixed size. Just calculate the maximum preferred height of the components you are using and set the row height to that. Of course, the developer might decide that the common height should be something else in order to make the GUI visually appealing, or to make it look symmetric, or to visually align things.

This sounds like application-specific logic that belongs in the application, not the layout manager. If there is more than one way to decide how to lay out the components, that decision should be made by the application using the layout manager rather than the layout manager itself. At best column/row groups are just another way of doing something that can be done already. At worse they make an assumption about what the user wants instead of letting the user be explicit.

5. Capping between Minimum and Preferred Sizes
Karsten wrote, "TableLayout lacks the FormLayout’s default component size that shrinks components from preferred size down to minimum size if the container space is scarce. Columns and rows have constant or component size or grow; you cannot combine these options in TableLayout and cannot specify resize weights."

I am not sure what Karsten means by this. I'm surmising that FormLayout has a feature that causes components to shrink from their preferred size to their minimum size as the container shrinks.

Assuming that I am interpreting Karsten correctly, there are several issues that come to mind. The first is that the word "scarce" is vague. It sounds like FormLayout is making a judgment call about when it is appropriate to start shrinking a component. Judgment calls are inherently arbitrary to at least some degree. I believe that a layout manager should only implement non-arbitrary, deterministic behavior that is easy for a programmer to understand. If the programmer ever asks, "why did that happen?" then something is wrong.

However, far more importantly FormLayout is attempting to impose both a minimum and a maximum size on components. If I understand this correctly, this is a very bad thing.

In TableLayout, it is impossible to specify contradicting constraints. Every possible set of components, constraints, and container sizes has a well-understood, deterministic solution that does not violate any constraints. I call this the well-behaved constraint property. It is not a trivial property to guarantee for a sophisticated constraints-based layout.

One day a developer emailed me a request to have TableLayout enforce the maximum size of a component using a row/column size similiar to the constant TableLayout.PREFERRED or TableLayout.MINIMUM. The user requested this because in a recent JDK, Sun added a method called getMaximumSize() to the Component class. The idea is that a component could say that it should be no larger than a certain size.

All this sounds nice until you scratch beneath the surface. In a long letter back to the developer, I explained why it is mathematically impossible to constrain components to both their maximum and minimum sizes in a general layout. Without going into all the details, the idea can be prove 1f40 n as follows. Add components cSmall and cBig to row 1. cSmall has a maximum size of 10x10. cBig has a minimum size of 100x100. What can the height of the row be to honor both the minimum and maximum sizes? In other words, what integer is less than 10 and greater than 100? None. Therefore, there is no solution.

In general, there will be conflicts between the minimum size of one component and the maximum size of another. In TableLayout, setting a row size to PREFERRED will ensure that every component contained (at least in part) by that row will be at least it's preferred height. No layout manager can make that guarantee and also guarantee that the component would not exceed a maximum height for all components in the row. This is simply a conflict of desires. Since it is impossible to fulfill all desires in a conflicting set, TableLayout explicitly states that the desires of the row/column come first and then the lower bound of the component's desire is respected if possible.

Of course, it is possible to respect both the maximum and minimum sizes of a component by disregarding the maximum and minimum sizes of other components in the same rows/columns. Similarly, we can use the component's preferred size in place of it's maximum size and have the same analysis. It sounds like FormLayout is attempting to fulfill both an upper and lower constraint, which means that it will at least one of these restraints for some components when there is a conflict. How FormLayout would resolve such a conflict is not obvious. TableLayout just avoids the conflict all together and thus preserves a well-defined behavior for even fringe cases.

6. FormLayout supports dialog units

Well, this is an area of controversy. First we should tell everyone what dialog units are, for those who didn't go through the hell of Microsoft GDI programming. One day Microsoft decided that a dialog should resize itself based on screen resolution, so a dialog that looks reasonable at 640×480 will look equally reasonable at 1600×1200. Sounds like a good idea. Unfortunately, Microsoft never quite got it right.

First off, dialog units only apply to dialog boxes because their definition depends on a dialog box's font. Second, dialog units only apply to dialog boxes that use a font. Third, dialog units only apply to dialog boxes that use only one font. As soon as you use more than one font, you have to answer the question of which font is used to define dialog units.

If you're lucky enough to meet all these requirements, you can define a dialog unit as follows. A base unit width is the average width of some characters in the font. Which characters? Well, that's a point of contention. Microsoft likes to use the capital and lower case letters in English, but the Chinese don't like that. A base unit height is the height of the font being used. A dialog unit width is one fourth of a base unit width and a dialog unit height is one eighth of a base unit height. If you're not confused yet, here's how you calculate the dialog units.

   void CAboutDlg::OnPaint()
   {
       CPaintDC dc(this); // device context for painting

       CFont* pFont = GetFont();
       CFont* oldFont = dc.SelectObject(pFont);

       TEXTMETRIC tm;
       dc.GetTextMetrics(&tm);
       int baseUnitY = tm.tmHeight;

       CSize size;
       size = dc.GetTextExtent
           ("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz", 
            52);
       int baseUnitX = (size.cx / 26 + 1) / 2;

       dc.SelectObject(oldFont);

       int dialogUnitX = baseUnitX / 4;
       int dialogUnitY = baseUnitY / 8;
   }
   

Well, isn't that nice. But it sure ain't Java. Of course, Java has its own API to query font metrics, so you could implement dialog units in a Java application. Just don't expect your dialog units to match up with a .NET application's dialog units, or another Java application's dialog units, or even the dialog units in another JFrame you opened in the same process.

The developer should realize that dialog units are a Microsoft Windows specific approach to designing GUIs. Sure you can apply any Microsoft approach to other platforms, but usually people don't and such is the case with dialog units. Although old time GDI and modern .NET programmers use dialog boxes, there are GUI developers that think the Microsoft approach flat out stinks. Must vocal in this opinion are the Macintosh developers, but then again they hate everything Windows.

There are some noted problems with dialog units. They do not address raster images such as the icons used in Windows. A 16x16 image looks create at 640x480 resolution, but is nearly invisible at 1600x1280. If you scale up the image, it looks terrible. The Macintosh developers are laughing that Window still uses raster icons while Mac OS uses vector icons that scale in the same manner as fonts and Shockwave animations.

Another problem is that dialog units are really implemented correctly in Windows anyway. The idea was that if you changed resolution, everything would scale appropriately. In fact changing the resolution on your Windows based PC does not cause any dialog boxes to resize. Compare the bitmap images of the Display Properties dialog (right click on desktop properties) before and after you change resolution. Screen capture the window and compare the image of the dialog on two different resolutions. The image is the same and the dialog appears smaller on the larger resolution. So do not think that using dialog units will cause you GUIs to look good on all resolutions. Scaling is not applied when the user changes resolution, but rather when the user changes the global DPI settings in the advance display properties dialog.

Dialog units are a Windows-centric approach to designing a window that looks good at various resolutions. Some people love them, while others hate them. But they do go against the platform-independent goal of Java applications. If the developers of Java thought dialog units were a good idea, then there would have been dialog units in the AWT. Instead Sun gave us a different way of accomplishing the same goal.

The Java way of scaling as the DPI settings change is to use the preferredSize of components. If the components have text then their preferredSize methods will query the font metrics which will encompass the change in DPI settings. If you want non-contextual components or gaps to scale with the DPI, then you have two choices. For a custom control that behaves like an analog dial, just have its getPreferredSize method return a font height multiplied by some value. Don't use both the height and width values of fonts because the aspect ratio could in principle change. The second way is to give a row or column a size proportional to another row or column that has a text component. For example, layout.setRow(1, layout.getRow(3) * 0.2); This is the Java equivalent of a dialog unit.

I see TableLayout as being a mature package. As the JDK adds new ideas to the AWT framework (and hence Swing) like component orientation, I will add them to TableLayout in such a way as to not compromise compatibility with older JDKs. Perhaps once in a while someone will come up with a great idea to add to TableLayout, but I think all the really good ideas have already been included.

In short I see TableLayout as being in a stable state that will require little change, and that's really what you want from a layout manager.

I might make an official SWT port of Tablelayout, as oppose to the unofficial LatticeLayout port. Since TableLayout uses the collections framework, it requires JDK 1.2 or later. Theoretically, I could get it to run on JDK 1.0 again like it did when I used my own linked list classes by adding an optional support Jar that has just the collections features used by TableLayout. I've toyed with the idea of doing that, but who uses JDK 1.0 or 1.1 anymore? They aren't even support by Sun anymore.

I think the real changes that affect TableLayout will be it's incorporation into better RAD builders. Right now both TableLayout and FormLayout are support by various commercial and free RAD builders. However, I still code my GUIs by hand because the RAD builders are not easy to use and the code they generate is ugly.

I think that a RAD builder should just generate an XML file that acts as a skin for an application. An application can load the skin with one line of code:

    Skin skin = Skin.load(urlToSkin);

Then the application can query the skin for whatever controls it needs in a fashion like:

    Button myButton = (Button) skin.getObject("button close");
    myButton.addActionListener(this);
    Frame frame = (Frame) skin.getObject("main frame");
    frame.show();

That way the GUI is completely separate from the application itself. An application could have an arbitrary number of skins and even use more than one skin at a time. The GUI isn't implement in code, but rather in data. That data is used by general purpose classes to create the GUI.

Q8. Where do you see desktop Java development going the next few years.

I see Java and .NET fighting for dominance. .NET is more ubiquitous on client desktops, but Java is certainly making it easier to deploy on client machines and is fighting for a presence on every computer.

I think eventually web-based interfaces will go out of style and people will want more sophisticated client applications that are Internet connected and can do SSL, tunneling, and socks. XML will replace HTML as it is doing now. If the World Wide Web had been invented today, it would be based on XML, not HTTP. When that happens, your client won’t have to be a Javascript-awared browser.

Resources:

FormLayout

TableLayout

ExplicitLayout