randrew / layout Goto Github PK

Is there a way to mark a node such that it will fill the available space while keeping its original aspect ratio?

in layout.h

in oui.h
switch(flags & UI_HFILL)
{
case UI_HCENTER:
{
pkid->margins[dim] += (space-pkid->size[dim])/2 - pkid->margins[wdim];
}
break;
..............
}

but I calculated pkid->margins[dim] by OUI.H code, but I found it was not in the middle.

how can custom layouts be achieved?

for example, a grid with AxB columns/rows

or a LinearLayout https://developer.android.com/guide/topics/ui/layout/linear.html

or even ConstraintLayout https://developer.android.com/develop/ui/views/layout/constraint-layout

The GENie file currently only builds as C99 for GCC and Clang by default. We should have some command we can run to test both C99 and C++ in one go, which should make it easier to catch incompatible differences (like the restrict/__restrict mistake)

We should use a separate mutable break flag bit instead of re-purposing the input flag bit.

how do i remove an item without having to rebuild the entire context list?

While using layout library in my project I've come across somewhat unexpected layouting behaviour.

Minimal reproducible example follows:

1. Create root item of arbitrary size, without any additional configuration it acts as layout container
2. In that root insert row container with unfixed size
3. In that row container insert item with fixed size, and margin from the bottom

Equivalent code:

    lay_id root = lay_item(ctx);
    lay_set_size_xy(ctx, root, 1, 100);

    lay_id row = lay_item(ctx);
    lay_set_contain(ctx, row, LAY_ROW);
    lay_insert(ctx, root, row);

    lay_id child = lay_item(ctx);
    lay_set_size_xy(ctx, child, 1, 50);
    lay_set_margins_ltrb(ctx, child, 0, 0, 0, 10);
    lay_insert(ctx, row, child);

In a case like that I would expect the following

1. row's height becomes 60, since item's height is 50 + item's bottom margin is 10
2. item is placed at the begginng of the row (row pos = [0, 20], item pos = [0,20])

It can be validated by a test:

    lay_run_context(ctx);
    lay_vec4 root_rect = lay_get_rect(ctx, root);
    lay_vec4 row_rect = lay_get_rect(ctx, row);
    lay_vec4 child_rect = lay_get_rect(ctx, child);

    LTEST_VEC4EQ(root_rect, 0, 0, 1, 100);
    LTEST_VEC4EQ(row_rect, 0, 20, 1, 60);
    LTEST_VEC4EQ(child_rect, 0, 20, 1, 50);

It is consistent with like other layout engines implement margins (like yoga layout or flexboxes in basically all modern browsers).

However, in current version of the library:

1. row's height indeed calculated as 60
2. but item is placed above the row, at position [0,15]

From my understanding, the culprit is the lay_arrange_overlay_squeezed_range function, specifically line 1104:

// in LAY_HCENTER case
rect[dim] += (space - rect[2 + dim]) / 2 - margins[wdim];

The following change seems to be fixing the problem, and doesn't break any of the tests

--- a/layout.h
+++ b/layout.h
@@ -1101,7 +1101,7 @@ void lay_arrange_overlay_squeezed_range(
         switch (b_flags & LAY_HFILL) {
             case LAY_HCENTER:
                 rect[2 + dim] = lay_scalar_min(rect[2 + dim], min_size);
-                rect[dim] += (space - rect[2 + dim]) / 2 - margins[wdim];
+                rect[dim] += (space - rect[2 + dim] - margins[wdim]) / 2;
                 break;
             case LAY_RIGHT:
                 rect[2 + dim] = lay_scalar_min(rect[2 + dim], min_size);

Before submitting an actual pull request I would like to ask:

• Whether or not there is any actual reason this function implemented the way it is, or nobody just ever tried such use case
• If you can spot any other side effects of the suggested chang which are not covered by tests, but may turn out to be a breaking change

I originally didn't expect to have so many users of layout, so I didn't put in security checks for overflows on the allocation math. I'll add some before too long.

We should have the ability to do this.

While reading through your code, I found something that may be an error.

From your comment, here should be pchild->margins[dim] + rect[2 + dim] + pchild->margins[wdim]?

Also, about the layout algorithm itself, margins are not allowed to overlap with other margins. Did I understand it correctly?

I would think what might sometimes be good to have is the mode for preset (fixed) item ID numbers, you will specify how many they are and then you will call the function to allocate that many, instead of calling lay_item for each one.

This could be done to check first if ctx->count is zero; if not, then it is an error, but if it is zero then it will set its capacity and count to the specified number, allocate them, and then initialize each item in a loop, similarly than lay_item already does.

(My own "smallxrm" library, which is an implementation of the X resource manager, has a xrm_init_quarks function with a similar use. You will allocate many items with fixed preset ID numbers from the beginning, which can be compile-time constants, rather than having to pass strings always or allocating them and assigning them to variables. (You can still add additional quarks afterward which do not have fixed numbers.))

Using names like lay_context_reset instead of lay_reset_context made sense when matching the style of the original project I wrote this for, but in hindsight it's pretty annoying. The functions will be renamed to lay_verb_noun where appropriate in an upcoming commit, and a regex to update existing code will be supplied.

When using LAY_BOTTOM or LAY_RIGHT anchors for an item's behavior, it doens't subtract the "left" margin, leaving you with an invalid offset: (yellow rectangles are the margins)

Changing the code to the following fixes the problem:

case LAY_RIGHT:
    child_rect[dim] += space - child_rect[2 + dim] - child_margins[wdim] - child_margins[dim];
    break;

This might possibly be an issue in lay_arrange_overlay_squeezed_range as well, but I have not tested it.

I can do a pull request if you want.

this ui layout is very good,but I do not understand how tp deal with layout for lay_top or lay_down?
I had read codes, do not found
case lay_top:
some code;
break;
case lay_down:
some code;
break;
and so on
I don't know if you can understand what I mean？

Layout defines it like this if __GNUC__ is defined:

#define LAY_RESTRICT restrict

However, this is not valid on g++. Changing this to __restrict makes it compile on g++ 6.3.0.