Community
Participate
Working Groups
The GridLayout manager treats the width and height hint as a minumum width even if fill and grab is specified for the cell. But is doesn't treat it as a maximum width. This makes it hard to design dialogs which are opened on a "smaller" screen. Consider the following example: - a shell with a tree and some label below the tree - the layout is managed by a GridLayout manager. - we specify a width hint of 500 for the tree and make it fill and grab. Open the dialog. When you resize it (make it larger) the tree gets enlarged as well. If you make the dialog small the tree get clipped. When you now open the dialog on a smaller screen (600x480) the tree gets clipped right from the beginning.
VI is the closest we have to a grid expert. I think I understand what he is saying and it seems to make sense. Basically, if you think in "form layout" terminology, the widget is attached on all sides and should be "rubber". Lynne, I added you because you are the original grid author. Do you have any comments? I don't think we should fix this for 2.1 because of the risk.
There was a previous request by Eduardo to have a preferred width. This would be used when computing the preferred size but would not interfere with the other aspects of GridData such as fill horizontal etc. I think this enhancement may provide what Dirk is looking for. I don't think we will be adding this for 2.1.
But we have PRs that some of your dialogs get clipped when using low resolution.
Dirk, Which dialog(s) are you concerned about? Point me at the source code and I will have a look at what can be done. I think FormLayout may be a better answer. I really do not think we can change the behaviour of GridLayout - others rely on it behaving as it does currently plus it is an involved piece of code that Eclipse relies on heavily and I do not want to screw everything else up by modifying it.
Most of the PRs are related to High contrast mode under Windows. See bug 30616 as an example. As far as I know it isn't clear yet on which resolution Eclipse has to support high contrast mode. Another bug is 31080. These bugs can be fixed by tweaking the width hint, but this can't be the final solution since it depends on various other aspects (font, os, ...). If we follow the path to tweak the hint then SWT should comment on bug 31278.
*** Bug 30708 has been marked as a duplicate of this bug. ***
Fixed in 3.1 > Sept 30. widthHint, heightHint are the values passed into Control.computeSize(int, int, boo to determine the preferred size of the control (e.g. in shell.pack()). New fields minWidth and minHeight are used to define the minimum width and height of the control. By default the minimums are 0. A minimum value of SWT.DEFAULT means use the result of Control.computeSize with widthHint or heightHint to determine the minimum size.
Wait ... shouldn't those fields be named "minimumWidth" and "minimumHeight"? I know the names are longer but we don't use short forms in API names and we already have Shell.setMinimumSize() and ScrollBar.setMinimum(). Please hold off using the new API until the names get finalized. Thanks. Sorry about that everyone (including Veronika).
