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.


  1. Based on your description, Alignment is right word as instead of Synchronizer for class, unless its already used in other context of api :)

  2. Well, yes and no :-)
    Alignment is already performed for components INSIDE one DesignGridLayout instance.

    Here the problem is to synchronize alignments across several DesignGridLayout instances (ie several independent panels).

    So maybe the right term would be "AlignmentSynchronizer" ;-) or to be really complete: "LayoutsAlignmentSynchronizer" or worse "MultipleLayoutAlignmentSynchronizer":-)

    I'll think about that; anyway the API may still change until the first beta can be released; for the time being I am working more on implementation issues; when I have satisfactory enough results, I'll check if I can "polish" the API a little bit then go 1st beta.

    Thank you for your comment.

  3. Oh I forgot. If you take a look at the current Synchronizer API, you'll see that it fits better than Alignment, because it is used this way (IIRC, I don't have the source right here):

    Synchronizer.layouts(layou1, layout2).alignRows().alignGrids();

    Something like that. Which shows that Synchronizer is some class that ACTs on something (layouts) to do something (alignment).
    If I used "Alignment" as the class name here, it would feel strange I find.

    Cheers, Jean-Francois

  4. I realize this is not the place to post this, but I have a question. We are considering switching our layout manager from absolute positioning. I like the look of your layout and think it would be an easy transition for our GUI. We currently use JBuilder 2005 and code the UI by hand. I am trying to use designgridlayout on a very small sample and I am getting the following exception (I have included designgridlayout-1.1p1.jar as a required library in the project):

    Exception in thread "AWT-EventQueue-1" java.lang.NoClassDefFoundError: org/jdesktop/layout/LayoutStyle
    at java.awt.Container.layout(Unknown Source)
    at java.awt.Container.doLayout(Unknown Source)
    at java.awt.Container.validateTree(Unknown Source)
    at java.awt.Container.validateTree(Unknown Source)
    at java.awt.Container.validateTree(Unknown Source)
    at java.awt.Container.validateTree(Unknown Source)
    at java.awt.Container.validate(Unknown Source)
    at javax.swing.RepaintManager.validateInvalidComponents(Unknown Source)
    at javax.swing.SystemEventQueueUtilities$ Source)
    at java.awt.event.InvocationEvent.dispatch(Unknown Source)
    at java.awt.EventQueue.dispatchEvent(Unknown Source)
    at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
    at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
    at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
    at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
    at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
    at Source)
    Caused by: java.lang.ClassNotFoundException: org.jdesktop.layout.LayoutStyle
    at$ Source)
    at Method)
    at Source)
    at java.lang.ClassLoader.loadClass(Unknown Source)
    at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
    at java.lang.ClassLoader.loadClass(Unknown Source)
    at java.lang.ClassLoader.loadClassInternal(Unknown Source)
    ... 23 more

  5. Hi, DesignGridLayout also needs swing-layout.jar in the classpath.
    Swing-layout does 2 different things depending on the Java version you use in runtime:
    - Java 5: brings baseline support to Swing components and compute platform standard margins between components
    - Java 6: just bridges baseline and margins calculations to Java 6 built-in features

    Thus, even if you use Java 6, DesignGridLayout still needs swing-layout dependency. I plan to remove this mandatory dependency only in 2010, when I drop support for Java 5.

    Hope this helps.