If netbooks are on the way out, it means we will see more machines with OpenGL [ES] 2.0 coming to market. This is a good thing; the netbook I use for development has OpenGL 1.4 support.]]>
The grid layout places views in a typical matrix style. All views in a grid are presented with a size that they may or may not use entirely. And views cannot be rendered outside of their allocated space.
Horizontal and vertical space between views can be controlled by the developer, as is the padding of the grid content.
In addition, a grid layout can be filled in two ways:
Layered Layout is the latest addition to the Layout family. Basically, it stacks areas one onto the other. And the top level area is the one that receives inputs events. The stacked areas are rendered from back to front; and with blending enabled areas can be seen through the stack.
The layouts that have been described through out the series are essential to give structure to Nux user interfaces. The Horizontal and Vertical layouts are the most complex of these layouts. This is due to traditional user interface design that tends to favor rows and columns of user interface components. However, user interface design is changing and things don’t have to be so linear anymore. Areas can be rendered in the 3D space and this offers new possibilities for user interaction.
UDS was full of conferences and presentations. Canonical announced a push toward tablets, smartphones and TV set-top boxes. All this means our products will have to be robust, reliable, great. Or simply exceed expectations.
I have a few pictures to share from UDS.]]>
I did some fixes in the StatictText class to make it better suited when it is used inside other views. For instance, the StaticText view may become larger or smaller according to size negotiation in a layout. However, its vertical size (the height) is determined by the size of the font. The StaticText view height cannot be controlled through the layout API. Its height is controlled by changing the size of the font.
The picture above, is showing the alignment of StatictText view in a vertical layout (VLayout). It also shows how the text appears with ellipsis if the StaticText view is too small to contain it. In the second line of text, the StaticText view maximum width has been forced to 250 pixels while the text inside occupies more than 250 pixels in width. Rather than cutting the text abruptly (or wrapping it), the rendering API (Cairo or DirectWrite) is showing ellipsis instead.]]>
With the new Button design, a button may have a label, an image or both. The label and the image may displayed horizontal or vertically. You can control the space between them or choose which one comes first in an horizontal or vertical arrangement. Here is what it looks like.
I am using horizontal and vertical layouts to hold the image and the label together. It all came down together nicely and this should be enough to get started. No code available for now but it will be made available with the release of Nux 2.0 in a week.]]>
Before I proceed, I want to introduce new terms. In previous parts of the Nux Layout series, I have been using the word “widget” to refer to containers (layouts) and physical interface component (such as button). However, I find the term “widget” inappropriate, too generic and not very descriptive. I prefer to substitute “area” to “widget”. An area occupies a physical region of the display. It may be a container (layout) or user interface object (such as a check box). Container type areas are invisible on the display but the placement of their content on the screen gives the hint of the role they play in the organization of the user interface. Some areas are both containers and user interface objects. A scroll view for instance is a visual interface component but it is also a container of a view that you can scroll up or down, left or right. In the Nux Layouts series, layouts as invisible container that inherit from the nux::Layout class.
When I refer to a size, I am talking about the size along the major axis. For and horizontal layout, this is the width.
All areas added to an horizontal layout are given a scaling factor. That factor is an integer number equal or greater than 0. And every area has a minimum and maximum size that cannot be changed by the layout process.
At the start of the horizontal layout computation process, areas with a scaling factor of 0 are set to their minimum size (only the major axis size is changed). Then, the total size of all areas with a scaling factor of 0 is taken out from the layout size (along the major dimension which is the width for an horizontal layout).
I didn’t add it in the formula (for simplicity), but the left/right padding of the layout and the space between children should also be taken out from the layout’s total size. This would yield the correct available space to share between children with a non zero scale factor.
The layout’s available size is then shared among all VIC with a non zero scale factor according to this formula:
The formula applies only if the minimum and maximum size of the area are respected. An area size cannot be smaller than its defined minimum or larger than its defined maximum. If the result of the formula would give an area a size that is larger than its maximum size, then the area would adopt its maximum size. If the result would be smaller than its minimum size, then the area adopts its minimum size.
Consider the following picture. It shows a simplified version of the layout process.
As a result of the computation, we have the folowwing:
The important point is that, not only does the parent layout affects the size of its children, the children also affects the size of their parent. The parent layout always tries to tightly pack its children along the major axis. In the end, the horizontal layout may look like this:
The last case reveal a configuration option. If the layout is larger than its content, the children may be distributed in different ways along the major axis:
All that has been said for the horizontal layout also applies to the vertical layout.
What I have shown here is a simplification of the layout process for nux::HLayout and nux::VLayout. There are more details to the layout process. By design, the process never gets stuck in a the recursion. The computation always reaches a solution even if it means that the children of the layout overflow beyond its borders. With the right of conditions imposed over the layouts and its areas, it is possible to achieve many linear arrangement styles.
In the next part I will go through some of the details of the grid and layered layouts.
The major axis in an horizontal Layout is its width, while the minor axis is its height. For a vertical layout, it is the opposite; the major axis is the height, while the minor axis is the width.
Major and minor axis only applies to horizontal and vertical layouts. When I talk about a layout’s children minor axis. I am refering to the axis of the children that is aligned with the layout minor axis.
When an horizontal or vertical layout goes through the size/position negotiation process of its children, it can try and change the minor size of children according to the following options:
The last option needs more precision. It means “try to make the the widget’s minor axis just as big as what its own content requires”. Because widgets can have minimum and maximum sizes (see below), this choice cannot always be fulfilled; but that won’t stop the layout process from achieving the layout.
There are also options to place the children inside a layout. A child can be at the following positions along the layouts’s minor axis:
I have exposed the position/size options along the minor axis of horizontal and vertical layouts. When adding a widget into an horizontal or vertical layout, the developer uses the Layout API to control the placement and position of children along the minor axis. In addition, each widget has a minimum and maximum size. This gives the developer additional control over the layout system. The layout process can never change the minimum or maximum size of a widget on its own. It always respects the minimum and maximum boundaries set by the developers. In Nux, a widget can be as small as 1 x 1 and as large as 2147483647 x 2147483647. (To be realistic, I will be changing the maximum size for reasonable values, such as the maximum OpenGL texture size by the GPU).
Some precision about widgets. Widgets can be layouts or views. In Nux, a view is a UI element. That is a view has a visual representation and it can receive keyboard and mouse events (like a button or a check box). And so, layouts can have views or layouts as children. The layout process involves going through the widget tree and getting all widgets to conform to the rules of the layout system. Once a widget layout is computed, the result is passed over to its parent so it can complete it layout process and so on up to the root layout of the interface.
In the next part, I will be going through the layout process along the major axis of an horizontal or vertical layout. I will show how widgets get their size along the major axis.
Both of these layouts have separate horizontal and vertical padding and they allow variable space between their children.
In both pictures above (1) represent the layout horizontal padding, (2) the vertical padding and (3) the space between children. The padding allows some space between the children and the layout’s borders. The horizontal and vertical padding may have different values, but the space between items remains the same. All these values can be set through the layout class API.
Just like horizontal and vertical layouts, grids have paddings and internal space between children. However, the horizontal (4) and vertical (3) space between the children may have different values.
A layered layout puts layouts on top of each others. At any time, one child of a layered layout is chosen to be the front layout. The front layout is the first child to receive input events in a layered layout. Children of layered layouts may be widgets or layouts of any kind (horizontal, vertical, grid or even layered layouts).
Layered layouts don’t have padding. Instead each child layout defines its own. Layered layout take care of the stacking of the children and their order in the stack.
There are more details about layouts. Although the horizontal and vertical layouts are conceptually simple, they are very flexible in the way they organize the placement of their children. In the next part, I will first define what are the minor and major axis in horizontal and vertical layouts. Then I will show the placement options available to children of these layouts.]]>