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.
Nux Layouts (part 3)
This is Part 3 of the Nux Layouts series (Part 1, Part 2). In the last article I briefly mentioned the major and minor axis in horizontal and vertical layouts. What are these? Let’s find out.
Minor and Major axis
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.
Horizontal Layout Axis
Vertical Layout Axis
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.
Widget Inside Horizontal Layout
Widget Inside Vertical Layout
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:
- give a child’s minor size the same size as the layout minor axis
- give a child’s minor size a percentage of the layout minor axis
- don’t change the child’s minor size
- let the child’s minor size tightly match the size of its content
Minor Size Horizontal Layout
Minor Size Vertical Layout
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:
- start of the minor axis
- center of the minor axis
- end of the minor axis
Minor Position Horizontal Layout
Minor Position Vertical Layout
Widget minimum and maximum sizes
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).
Widget tree
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.
Size along the major axis
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.
Nux Layouts (part 2)
In Part 1 I introduced Nux’s layouts types and how they structure the widget tree. Now, I will show the anatomy of a the layouts, how they are structured and how their children are placed inside.
Horizontal and vertical layouts
Both of these layouts have separate horizontal and vertical padding and they allow variable space between their children.
Horizontal Layout Padding
Vertical Layout Padding
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.
Grid layouts
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.
Grid Layout Padding
Layered layouts
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 Layout
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.
More about layouts
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.
Nux Layouts (part 1)
Layouts in Nux are containers of widgets. They group widgets horizontally, vertically, in a grid or stacked one on top of the other. These types of layouts are common in user interfaces. They are simple and easy to understand. Here is a mockup of some layouts:
Horizontal Layout
Vertical Layout
Horizontal Grid Layout
Layouts may contain widgets and other layouts. Layouts themselves are placed inside widgets. Each widgets may have one and only one layout. Together, widgets and layouts define the widget tree of a Nux user interface.
Widget Tree
At the top of the widget tree, there is a layout attached to the client space area of the application window. This is the root layout of the interface.
Layouts are responsible for size management and position of user interface elements. They have a programming interface that allows developers to give instructions that drive size negotiation and position during the layout processing cycle.
The layout system is dynamic. Objects’ size and position inside layouts are automatically computed when certain conditions changes. For instance, if the application window changes size, the root layout will initiate size negotiation through out the widget tree and objects’ size will be re-calculated.
Size negotiation in widgets is complex. It involve going back and forth through the widget tree until the system comes to an equilibrium. However, from a user point of view, the hope is that the layout system is easy to use for simple cases and flexible enough for more advanced configurations.
In the next part, I will be going over details about the layouts internal design.
Tracking Down A Bug
To track down a software bug, sometimes, you have to move away from your computer. That is what I did last week end. Not that I am always stuck in front of my computer, mind you. I was working on a bug that could only be reproduced with the open source radeon driver and ATI R300/400/500 GPUs. I didn’t have the right GPU to reproduce the bug, so there wasn’t much I could do to fix it. I had the feeling it was a driver bug but I wasn’t quite sure.
I looked in the classified ads of my area and found someone who had an ATI X1950 for sale. I contacted him and he quickly responded. We met the next day and he gave me the GPU in exchange for a reasonable price. The fun part was that met in a nice place where I have never been before; so I took the time to walk around and visited a few stores.
Back home, I plugged the card in my system, and switched the bios to PCIe 1.0 (the X1950 only supports that type of transfer). I had no trouble getting the card to run Unity and then, I was able to reproduce the bug. Finally, I could try to solve the problem.
I eventually succeeded in localizing the issue and found a workaround. It turns out the open source radeon driver does not behave as expected when the OpenGL scissor area has a null size. For isntance, if I call glScissor (10, 245, 0, 0), I expect that nexct time I draw a full screen quad, nothing should appear on the screen. That would be the expected behaviour since i have set a 0 size clipping region; and the OpenGL doc for glScissor says so!
The workaround has been implemented and merged with the code base so anyone with an ATI R300/400/500 can use Unity. Despite the fact that the bug was hard to resolve, the best part was that I got out of the house to solve part of the problem (get the ATI X1950 card) and discovered a nice place.
Bug fixing isn’t always like that!