How GridLayout computes Composite size - java

In an SWT application, I have a composite with a GridLayout that has two columns. The first contains labels, the second texts and checkboxes. I use TextLayouts for some of them and paint them manually (in a paint listener), so I have to manually compute their sizes. I set the computed sizes for the widgets with setSize() and set widthHint and heightHint in their respective GridDatas. GridData objects for the labels (1st column of the grid) are created with (SWT.RIGHT, SWT.CENTER, false, false) and for the widgets in the 2nd column with (SWT.FILL, SWT.CENTER, true, false). The computeSize() for the widgets returns the sizes I expect (eg. no more then 68 pixels of width for the 1st column and 128 for the 2nd).
But the computeSize() for the Composite returns a width that is much larger than I expect to see (or want), namely 253, while I expect 68 + 128 + 3 * 4 + 2 * 2 = 212 or something near to it.
The pack() on the Composite, acccordingly, makes it grow much wider than I want. I can force the required width of the Composite with the setSize(), but subsequent actions on the shell containing my composite invoke the composite's pack() anyway, so its width gets spoiled. Setting of the widthHint of the composite's GridData won't work either.
The Composite itself is a child of a upper-level Composite with GridLayout and has a GridData with (SWT.LEFT, SWT.FILL, false, true).
Why the computeSize() decides that the width of the Composite should be 253, if the widths of the widgets in the columns are computed to be 68 and 128 pixels wide and their widthHints are set correspondingly? How does it work? What does it take into account, besides the computed sizes of the child widgets? Where can I find a description of its algorithm (the source of the GridLayout's layout (Composite composite, boolean move, int x, int y, int width, int height, boolean flushCache), which actually computes the size, is rather complicated and difficult to understand) ?
How can I make the layout managers keep the required width of the Composite while changing layout of the parent Composites, including the Shell (on resizing, font changes etc)?

GridLayout is full of surprises. If you are not dogmatically stuck to it, I recommend switching to FormLayout. This is much more powerful and gives you much much more control over the final result of your UI. It is a paradigm shift compared to GridLayout, but it is very much worth learning it.
With FormLayout, you can use the dimensions of the parent, or the position and dimensions of any sibling Controls (ie. Controls sharing the parent) for positioning and sizing controls. It's like declaring a couple of layouting constraints per control and the manager will do its best to satisfy your wishes.
Here is a tutorial for you to get you started. It introduces you to FormData, which declares four anchor points (top, bottom, right, left) and the FormAttachments which define the constraints in a FormData object.
For your problem, you can layout the first column as using eg. 40% of the width of the parent, with each row being placed below the label of the previous row. The controls of the second column are placed relative to their label (on their left) and the label or control of the previous row (on their top).
Now what seems to bother you is the width of some of the controls in the second column. In FormLayout, you can set an explicite constraint for the right anchor, either by declaring it to be eg. at 100% width of the parent (starting from the 40% right anchor of the first column) which will then rely on the layout of the parent's parent, or by setting the right anchor as an absolute margin in pixels counting from the right edge of the first column. This can be done by referencing the label in the first column, but switching the alignment. This is necessary because by default, a relation from the right anchor of Control A to a sibling B will automatically use the left side of B. In code, this second possibility will spell out like that:
FormData fd;
//row 1
Label lblC1R1;
Control ctrlC2R1;
//row 2
Label lblC1R2;
Control ctrlC2R2;
...
fd = new FormData(); //for ctrlC2R2;
fd.top = new FormAttachment(lblC1R1); //top edge clings to (y-coord of) bottom of row 1 label (could reference row 1 control, too)
fd.left = new FormAttachment(lblC1R2); //left edge clings to right side of row 2 label
fd.right = new FormAttachment(lblC1R2, 200, SWT.RIGHT); //right edge is defined as a distance of +200 px from *right* side of row 2 label (by default, it would use the left side)
//we don't set fd.bottom, so the control may grow or shrink with ie. font size
ctrlC2R2.setLayoutData(fd);
This will fix the width of the second column control to 200px starting from the right side of the first column, no matter what the control says about its preferred size.

Related

How can SWT layout resize (grow/shrink) based on content

I have an explorer in my RCP application to which I added an inner composite with a RowLayout to show various category items. When the width of the explorer is resized I want the category items to wrap to new rows and expand the size of their parent composite.
If I initialize my inner composite with defaults, nothing happens, not even wrapping. If I set it to grab vertical space, it takes half the space, leaving the other half for the tree, which is ugly and not what is wanted. If I set hints, I does wrap but the size of its composite never changes, thus hiding the next rows. I tried adding a resize event listener and resizing my inner composite. That allows me to resize it and show all the rows, but it then covers up and hide part of the tree. I tried to do a setLocation and setSize for the tree itself to move/resize it accordingly but to no avail, it doesn't change.
How can this be made to work. What am I missing. Isn't there a simple way to ask for a layout that will use the minimum required height and no more but adjust if needed?
Thanks for your help.
Here the code:
innerComposite = new Composite(parent, SWT.NONE);
innerComposite.addListener(SWT.Resize, listenerComp);
GridDataFactory.fillDefaults().hint(10, 30).applyTo(innerComposite);
GridLayoutFactory.fillDefaults().applyTo(innerComposite);
Listener listenerComp = new Listener() {
public void handleEvent(Event event) {
Widget widget = event.widget;
Composite comp = (Composite)widget;
Composite parent = comp.getParent();
Point parentSize = parent.getSize();
Point size = comp.computeSize(parentSize.x, SWT.DEFAULT);
comp.setSize(size);
}
}
And here's an image:
And after resize (noticing that the 1st row of the tree is covered up):
When you are using Layouts calling setSize (or setBounds) will mess up the layout that has been setup.
Instead you should call layout(true) (or even layout(true, true) on the Composite which owns both the Tree and your innerComposite.

Change growth ratios for panes inside SplitPane

Have an horizontal split pane. If the pane grows, then the two interior panes will grow equally (if the split pane grows 100 pixels then each interior pane grows 50 pixels).
Is it possible to adjust this so that the second interior pane grows more than the first one? Like the first one gets 25% of the growth and the second gets 75%.
The SplitPane has no direct API for this, but indirectly we may achieve this..
The API doc gives us a hint:
The dividers in a SplitPane have the following behavior: [...]
Dividers moving to the left/top will stop when the node's min size is reached.
Dividers moving to the right/bottom will stop when the node's max size is reached.
[...]
So, by setting a minimum size, we can force the SplitPane to distribute the available space as we need it.
This is a little example with two TableViews aligned left and right in a SplitPane. Now I bound the minimum size of the left TableView to 20% of the Stages current width and the right ones to 70%.
TableView<?> table1 = createTable();
TableView<?> table2 = createTable();
table1.minWidthProperty().bind(primaryStage.widthProperty().multiply(0.2));
table2.minWidthProperty().bind(primaryStage.widthProperty().multiply(0.7));
SplitPane split = new SplitPane(table1,table2);
You can easily modify the minimum size, to constant values or bind them to different parent container sizes.

GridBagLayout extends column

I have a JPanel with GridBagLayout set. It has 2 columns and 1 row (2 cells). Every cell contains one JPanel which contains one JLabel (type of component is insignificant).
The JLabel in the left cell has width attribute set to 100px. The JLabel in the right cell has width attribute set to 50px. In such case the left cell extends a little and it's wider than the right cell.
I thought that GridBagLayout expands cell only when contained components take too much space.
Is it a GBL bug?
Any idea how I can solve this problem?
Any idea how I can solve this problem?
Java Swing does not work the same way as CSS/HTML. You create the components in Swing and let the GUI worry about the sizing.
Without knowing what you're trying to accomplish, all I can do is say define the Swing components and let the GridBagLayout manage the layout.
If you want the grid areas to be the same size, you would use the GridLayout.
I am afraid this is a difficult question to answer because GridBagLayout doesn't arrange it's columns and rows this way. If you have two columns and two components the columns will size themselves as the sizes of the largest components put into those columns. So your left column is bigger, because your left component is bigger.
You can adjust how much of any spare space a cell takes by adjusting your component's corresponding GridBagConstraints attributes. The weight attributes (weighty & weightx) control how much of any spare space the columns (weightx) and rows (weighty) take up. If for example your JPanels were using GridBagConstraints objects called rightGbc and leftGbc you could use the following code to alter their relative sizes.
leftGbc.weightx = 0.5;
rightGbc.weightx = 1;
This means that the right column will take up twice as much spare space as the left column and therefore (hopefully) make up for the difference in the size of your components.
Using the weight attributes can feel like a very abstract process, and it can take a while to get used to them, but once you start using them for a while you will get it. Depending on which components you are using, there are other quirks which can effect how much affect the weight attributes have on the columns/rows.

How do I get a Composite containing FlowLayout inside a ScrolledComposite to grow vertical and not horizontal?

I'm trying to create a Composite containing FlowLayout inside a ScrolledComposite so that the Composite inherits its width from the ScrolledComposite but grows in height dynamically. I've searched some snippets but I'm not getting them to work; I can only get it to grow in width which is not desirable.
What I'm trying to do is to create a View containing a bunch of thumbnails to fill the window/surrounding composite in width and scroll in height.
You will need to override the computeSize method of the composite, or the FillLayout to always report back the given widthHint, unless perhaps the width hint is smaller than a single thumbnail's width in which case you might want to show horizontal scroll).
There could also a possibility that you add a resize listener to ScrollComposite and keep calling ScrollComposite#setMinSize() to ensure the composite inside only grows vertically.
Also are you using the correct type on FillLayout?

Problems with JTable and JScrollpane size

I have a JScrollPane with a JTable in it. In the JTable I have initially 3 rows. Later on rows get added.
The default JTable with my 3 rows is ugly because JScrollPane calls getPreferredScrollableViewportSize from the client (JTable) and the return value is always the same. That's why my JTable/JScrollpane with 3 rows has this free space, JScrollpane andJTable do not have the same size.
My solution is to make a subclass JTable, override getPreferredScrollableViewportSize and return in this function getPreferredSize();. Now the whole JScrollPane has exactly the size of the 3 row `JTable!
When a row gets added I have the command ((JComponent) scrollPane.getParent()).revalidate();
The scrollpane grows with the table.
Everything works fine!
But now I want to set a certain layout for the container of the scrollpane (panel):
myjpanel.setLayout (new BoxLayout(contentPane, BoxLayout.Y_AXIS));
When I add this command my whole solution doesn't work anymore.
The scrollpane hasn't the size of the 3 row table, this free space is there again.
Why is this?
Does anybody have a solution?
CONTINUED
Thank you camickr for pointing me in the right direction. My solution is the following:
scrollPane = new JScrollPane (table) {
public Dimension getMaximumSize () {
double height = 0;
double width = super.getMaximumSize().getWidth();
height += columnHeader.getViewSize().getHeight();
height += viewport.getView().getPreferredSize().getHeight();
height += (getViewportBorderBounds().getHeight() * -1);
Dimension returnValue = new Dimension ((int) width, (int) height);
return returnValue;
}
};
It works now at the beginning.
But when a row is added to the jtable and I call revalidate(); on the jpanel (parent container of the scrollpanel) the jscrollpanel shrinks in height to 1 row + header!
Has anyone got an idea what is to do in this situation.
CONTINUED
Now I know the problem. It is the viewportBorder. In order to get the whole, exact height I have to total the height of the view (Jtable), the height of the column header and the height of the viewportBorder. The first time getViewportBorderBounds().getHeight() returns -3, next time - after a new row is inserted in the table model - the function returns 48. I do not understand why this function returns 48 now.
Another point is that camickr says that changing the size of the jscrollpane defeats the purpose of the scrollpane. I do not understand this. How can anyone be satisfied with a default jscrollpane size of 450 x 400 (http://www.javalobby.org/java/forums/t19559.html) even when the jtable has only 3 lines at the beginning. This unfilled extra space does not look very professional in my eyes. Has anyone got a better solution for this.
Thank you very much for your answers
CONTINUED
Now everything works!
At the beginning I simply set the jscrollpane border to 0 ... sp.setBorder(createEmptyBorder());
In this way I avoid having these strange return values of getViewportBorderBounds().getHeight()
Wolfgang
The BoxLayout allows the component to grow up to the maximum size of the component. I guess you need to override the getMaximumSize() of the scrollpane to return the preferred size.
When a row gets added I have the command "((JComponent) scrollPane.getParent()).revalidate();" The scrollpane grows with the jtable.
That kind of defeats the purpose of the scrollpane. The scrollbar is supposed to stay at a fixed size and then scrollbars will appear if necessary.
I had a similar problem - the basic upshot is that I wanted a JTable in a scroll pane that had a minimum and maximum size: when there was no data in the table, it should have a one-row-height pane background displayed (not a fake row, obviously), and when it was over 10 rows to limit the displayed table size to those 10 rows plus scrollbars. Any size between 1 and 10 should display the table at full height. The situation was a parent-child table, and this was the child table, so I had to trigger the child table resize depending on which parent table row was clicked. A fixed pane size looked ugly in that it took up unnecessary space to push other potentially viewable info under the child table out of view with just blank space.
Using the setPreferredScrollableViewportSize after updating the model with the child rows (and setFillsViewportHeight(true) of course) gave me almost everything I needed. Except that the viewport wouldn't redraw until I clicked on it, or took focus from the window then flicked back, it was most annoying.
The solution was super-simple after reading this post: I just had to call revalidate on the scrollpane's parent, as pointed out in the solution. Fixed it perfectly. Mostly I just wanted to share a use case where you want the scrollpane size to change dynamically up to a maximum size. Swing is so much simpler if everything is created at a fixed size forever... unlike pretty much every real-life use case I've ever encountered :-)

Categories

Resources