Nux Layouts (part 5)
I will conclude the Nux Layouts series with a look at the Grid and Layered Layout.
Grid Layout
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.
Grid Layout Design
In addition, a grid layout can be filled in two ways:
- Horizontally, with areas added in rows from left to right
- Vertically, with areas added to columns from top to bottom
Grid Layout Horizontal Flow
Grid Layout Vertical Flow
Layered Layout
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.
Layered Layout Design
Conclusion
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.
Precise Pangolin
That is the name of the next Ubuntu release. I am heading to Orlando (Florida) for a Unity design sprint where the designers and developers get to meet and talk about what is coming next. Should be fun!
Nux Sample Programs
I am making some Nux sample programs available. The programs are currently available at this branch (lp:~jaytaoko/
Static Text View
Displaying static text is absolutely necessary in any UI toolkit. Not only that, it is important to do it right. I have been working on the text view lately. It uses Pango/Cairo on Ubuntu and Direct2D/DirectWrite on Windows.
Text Formatting
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.
Button Design
Lately I have been revisiting the Button user interface of Nux. The former Button design was very simple; it featured a label in the middle of the area, and the button changed its visual appearance as a result of the mouse pointer action over itself. If you wanted a button with more feature, then you had to write one yourself or subclass the existing one. Although I didn’t want to add too many to features to the Button design, I felt it was important to have just enough so you don’t need to recreate a new button from scratch to get started.
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.
Weather Buttons
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.
Nux Layouts (part 4)
In Part 3, I have shown the options available along the minor axis of an horizontal or vertical layout. In this part, I will go though the layout process along the major axis. I will be using an horizontal layout to demonstrate the process, but the same computations applies along the major axis of a vertical layout. For reference, here are the previous parts in the Nux Layouts series: Part 1, Part 2, Part 3.
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.
Layout computation along the major axis of an horizontal layout
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.
User Interface Component Size
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).
Layout Available Size
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:
Size Computation
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.
Size Computation Process
As a result of the computation, we have the folowwing:
- area 0 occupies 3/5 of the available size
- each one of area 2 and 3 are 1/5 each of the available size
- each one of area 2 and 3 and each 1/3 the size of area 0
- area 1 is reduced to its minimum size
Recursion
Layout Process Recursion
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:
Final Layout Result
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:
Final Layout Distribution
Summary for HLayout and VLayout
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.