Community
Participate
Working Groups
GridLayout is the most powerful layout manager in SWT and is used for most nontrivial layouts. It is generic and therefore applicable to many situations, but there are cases where it does not work well. Its main problem is that it assumes that controls can always compute their width and their height independently. This is not the case in text control (Label, Text) that are allowed to be multi-line and where WRAP flag is set. There is no 'right' width and height for such a control - its height depends on the width it can use. When wrappable controls are layed out using GridLayout, it will ask them for their size. Such a control always returns the size that will allow it show all of its text in a single line. GridLayout will allocate just one line for its height. If for any reason the container's width turns out to be smaller than expected, the label will wrap, but the text will be cut off because the layout manager didn't allocate space for the required height. The proposed new layout would work as specified in W3C HTML 4.01 specification related to HTML table layout (HTML 4.01 spec, Appendix B.5: Notes on Tables: http://www.w3.org/TR/html4/appendix/notes.html#h-B.5 ). This algorithm calculates column widths first, and does it recursively for all the children that are themselves tables. This calculation pass establishes minimum and maximum column widths. Based on widths, it calculate row heights. Layout portion works top-down, left-to-right, and again assigns widths first (for one whole row). Once all the widths for the row are assigned, it is possible to calculate row height because wrappable controls are now able to tell their height. The advantage of this algorithm is that it is capable of 'pushing' controls down when the container is resized and text reflowed (similarly content in the Web browser). The disadvantage is that it typically has to work with a composite capable of scrolling (ScrolledComposite) because reducing the width of the container may increase the height of the content beyond container's height. For an incomplete yet working implementation of the algorithm, please check HTMLTableLayout.java in package org.eclipse.update.ui.forms, project org.eclipse.update.ui.forms in the 2.0 stream. There is a runnable test class TableLayoutTest that can be used for quick evaluation.
DG should consider implementing this layout if interested in it. Also, see the new FormLayout class, since it has more powerful capabilities.
Moving from Later.
I believe the new SWT GridLayout (in HEAD) behaves as described.
Care to elaborate?
*** Bug 83403 has been marked as a duplicate of this bug. ***
It would be very useful if this layout allowed empty cells i.e. if the table layout data allow the column and row index for a control to be specified
Agree with comment 6. Allowing blanks will allow more of an HTML layout style. Refactoring the HTML layout from forms into SWT makes sense.
Update: 1) GridLayout supports items that change height as their width changes (e.g. Labels with wrapped text). This support was added in Eclipse 3.1. Like HTML Table Layout, it uses a two pass approach. 2) Finer control of the width of widgets in a GridLayout can be obtained using GridData.minimumWidth - also added in Eclipse 3.1. With the minimum width, you can have a widget that expands to take up available space but will not shrink to a size less than the minimum width. You can also exclude widgets from the GridLayout using GridData.exclude. 3) DG has contributed a layout called TableWrapLayout which can be found in org.eclipse.ui.forms.widgets 4) I have added an enhancement request for FormLayout which would make it easier to do vertical alignment: https://bugs.eclipse.org/bugs/show_bug.cgi?id=219206 I am not saying that the above items replace the need for an HTML Table Layout, I am just bring this bug report up to date with the current state of layouts in SWT.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
