History

Added `Layout System` section to doc/usage.md

rxi committed 8 years ago

Commit 8fbc0401 parent d0e93181 file · +79 −7Browse files

Unified · Split

doc/usage.md+79−7
@@ -8,7 +8,7 @@ · 7 unmodified lines
8## Overview8## Overview
9The overall structure when using the library is as follows:9The overall structure when using the library is as follows:
10```10```
11initialize `mu_Context`11initialise `mu_Context`
12 12
13main loop:13main loop:
14 call `mu_input_...` functions14 call `mu_input_...` functions
@@ -19,7 +19,7 @@ main loop: · 4 unmodified lines
19```19```
20 20
21## Getting Started21## Getting Started
22Before use a `mu_Context` should be initialized:22Before use a `mu_Context` should be initialised:
23```c23```c
24mu_Context *ctx = malloc(sizeof(mu_Context));24mu_Context *ctx = malloc(sizeof(mu_Context));
25mu_init(ctx);25mu_init(ctx);
@@ -38,8 +38,8 @@ mu_begin(ctx); · 12 unmodified lines
38Before any controls can be used we must begin a window using one of the38Before any controls can be used we must begin a window using one of the
39`mu_begin_window...` or `mu_begin_popup...` functions. The `mu_Container`39`mu_begin_window...` or `mu_begin_popup...` functions. The `mu_Container`
40for the window is expected to be either zeroed memory in which case40for the window is expected to be either zeroed memory in which case
41it will be initialized automatically when used, or to have been41it will be initialised automatically when used, or to have been
42intialized manually using the `mu_init_window()` function; once used,42initialised manually using the `mu_init_window()` function; once used,
43the `mu_Container`'s memory must remain valid until `mu_end()` is called43the `mu_Container`'s memory must remain valid until `mu_end()` is called
44at the end of the frame. The `mu_begin_...` window functions return a44at the end of the frame. The `mu_begin_...` window functions return a
45truthy value if the window is open, if this is not the case we should45truthy value if the window is open, if this is not the case we should
@@ -73,7 +73,7 @@ The library generates unique IDs for controls internally to keep track · 27 unmodified lines
73of which are focused, hovered, etc. These are generated either from the73of which are focused, hovered, etc. These are generated either from the
74pointer passed to the function (eg. for treenodes, checkboxes, textboxes74pointer passed to the function (eg. for treenodes, checkboxes, textboxes
75and sliders), or the string/icon passed to the function (eg. buttons). An75and sliders), or the string/icon passed to the function (eg. buttons). An
76issue arrises then if you have several buttons in a window or panel that76issue arises then if you have several buttons in a window or panel that
77use the same label. The `mu_push_id()` and `mu_pop_id()` functions are77use the same label. The `mu_push_id()` and `mu_pop_id()` functions are
78provided for such situations, allowing you to push additional data that78provided for such situations, allowing you to push additional data that
79will be mixed into the unique ID:79will be mixed into the unique ID:
@@ -95,7 +95,7 @@ mu_end(ctx); · 15 unmodified lines
95 95
96When we're ready to draw the UI the `mu_next_command()` can be used96When we're ready to draw the UI the `mu_next_command()` can be used
97to iterate the resultant commands. The function expects a `mu_Command`97to iterate the resultant commands. The function expects a `mu_Command`
98pointer initialized to `NULL`. It is safe to iterate through the commands98pointer initialised to `NULL`. It is safe to iterate through the commands
99list any number of times:99list any number of times:
100```c100```c
101mu_Command *cmd = NULL;101mu_Command *cmd = NULL;
@@ -119,7 +119,79 @@ See the [`demo`](../demo) directory for a usage example. · 17 unmodified lines
119 119
120 120
121## Layout System121## Layout System
122*TODO*122The layout system is primarily based around *rows* — Each row
123can contain a number of *items* or *columns* each column can itself
124contain a number of rows and so forth. A row is initialised using the
125`mu_layout_row()` function, the user should specify the number of items
126on the row, an array containing the width of each item, and the height
127of the row:
128```c
129/* intialize a row of 3 items: the first item with a width
130** of 90 and the remaining two with the width of 100 */
131mu_layout_row(ctx, 3, (int[]) { 90, 100, 100 }, 0);
132```
133When a row is filled the next row is started, for example, in the above
134code 6 buttons immediately after would result in two rows. The function
135can be called again to begin a new row.
136
137As well as absolute values, width and height can be specified as `0`
138which will result in the Context's `style.size` value being used, or a
139negative value which will size the item relative to the right/bottom edge,
140thus if we wanted a row with a small button at the left, a textbox filling
141most the row and a larger button at the right, we could do the following:
142```c
143mu_layout_row(ctx, 3, (int[]) { 30, -90, -1 }, 0);
144mu_button(ctx, "X");
145mu_textbox(ctx, buf, sizeof(buf));
146mu_button(ctx, "Submit");
147```
148
149If the `items` parameter is `-1`, the `widths` parameter is ignored
150and controls will continue to be added to the row at the width last
151specified by `mu_layout_width()` or `style.size.x` if this function has
152not been called:
153```c
154mu_layout_row(ctx, -1, NULL, 0);
155mu_layout_width(ctx, -90);
156mu_textbox(ctx, buf, sizeof(buf));
157mu_layout_width(ctx, -1);
158mu_button(ctx, "Submit");
159```
160
161A column can be started at any point on a row using the
162`mu_layout_begin_column()` function. Once begun, rows will act inside
163the body of the column — all negative size values will be relative to
164the column's body as opposed to the body of the container. All new rows
165will be contained within this column until the `mu_layout_end_column()`
166function is called.
167
168Internally controls use the `mu_layout_next()` function to retrieve the
169next screen-positioned-Rect and advance the layout system, you should use
170this function when making custom controls or if you want to advance the
171layout system without placing a control.
172
173The `mu_layout_set_next()` function is provided to set the next layout
174Rect explicitly. This will be returned by `mu_layout_next()` when it is
175next called. By using the `relative` boolean you can choose to provide
176a screen-space Rect or a Rect which will have the container's position
177and scroll offset applied to it. You can peek the next Rect from the
178layout system by using the `mu_layout_next()` function to retrieve it,
179followed by `mu_layout_set_next()` to return it:
180```c
181mu_Rect rect = mu_layout_next(ctx);
182mu_layout_set_next(ctx, rect, 0);
183```
184
185If you want to position controls arbitrarily inside a container the
186`relative` argument of `mu_layout_set_next()` should be true:
187```c
188/* place a (40, 40) sized button at (300, 300) inside the container: */
189mu_layout_set_next(ctx, mu_rect(300, 300, 40, 40), 1);
190mu_button(ctx, "X");
191```
192A Rect set with `relative` true will also effect the `content_size`
193of the container, causing it to effect the scrollbars if it exceeds the
194width or height of the container's body.
123 195
124 196
125## Style Customisation197## Style Customisation

Keyboard shortcuts

General

Show keyboard shortcuts
?
Focus the current search
/

Issues and pull requests

Open filters
f

Issues, pull requests and Inbox

Select next item
j↓
Select previous item
k↑
Open selected item
Enter
Dismiss filters or clear selection
Esc

Repository code

Go to file
t