GUI Face Sizing - r3n/rebol-wiki GitHub Wiki

Posted by Carl Sassenrath, 18-Mar-2009

Table of Contents Goal Defining the main issue Reviewing the purpose Summary of requirements The problem? A proposed solution How it effects layout Do we need MAX-SIZE? Are there any other issues? How to decide Test cases

The goal is to finalize the sizing/resizing mechanism used by the GUI.

There have been a few discussions on DevBase/RebDev chat about it, expressing a few concerns.

The purpose of this document is to address those concerns and determine what changes are necessary to satisfy most developers.

In general, I am satisfied with the face sizing and layout mechanism. It produces good results for the primary cases. But, it may be that for some cases we still have some design flaws or implementation bugs that cause strange results.

If I understand the comments posted recently, the main issue seems to be related to the max-size field.

The max-size field limits the growth of a GUI face. I find it useful because:

1. Some faces look a little "goofy" when they get too wide. For example, a single button may span the entire width of a window. (We can allow that if a developer wants it, but it should not be the default.)
2. We do not want to use "fillers" everywhere to limit sizes. It makes the GUI code harder for users and not as easy to read.
3. Text faces are difficult to read when they are too wide (because the reader's eyes must track long lines - one reason newspapers and other media use multiple columns.)

We want to be able to specify the size a face in a few ways:

1. Fixed size (always the same size)
2. Variable size - expands or shrinks

There are multiple ways to specify variable size:

1. As a percentage
2. Limit to max-size
3. Fill all space available

Also, it is useful to have a min-size to limit the smallest size.

Right now, the max-size field also controls the expansion ratio. A face with a larger max-size creates "greater pressure" to expand than a smaller face.

It is true that this makes max-size a dual-purpose variable. During design, it seemed like a reasonable method, but perhaps we need separate fields.

Do you think this would be a satisfactory solution:

Add an EXPAND (or GROW) field that provides the desired expansion ratio.

The EXPAND field could be set to:

• NONE - do not expand.
• A PERCENT! value - expand as a percentage of the size available.

If the field is set to 100% it will always try to use all space available.

Of course, it's not really that easy, because we must allow expand both in X and Y directions. Because it is PERCENT! that means we cannot use a single PAIR value.

We will need: EXPAND-X and EXPAND-Y (or GROW-X and GROW-Y).

Layout is done as a grid (like HTML tables). If we allow EXPAND, then we will need to decide what effect it has on its rows and columns.

For example if we have a panel that has two rows (1 and 2) and two columns (A and B), what happens if A1 has EXPAND-X set to 30% and A2 has EXPAND-X set to 80%, what is the result?

If we add EXPAND, do we need MAX-SIZE?

The EXPAND is a relative size, but MAX-SIZE is an absolute size. So, for example, a TEXT-AREA may be 100% wide (full width of the panel), but if the window is resized to be very large, the TEXT-AREA would also be very large.

The same is true for sub-panels. If we have a navigation panel that is 20% wide, we want to be able to limit its width to perhaps 200 pixels when the window is resized to be very large.

Did I cover the main issue(s)?

The chat thread had a few more comments about layout that were related to aligning to left or right sides.

I think that issue is a matter of user education. In the R3 GUI, you can insert a pad to push a face to the right side. It's just as easy as using some kind of special mechanism, and requires no extra implementation internally.

There is only one way to reach a decision. Use a variety of test cases, and determine if good results are produced.

Good results also means that it must abide by the Rebol principles:

• Simple things should be simple. Defaults should be smart.
• Common variations should be possible with little effort.
• Major changes should be possible, but require more effort.

Here are two test cases:

Case 1:

view [
    title "Example"
    area
    button "Submit"
]

A good result would be for the area to be full width and full height (less title and button), with the button being perhaps 30% wide.

Case 2:

view [
    title "Example"
    area
    group [
        button "Submit"
        button "Cancel"
    ]
]

Same results as above, except each button is 30% wide.