Thursday, October 09, 2008

DesignGridLayout: real-time resizing of JScrollPane


In my quest to solve the issue #5 of DesignGridLayout (namely: "Layout does not allow additional height usage after resize"), I have created a special dialog for testing my fixes for this issue. You can see a snapshot below (at default -ie preferred- size).

In this sample, I have put several rows, containing various kinds of components, of which some should be given extra height when the user resizes the dialog (eg JTable), and some should never grow taller than their preferred size (eg JTextField).

I could find out that there are only 2 categories of components that want extra height when it becomes available:
  • any Component that is set as the view of a JScrollPane (in particular JTextArea, JTable, JList)
  • any JSlider using JSlider.VERTICAL policy
Besides these, I did not find any component that should grow height when its embedding dialog is resized.

Based on these observations, I have implemented a simple internal mechanism into DesignGridLayout for distinguishing these 2 kinds of components:
interface HeightGrowPolicy
* Checks if a {@link Component} can grow in height.
* @param component the component to test
* @return {@code true} if {@code component} has a variable height;
* {@code false} if {@code component} has a fixed height.
public boolean canGrowHeight(Component component);
This interface is implemented by several classes:
  • HeightGrowPolicyMapper (allows to map different Component classes to their own specific HeightGrowPolicy),
  • JScrollPaneHeightGrowPolicy (special implementation for JScrollPane),
  • JSliderHeightGrowPolicy (special implementation for JSlider)
The mechanism itself is easily extensible because I can easily add further policies for other kinds of Components.

My first working prototype for issue #5 was roughly that simple (of course I also had to make some little changes in a few existing classes of DesignGridLayout library).

But I was not fully satisfied with it. The main reason for this was that when you extend the height of the dialog, all resizable components get a few pixels more for their height, which is absolutely ugly for a JTable, a JList or a JTextArea, because these components would then start to show, on the bottom side, some "incomplete" row or line of text.

Whenever I see this happening in a GUI application (be it made in Java or any other language) I generally get angry and immediately classify it in the category of "non professional" software.

So I inferred on some way to solve this: that is really the responsibility of a LayoutManager to make sure that whenever you resize a Container, all resized Components keep good-looking.

First I have extended the interface HeightGrowPolicy above:
interface HeightGrowPolicy
public boolean canGrowHeight(Component component);

* Computes the maximum amount of extra height that a {@link Component} can
* use.
* @param component the component to test
* @param extraHeight the amount of available extra height
* @return the maximum amount of extra height that {@code component} can use
* without exceeding {@code extraHeight}
public int computeExtraHeight(Component component, int extraHeight);
to give a chance to let DesignGridLayout know what amount of extra height a given Component will accept to keep its good look. This amount can be anything between 0 and extraHeight.

Here is the implementation for JScrollPane components:
class JScrollPaneHeightGrowPolicy implements HeightGrowPolicy
public boolean canGrowHeight(Component component)
return true;

public int computeExtraHeight(Component component, int extraHeight)
JScrollPane scroller = (JScrollPane) component;
int unit = scroller.getVerticalScrollBar().getUnitIncrement(+1);
if (unit <= 0)
return extraHeight;
// Return an integral number of units pixels
return (extraHeight / unit) * unit;

Simple isn't it? It makes use (behind the scenes) of the Scrollable interface that is most often implemented by components that are supposed to be used in JScrollPane (namely JList, JTable, JTextArea and JTree).

Provided that the preferred size of these components of your dialog is already good looking, then DesignGridLayout will ensure that they always stay this way. If you want to have proper preferred size for JTable, JList or JTextArea, you can use specific API of these components in your own code as in the following snippet:
JTextArea area = new JTextArea();
JTable table = new JTable();
JList list = new JList();

// area has preferred height to show exactly 3 lines of text

// table has preferred height to show exactly 4 rows
int height = 4 * table.getRowHeight();
table.setPreferredScrollableViewportSize(new Dimension(PREF_WIDTH, height));

// list has preferred height to show exactly 2 items (ie 2 rows)

You can try this on the Java Web Start enabled example.

Not bad!

But that's not the end of the story yet. If you play a bit with the example above, you'll see that between two actual resize of e.g. the first JTable component, the spacing between that row and the next is increasing, which is in contradiction with DesignGridLayout philosophy which promises to use the "ideal" inter-components spacing (according to the LAF/platform in use).

So I have made a second attempt, that you can experiment through this JWS example.

In this attempt, inter-components spacing is always preserved. However, to my viewpoint, resizing does not have a very good behavior (in real-time I mean):
  • first of all, the user does not "feel" that something is going on during the first pixels of his resizing action: the layout does not change at all! The user may just stop here and think that resize does not work!
  • second, a weird behavior is observed when the exact number of extra pixels is obtained during resize: all components below the first JTable seem to "hop" to a new position several dozens of pixels away from their previous one!
Hence I believe I will stick with the first solution and completely remove the second one. I could make it an option for the library users to choose, but I would not feel satisfied of giving such a possibility to create layouts with such a bad feel during resize.

What do you think?

If you want to look at DesignGridLayout code which snippets have been used in this post, you should check out the latest trunk from subversion.

Have fun!


  1. The original jars in the post had a small bug with the height of rows containing 2 different variable height components (in this sample, the row with a JList and a JTextArea).

    I have fixed the jars and updated the dialog snapshot.

  2. There are such things as custom components...

  3. Could you elaborate further your comment, please?

    I understand perfectly there are custom components but if they have variable height, they would normally be embedded into a JScrollPane, don't you think?
    If so, then DesignGridLayout will manage them well (in particular if they implement correctly the Scrollable interface) without any change.

    Do you have one concrete example of a custom component, that has variable height but that you would not embed in a JScrollPane?

    Thank you for your feedback.

  4. I'm not the OP but I have many cases where I have a JPanel that contains other components with jscrollpanes or vertical sliders. These panels do not work correctly with DesignGridLayout.

  5. Hi Curtis, I already answered your point in DesignGridLayout forums but I post it here also for the sake of giving an answer to people browsing my blog and seeing your comment.

    As suggested in the issue #35 (, one better option to using JPanels is to use "builder" classes that add components to an existing DesignGridLayout.

    Anyway, this request will be implemented in version 1.2 (no official release date yet, but I believe I can come out with a first RC by the end of February).

  6. Hello, Jean-Francois,
    What if I, say, want to add JTabbedPane that want extra height when it becomes available?

  7. Hi Dmitry, this seems to be an unusual use case.
    Indeed, I've never added a JTabbedPane inside a DGL-based panel.

    Generally I use DGL inside each tab of my JTabbedPane, and then I add the JTabbedPane to the main dialog content pane using another LayoutManager (eg Border or GridBag).

    Do you have a concrete use case for adding a JTabbedPane inside a form managed by DGL?

    In any case, you can, as a workaround, put your JTabbedPane inside JScrollPane (without any scroll bars visible); for this to work perfectly, you may have to subclass JTabbedPane to implement the Scrollable interface.

    Cheers, Jean-Francois