Download qooxdoo Documentation

qooxdoo Documentation, Release 1.2
Growing & Shrinking
Dynamic GUIs often must work equally well in cases where not enough (or too much) room is available to render
the GUI in the way meant by the developer. This may include simple cases where the size of tabs is reduced in order
to handle the display of all open tabs without scrolling. More advanced cases are text which wraps to multiple lines
depending on the available width (and this way influences the position of following children).
In the first case we often see that an application reduces the size of the label and uses an ellipsis symbol to show
that the label was too long. This feature is built-in into both commonly used widgets: Label and Atom. When the
underlaying layout ask to reduce the width (or the developer using the width property) the widget tries to solve the
requirement dynamically. This certainly works for the height as well.
var label = new qx.ui.basic.Label().set({
value: "A long label text which has not enough room.",
width: 60
});
The second case is handled by the height for width support. Longly name but basically a really strong feature which is
required quite often. It means that the height may depend on the actual width available. This especially makes sense
for multi-line text where the wrapping may be influenced by the available width. The Label widget includes support
for this feature when using the rich output mode (HTML content).
var label = new qx.ui.basic.Label().set({
value: "A long label text with auto-wrapping. This also may
contain <b style=’color:red’>rich HTML</b> markup.",
rich : true,
width: 120
});
Finally this means that every widget can grow and shrink depending on the limitations given for the respective axis.
Two easy accessors which disable growing or shrinking respectively are allowGrowX and allowShrinkX. When the
growing is disabled the configured or automatically detected maximum size is ignored and configured to the preferred
size. When the shrinking is disabled the configured or automatically detected minimum size is ignored and configured
to the preferred size. Two convenient methods to controlling these features without knowing of the exact dimensions.
Overflow Handling
This leads to the next question: how to handle scenarios where the content needs more room than provided by the
parent but should not shrink. This is a common case for data widgets like Lists or Trees. Both extend the AbstractScrollArea to provide scrollbars to handle overflowing content.
The ScrollArea itself renders scrollbars in a custom way. It does not use the native scrollbars nor the native
overflowing capabilities of the browser. Benefits of this decision are:
• Scroll bars can be themed.
• Optimal integration into layout system.
• Own implementation overrides browser quirks
The scrollbars are controlable in a way that is comparable to CSS. It is possible to have both scrollbars marked as
auto to automatically detect the needs of the content. Or any other combination where a scrollbar may be statically
hidden or visible. Each bar can be controlled separately. It is possible to enable one scrollbar statically and make the
other one auto-displayed and vice-versa.
var big = new qx.ui.form.TextArea;
big.setWidth(600);
big.setHeight(600);
198
Chapter 4. GUI Toolkit