DesignGridLayout: real-time resizing of JScrollPane

Hi,

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;
        }
        else
        {
            // 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
area.setRows(3);

// 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)
list.setVisibleRowCount(2);

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!