Difference between revisions of "UI Autolayout"
From cxwiki
| Line 1: | Line 1: | ||
| − | <div class="mw-parser-output"> | + | <div class="mw-parser-output"><div class="mw-parser-output"> |
The cxsource framework provides automatic layout facilities, allowing user interface layouts to be built with runtime-evaluated rules rather than hardcoded values. This offers a number of immediate benefits: | The cxsource framework provides automatic layout facilities, allowing user interface layouts to be built with runtime-evaluated rules rather than hardcoded values. This offers a number of immediate benefits: | ||
| Line 17: | Line 17: | ||
| | ||
| + | |||
| + | = Alignment Containers = | ||
| + | |||
| + | TBD. | ||
= UX Files = | = UX Files = | ||
| − | + | While it is possible to create autolayout hierarchies completely from code, this tends to be a lot of work and generally isn't necessary. Instead, [[UX File]]s are typically loaded (using [[TextConfig]]) and parsed to build the user interface. Each UX file can contain a complete hierarchy, but it is also possible to separate sub-components out into their own files to keep things simple or to enourage re-use. | |
| + | |||
| + | In the rare cases where program code needs to modify the interface layout at runtime, modifications can be performed at any time after the initial loading from the UX File is complete. | ||
| − | = Alignment | + | = Alignment Methods = |
TBD. | TBD. | ||
| − | = | + | = Autolayout Lock = |
TBD. | TBD. | ||
| − | </div> | + | </div> </div> |
Revision as of 05:16, 5 March 2018
The cxsource framework provides automatic layout facilities, allowing user interface layouts to be built with runtime-evaluated rules rather than hardcoded values. This offers a number of immediate benefits:
- The underlying fonts and control appearances can be swapped out, leading to changes in the user interface layout requirements, without having to manually update every single UI.
- This is especially useful when developing cross-platform interface layouts where the native appearance and even font rendering may require subtle changes to the layout.
- Localised versions of the UI can reflow correctly without running out of space and without leaving ugly gaps.
- A lot of manual coding, or manual calculations, can be skipped in favor of automated placement.
- Layouts can adjust as windows are resized, including controlled collapse of elements when the window is too small to fit the full user interface.
- Layouts can be hot-reloaded during development.
- Window sizes and size limitations are calculated automatically, and can automatically adapt as the UI changes.
- Layouts can be animated easily.
There are also some downsides:
- Calculating the layout at runtime is slower than simply loading some predefined values.
- Debugging problems in the user interface layout is sometimes more time-consuming.
Alignment Containers
TBD.
UX Files
While it is possible to create autolayout hierarchies completely from code, this tends to be a lot of work and generally isn't necessary. Instead, UX Files are typically loaded (using TextConfig) and parsed to build the user interface. Each UX file can contain a complete hierarchy, but it is also possible to separate sub-components out into their own files to keep things simple or to enourage re-use.
In the rare cases where program code needs to modify the interface layout at runtime, modifications can be performed at any time after the initial loading from the UX File is complete.
Alignment Methods
TBD.
Autolayout Lock
TBD.