Showing posts with label GUI. Show all posts
Showing posts with label GUI. Show all posts

Friday, May 01, 2009

DesignGridLayout: where do we stand?

It's been a long time I haven't blogged on DesignGridLayout. Several events have concurred to this lack of communication:
  1. I have bought a brand new notebook (for those interested: that's a Sony VAIO Z)!
  2. It's taken me a long time to have DesignGridLayout tests run on both my old notebook (Windows XP) and my new one (Vista)
  3. I have plaid with Hudson on my old notebook to setup a continuous build for DesignGridLayout
Now that all that works (after a lot of pain for the second point, and thanks to the active help of Alex for quickly improving FEST "specially" for me), I can finally resume my work on the project.

Where do we stand?

Version 1.2, which I am currently working on, shall have the following features:
  1. alignment synchronization of multiple panels (all using DesignGridLayout): particularly useful to make smooth panels transitions in Tab panes and Wizards.
  2. optional consistent baselines spacing between consecutive rows (only for fixed height rows).
  3. addition of a new API to notify DesignGridLayout of special components behavior with regards to vertical resize.
For these features, I have already made a big refactoring of the source code.

Enhancement #2 above is already implemented in Subversion trunk, here are 2 screenshots comparing the same layout with and without consistent baseline spacing, respectively:

Note the consistent spacing between labels baselines for all rows but the second one (because it has variable height) and the last one (because it has an emptyRow() before it to visually separate that row from the previous one).

Without consistent baselines spacing, all vertical gaps conform to the values provided by the installed look & feel, but due to different heights of components and different vertical gaps, the inter-row spacing doesn't look consistent and is not very eye-friendly (this is particularly true when observing the column of labels).

Regarding synchronization of alignments between different panels (enhancement #1 above), the following screenshots help showing what works today (excerpts from DesignGridLayout automatic tests).

The example below is a dialog with a tabbed pane, embedding two different tabs. The first 2 screenshots show both tabs, built with DesignGridLayout, without synchronization.

Please note that there are no horizontal or vertical alignments between both tabs, this is particularly noticeable when running the application and changing from one tab to the other.

Now, let's add just one line of code to the layout building code, as follows:
Synchronizer.synchronize(layout1, layout2).alignGrids().alignRows();
Then the screenshots become different (note that I have put the 2nd tab both on the right side and on the bottom of the first tab so that you can easily check alignments in both directions):

You can notice the alignment of the origins of both columns of fields, and you can also check that all rows baselines from both tabs are aligned with one another.
This example is particularly interesting due to the use of Java -default- Metal look & feel, in which different kinds of components have different heights (compare the heights of JTextField and JComboBox); other look & feels may have consistent heights for all components, which would not show the difficulty of aligning each and every row from one tab to its matching row in the other tab. I am not sure other LayoutManagers can do that, I haven't checked yet though.

Back to DesignGridLayout V1.2 schedule, I still have some work with:
  • baseline synchronization
  • new API for vertical resize behavior customization (point #3 above)
  • layout calculation optimization (avoid multiple recalculation)
For DesignGridLayout 1.2, I plan to release a beta with new features and the new API so that I have time to polish it before a release candidate. Here is the expected schedule:
  • End May: 1.2 beta 1 out, beta testing will last one month
  • End June: 1.2 rc 1 out, followed by final release after 2 weeks (or 2 weeks after latest rc if bugs are reported)
What's next?

Later, for V1.3, I foresee enhancements to non-grid rows API & functionality:
  • possibility to separate 2 components with unrelated gaps
  • smart positioning of standard buttons (OK, Cancel...) based on the runtime platform
  • make component sizes consistent across several rows (currently, sizes are consistent inside individual rows only)
It's hard to predict what a release date could be, but since I don't see too much complexity in these features (but as usual, the difficulty will be in finding the right API for them), I think it should be possible to have a first release candidate less than 2 months after final release of V1.2, around September-October.

Sunday, February 15, 2009

Announce: DesignGridLayout 1.1 released!

Two weeks after the fourth release candidate of DesignGridLayout 1.1 (1.1-rc4), I have decided to release the official final 1.1 release.

Compared with previous official 1.0 release, this version brings the multiple rows span components feature, in addition to a few enhancement and bugs fixes:
  • fixed several problems with baseline alignment (only on Java 5): issues #3 and #27
  • fixed a problem with smart vertical resize of JList (issue #28)
  • fixed an exception with multi-grid feature (issue #26)
  • fixed an exception when creating a row but adding no component to it (issue #30)
  • fixed a bad look with grids having just a label but no component (issue #31)
  • optimized the size of the example jar (removed all screenshots that are used during automatic tests)
  • completely refactored the examples application
  • added an option to disable "smart vertical resize" feature (issue #34)
Now I can go back to work on next release (1.2). Future version 1.2 will have two major features:
  1. Synchronization of several layouts: with this feature it will be possible to ensure correct alignments (vertical or horizontal) across several panels using DesignGridLayout. This will be particularly useful for use inside JTabbedPanes or in Wizard dialogs.
  2. Extension API to customize policies related to components vertical resize (the current -internal- policy recognizes only vertical JSliders and JScrollPanes as variable height components, but some users have expressed the need to recognize also other specialized components)
First enhancement is on the way but will take some more time since it is a quite complex feature. I intend to release a 1.2-beta with this feature only, for users to check if it fits their needs well in synchronizing alignments. 1.2-beta is expected by mid-March if I can progress well.

If you're not afraid of using a "work-in-progress" version, you can get it from Subversion trunk, build it according to the instructions on the web site, then take a look at the new Synchronizer class.

I hope to have a first 1.2 release candidate by end of March or early April.

Thursday, January 15, 2009

Swing UI layout: best practices

Today, I will show my best practices about designing Swing UI forms.

This post focuses exclusively on UI layout, not on other -common- UI problems such as MVC, binding, actions... I may post about all these in future posts however.

This is quite a long post, but this is partly due to screenshots showing do's and don'ts.

The best practices exposed here use my DesignGridLayout as an example, but most of them (if not all) should be suitable for most modern LayoutManagers (like GroupLayout) and even some old-fashioned ones (like GridBagLayout).

For each practice, I'll show screenshots before/after the practice along with code snippets.

Code presented here works with Java 5 (baseline alignment may require the additional swing-layout library) and Java 6.

1. Always use Baseline alignment for components that have a meaningful baseline
Most modern LayoutManagers have an option to align components in a row on their baselines.
DesignGridLayout gives you no choice: baseline alignment is automatic (and cannot be disabled).

Without baseline alignment

With baseline alignment


2. Avoid using JEditorPane and JTextPane
Most Swing components in Java 6 have a meaningful baseline. However, some seem to have no correct baseline (for no apparent good reason). JEditorPane and JTextPane are examples of such components. This means that it is impossible to have these components aligned on their baseline.
Thus, when using those components, you don't know exactly how they will be aligned with other components in the same row; this will depend on the LayoutManager you use.
DesignGridLayout aligns these components on the top of their "box", which is not very beautiful, but nothing better is possible until those components are able to return a decent baseline value.

Screenshot sample

Hence the best is to not use such components at all if possible. You should prefer JTextArea when it fits your needs (no need for rich text style).

3. Call setColumns() on JTextField and JTextArea
Most LayoutManagers use (or can use) components preferred size to perform an optimal layout.
In Swing, many components are able to determine the optimal preferred width based on their content. For instance, JLabel, JButton, JList, JTable belong to this category and for these you don't need to explicitly set the preferred width.
For JTextField and JTextArea, however, this is not the case, by calling setColumns() (or using the constructor that takes a columns argument), you make sure these components will have the right preferred width.

Without setColumns()

With setColumns(10)

4. Put all components that can vary in height in a JScrollPane
Some components allow you to display several "lines" of information (JTable, JList, JTextArea...) In most cases, it is impossible to know exactly how many lines will be displayed. Hence by putting those components in a JScrollPane you make sure the user will be able to vertically scroll to see all available data.
In addition, some components (such JTextArea) were specifically coded to be embedded in a JScrollPane, if you don't, they will look ugly (e.g. no border).

Without JScrollPane

With JScrollPane

5. Call setRows() on JTextArea
Like setColumns(), it will help optimize the preferred height for the component (by default its preferred height is equivalent to the height of 1 line of text).

Without setRows()
Note how the JTextArea looks like a simple JTextField!

With setRows(4)

6. Call setVisibleRowCount() on JList
As for JTextArea where you should call setRows(), JList has a useful method that enables you to set the preferred number of rows to be visible, which will then automatically compute the preferred height (depending on the actual content of those rows).

Without setVisibleRowCount()

With setVisibleRowCount(4)

7. Call setPreferredScrollableViewportSize() on JTable
Unfortunately, JTable does not have a setVisibleRowCount() method as in JList. Hence, you need to find another way to set a preferred size (in terms of number of rows) to the JTable but avoid that it displays "partial" rows. The default JTable preferred height shows 20 rows (independently of the actual number of rows in the model) which is generally more than what you would want to show.

The practice I show here has worked quite well for me:
static public void setTableHeight(JTable table, int rows)
{
int width = table.getPreferredSize().width;
int height = rows * table.getRowHeight();
table.setPreferredScrollableViewportSize(new Dimension(width, height));
}

Without setPreferredScrollableViewportSize()

With setPreferredScrollableViewportSize()

8. Force minimum width on JTextField
In best practice 3 above, I have shown how to set a correct preferred width for JTextField, this will allow the LayoutManager to show the panel in its preferred size with correct sizes for all fields. However, when resizing the panel, the minimum size is generally used by the LayoutManager to make sure that components never shrink smaller than this minimum size.

Unfortunately, JTextField minimum width is meaningless and generally needs to be set by hand to avoid ridiculously small fields when the user shrinks the panel width.

However, you should always avoid setting sizes in pixels to avoid bad layouts on different kinds of monitors (you should strive to be resolution independent so that your UI will look good on low and high DPI screens).

What I do is to use setColumns() again but as an intermediate step to setting the minimum width:
static public final void setTextField(JTextField field, int min, int pref)
{
field.setColumns(min);
field.setMinimumSize(field.getPreferredSize());
if (pref != min)
{
field.setColumns(pref);
}
}

Before (trying to shrink width as much as possible)

After

9. Don't use TitledBorder to separate groups of information
A lot of people use Swing TitledBorder around several sub-panels in order to separate groups of information inside a form. The major problem with this approach is that every sub-panel has its own LayoutManager, and LayoutManagers are disconnected from each other, hence you are likely to have bad alignment between sub-panels:


If you follow Karsten Lentszch's advice, you could use a JLabel and a JSeparator instead:


Here is how you can do it with DesignGridLayout:
_lblInfo.setForeground(Color.BLUE);
layout.row().left().fill().add(_lblInfo, new JSeparator());
layout.row().grid(_lblFirstName).add(_firstName);
layout.row().grid(_lblSurname).add(_surname);

layout.emptyRow();
_lblOffice.setForeground(Color.BLUE);
layout.row().left().fill().add(_lblOffice, new JSeparator());
layout.row().grid(_lblCompany).add(_company);
layout.row().grid(_lblAddress).add(_address);
layout.row().grid(_lblZip).add(_zip);
layout.row().grid(_lblCity).add(_city);

10. Set consistent sizes for all JButtons in a row
Swing automatically calculates JButton preferred size based on its content (text, icon). However, this means that all buttons in your form will have a different width!
Depending on the LayoutManager you use, you may have to individually set the preferred sizes of all buttons, based on the preferred size of the largest one.

Most modern LayoutManagers will do that for you, though. Here is an example with DesignGridLayout:
layout.row().center().add(new JButton("OK"), new JButton("Cancel"));


11. Special considerations for components spanning several rows
Some LayoutManagers (including DesignGridLayout) allow you to define components (like JList or JTable) to span several rows.

When I use such components, I make sure that their preferred height (which defines the height of the JScrollPane in which they will be embedded) is larger than the total height of the rows that are spanned. Why so? Just a matter of taste. See for yourself:

With height smaller than spanned rows

With height larger than spanned rows

Conclusion

For some of these best practices, it may prove useful to create a class with a few helper methods (such as setTableHeight() and setTextField() above) or create a factory for your components.

If you follow those best practices, you should achieve a better user experience in your UI forms. DesignGridLayout, if you use it, will take advantage of these best practices in an effective way.

Hope that this can be useful to all Swing developers. Any comments are welcome.

Wednesday, January 07, 2009

Announce: DesignGridLayout 1.1-rc1 released!

After one month of heavy work, I am proud to announce the first release candidate of DesignGridLayout 1.1.

This version brings one major new feature and fixes a few bugs:
  • new support for components to span several rows (RFE #10)
  • fixed problems with baseline alignment in JRE5 (issues #3 and #27)
  • fixed a problem with smart vertical resize of JList (issue #28)
  • fixed a potential exception that could occur in very specific layouts (issue #26)
In addition, the examples demo application has been completely rewritten in order to show all DesignGridLayout features along with description and source code. This application can now constitute a very effective way to learn DesignGridLayout from scratch in no time. It is also useful to current DesignGridLayout users who want to learn new features.

The new support for components spanning multiple rows allows you to define layouts that look like this:


The source code for that is quite straightforward:
layout.row().grid(label1).add(field1).grid(label2).add(list);
layout.row().grid(label3).add(field3).grid().spanRow();
layout.row().center().add(button);
It is important to notice that "smart vertical resize", one of DesignGridLayout unique features, is still active on components spanning multiple rows. You can see on the following screenshots the same layout as above during vertical resize (note the list always show only entire rows and never truncates any row):





Of course, you can also see this behavior "live" if you launch the examples application!

I consider this release candidate to be ready for production and, if no bugs are reported, I expect a final release in less than one month.

Enjoy!

Wednesday, November 05, 2008

Announce: DesignGridLayout 1.0-rc1 released!

I am particulaly glad to announce the first release candidate of DesignGridLayout V1.0.

DesignGridLayout is a Swing LayoutManager, revolutionary by its API, simple but powerful. Its main advantages are:
  • Good looking forms (alignment, spacing, sizing, visual balance): this is entirely taken over by DesignGridLayout itself without any special hint from the developer
  • Reduced learning curve for developers, thanks to its fluent API which is simple, effective, compile-safe and IDE code-completion friendly
  • No graphics designer needed: the API is the graphical designer
  • Readability and maintainability: you can literally "visualize" the layout by browsing the code that sets it up; inserting a new row of components is done by simply inserting a new line of code in the layout setup code...
  • Free: the project is open source and released under Apache License 2.0
Version 1.0-rc1 is available here or through the java net maven 2 repository (for more info, you can check my previous post and replace "0.9" with "1.0-rc1").
This version brings the following improvements:
  • #13: support for multiple groups of fields, each with its own label column
  • #5: smart vertical resize: DesignGridLayout automatically determines which rows should grow vertically and also make sure that components height is suitable to display an entire line of information (useful for JList, JTable, JTextArea)
  • #18: smarter horizontal resize behavior: now DesignGridLayout won't resize components under their minimum size
  • #9: automatic support of right-to-left text orientation based on Locale
  • #16: smarter gaps for empty rows
  • #15: resolution independence
  • #20: fixed ugly layout problem when container has a border
  • #12: now setLayout() is automatically called by DesignGridLayout constructor
Please note that V1.0 required API changes that I could unfortunately not keep compatible with previous 0.9 release. This should be the last time that happens (V1.1 should only extend the current API).

I consider the current version ready for production as the current test suite of DesignGridLayout is quite comprehensive and covers all its features.
However, I have decided to prepare a release candidate to give myself a chance to fix any problems that users may find but that I could not discover by myself (in particular, problems related to platforms that I don't have: MacOS-X, Linux, Solaris).

If needed, I will create further release candidates. I will wait about one month after a rc until I cut a final release.

What's next?
  • first of all, I'll get some rest;-)
  • then I'll spend some weeks on my other open source project, guice-gui
  • finally I'll start working on DesignGridLayout V1.1, which should include just one improvement (issue #10: support for components spanning several rows) which should be released as a Christmas present;-)
Enjoy it and don't hesitate to report any problems or enhancements!

Thursday, September 25, 2008

DesignGridLayout news

Two months ago, I had announced my participation to the OSS project DesignGridLayout.

As a brief reminder, DesignGridLayout is a LayoutManager for Java Swing GUI, which main advantages are:
  • Good looking dialogs (alignment, spacing, sizing, visual balance): this is taken over by DesignGridLayout itself without any special hint from the developer
  • Reduced learning curve for developers, thanks to the fluent API which is, at the same time, simple, effective, compile-safe (no cryptic strings to express the layout) and IDE code-completion friendly
  • No graphics designer needed: the API is the graphical designer
  • Readability and maintainability: you can literally "visualize" the layout by browsing the code that sets it up; inserting a new row of components is done by inserting a new line of code in your layout setup code...
During the past 2 months, after struggling with the switch from CVS to SVN, I have finally finished taking the project over.

In the past few days, I have checked in the latest source code into SVN, and updated the web site.

Several things have changed in this project (as compared with previous 0.1.1 version):
  • License: the original GPL has been changed to ASL 2.0, much more open
  • Build: now the project uses maven 2 for the build and the site generation
  • Package: the old "zappini.designgridlayout" has been changed to a more standard "net.java.dev.designgridlayout"
  • Source code: it has been refactored to improve the API and ease future evolutions
  • Issues: all known bugs have been fixed
  • API: it has been improved on several points (more on this below) such as its narrowing (in order to prevent calls that have no effect, hence potentially pollute source code using DesignGridLayout), as well as the implementation of a few enhancements
  • Javadoc: has been completely rewritten and completed for all public API, along with examples in the package description
Improvements on the API consist essentially in using different interfaces for the different "rows" created by DesignGridLayout:
  • IRow
  • IGridRow extends IRow
  • INonGridRow extends IRow
These interfaces define the exact methods available to each kind of row. Once a row has been created, you cannot change its type (e.g. from Grid to Center) as you could before, which was useless, required more calls and led to some flaws in the API (e.g. what should happen if you set the row type to Grid, then back to Center; and why would you do that?).

Moreover, in DesignGridLayout, methods that create rows have been specialized to determine upfront which kind of row is to be created:
  • DesignGridLayout#row() creates a grid row (IGridRow)
  • DesignGridLayout#centerRow() creates a non grid row, with centered components (INonGridRow)
  • DesignGridLayout#leftRow() creates a non grid row, with left-aligned components (INonGridRow)
  • DesignGridLayout#rightRow() creates a non grid row, with right-aligned components (INonGridRow)
  • DesignGridLayout#emptyRow(int height) creates an empty row, with no component at all (used for introducing vertical spacing between rows)
Other changes in the API are:
  • Removal of IGridRow#label(String) to keep only IGridRow#label(JLabel): this was motivated by the fact a LayoutManager should not create components by itself (arguable opinion, I admit); in addition, this reduces one's options for GUI i18n (one option is to use Component#getName()) to set its text, which is impossible here, since the end-developer code can not get hold of the created JLabel)
  • Row.EMPTY "component" is replaced by IGridRow#empty() methods
  • New INonGridRow#fill() added to allow extreme components to take all remaining space in the row. This is particularly useful to split groups of rows with a label and a separator (as in Karsten Lentzsch FormLayout)
  • New IRow#addMulti() method to add several components in only one grid column, which is useful when you have components that should always "stick together" (eg a JSpinner and a JLabel indicating a unit of measure)
With all these changes, all constants and enum have been removed from the previous version because they serve no purpose now.

You can find the current snapshot (named "0.9-SNAPSHOT") of this version there.

So a further question is "when will the official 0.9 version be released?". That should be short now, we should expect an official release by mid October, including uploaded artifacts to some maven repository (for developers using maven).

What's the roadmap for 1.0?

There are a couple of enhancements requests submitted here.

The main enhancement planned for 1.0 will be the support for variable height rows that would get extra height during resize; this is particularly useful for rows that include components such as JList, JTable, or more generally any component wrapped in a JScrollPane.

Another interesting feature I would like in 1.0 release is components spanning several rows. This is a particularly useful feature and I know several users have been expecting it. The difficult part here will be to define the right API for that, in order to keep this feature easy to use, easy to visualize and safe (reducing potential errors at runtime by catching them at compile-time).

Finally, 1.0 release may include some attempts at right-to-left languages support. This will depend on several factors.

In any case, if you are a DesignGridLayout user or consider it for your next Swing GUI, please take your chance and participate in the discussions on the 3 issues above, so that DesignGridLayout can keep its spirit while bringing important features common in daily GUI design work.

Of course you can also suggest other enhancements and report bugs if you find any.

You can find more details on DesignGridLayout here.

Enjoy GUI design with DesignGridLayout!

Sunday, July 27, 2008

New OSS project responsibility!

About one month ago, I have been assigned owner of the DesignGridLayout project.
I was very happy for that because:
  1. I like this project a lot (since the first time I knew it, in November 2007)
  2. But it seemed to have been dormant for more than one year
Most of the few issues open on the project were posted by me, hence I had to fix them by myself in the past.

Recently, I thought about completely refactoring DesignGridLayout source code, which I did, in order to improve its API furthermore and make it easier to enhance later on.

Since I have several improvement ideas, I have then contacted the curren project owner to ask him if he was interested in my work. His answer was that unfortunately he is much too busy to keep the project living and thus he suggested that I could become owner of the project and keep it alive! That's how it all happened!

From then on, I have started to take hold of the project and suggest important changes:
  • more open license (GPL currently)
  • upload to maven2 repository
  • switching from CVS to Subversion
  • API improvements
I truly believe that DesignGridLayout is a revolutionary LayoutManager for Swing applications but unfortunately, there was not much advertising about it so far.

If you are fed up of standard Swing layouts (GridBagLayout in particular;-)) and you find 3rd party OSS layouts a bit steep to learn, then you should definately take a look at DesignGridLayout, it is worth your (little) time!

I'll blog more about DesignGridLayout soon after I have released a new version including the whole refactored source code.