Community
Participate
Working Groups
When writing a layout, it is usually useful to know the following about a control: 1. Given the available space in one dimension, how much could the control be compressed in the other dimension before it would start losing functionality. I will refer to this as the control's "minimum size". (Note that this is not the space required to display all of the control's contents at once: if the control is scrollable, the control's entire contents are accessible through scrolling so the control will have a constant minimum size regardless of the current contents.) 2. Given the available space in one dimension, how many pixels could the control fill in the other dimension before it starts filling the space with the background colour. I will refer to this as the control's "maximum size". Currently, it is necessary to estimate these quantities using the control's "preferred size" (the space required to display the control's entire contents), which is complicated and does not always work properly. The layouts in the forms library and the workbench both need these values. SWT should provide a standard protocol for Controls to report this information so that Controls can be written that work in any type of layout, and so that layouts can use real data rather than heuristic guesses.
The patch in bug 103863 shows how this protocol might look. It specifies an optional interface that controls and layouts could use that looks like this: /** * Objects implementing this interface are capable of returning information * about their size constraints. * * @since 3.1 */ public interface ISizeProvider { /** * Constant used to indicate infinite size. This is equal to Integer.MAX_VALUE, ensuring * that it is greater than any other integer. */ public static final int INFINITE = Integer.MAX_VALUE; /** * Returns the maximum size of the control, or INFINITE if unbounded. The maximum size is the size * beyond which the control would simply fill in the extra space with the background colour. * * <p> * Most controls with a border (such as push buttons or most scrollable controls) consider * themselves to be unbounded if they can fill the extra space with the border. The exception * would be simple composites, which take their maximumum size from their layout, even if they * have a border. Labels and toolbars have a rigid maximum size since they cannot expand to fill * the extra space once their full contents are visible. * </p> * * <p> * All sizes refer to the outer dimensions of the control in pixels, not its inner content size. * </p> * * @param constrainedDimension fixed dimension of the control (pixels), or INFINITE if unconstrained. If * resultIsWidth is true, this is the height of the control. If resultIsWidth is false, this is the width * of the control. If canWrap(toCompute, resultIsWidth) is false, then this argument will be ignored and * the caller can assume that the result would be the same for all other values of constrainedDimension. * @param resultIsWidth if this is true, the method returns a height given a width. Otherwise it returns * a width given a height. * @return returns the maximum width or height of the control based on resultIsWidth. Returns INFINITE if * this control can make use of any available space. */ public int computeMaxSize(int constrainedDimension, boolean resultIsWidth); /** * Returns the minimum size of the control. The minimum size is the size at which the widget would lose * functionality if made any smaller. For scrollable controls, the minimum size is typically the minimum * space required to render the scroll bars, border, and some constant minimum area for the content * region. The minimum space for the content region is NOT the space required to view the entire * contents of the control, but rather the minimum size required to see anything useful at all. That is, * as long as it is still possible to view the content area through scrolling, then the content area * is not part of the minimum size. * * <p> * For simple non-scrollable controls (such as labels, toolbars, etc.), the minimum size is often equal to * the maximum size. The minimum width of a wrapping label is the width required to display the longest * word in the label (since making it any smaller would truncate that word). * </p> * * @param constrainedDimension fixed dimension of the control (pixels), or INFINITE if unconstrained. If * resultIsWidth is true, this is the height of the control. If resultIsWidth is false, this is the width * of the control. If canWrap(toCompute, resultIsWidth) is false, then this argument will be ignored and * the caller can assume that the result would be the same for all other values of constrainedDimension. * @param resultIsWidth if this is true, the method returns a height given a width. Otherwise it returns * a width given a height. * @return returns the minimum width or height of the control based on resultIsWidth. Returns 0 if the * control has no minimum size. */ public int computeMinSize(int constrainedDimension, boolean resultIsWidth); }
Note that this bug, bug 46112, and bug 103863 are the issues that are currently complicating the workbench layouts.
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. If the request is still relevant please remove the stalebug whiteboard tag.
