Styled UI

At the starting page of the UI Subsystem, the style-array is mentioned as one of four ways to create your UI.

This page takes a closer look at this feature.

The style-array Format

A style-array looks like this:

[
  [ Panel, { min_height: 144 }, { dock: dock.top, padding: 12 } ,
      [ Label, struct_join(label_struct, { text: "[scale,1.5][ci_accent]UTE - raptor Unit Test Engine", }), { position: [48,32]} ],
      [ Label, struct_join(label_struct, { text: "[scale,1.5]Discovered Test Suites", }), { position: [48,84], name: "middel"} ],
      [ Label, struct_join(label_struct, { text: "[scale,1.5]Detailled Test Results", }), { position: [968, 84]} ],
  ],

  [ ScrollPanel, struct_join(scrpanel_struct, { min_width:1000, }), { 
      name:        "der_rechte",
      dock:        dock.right,
      content_autofill:  [true, 4],
      content_object:    [UnitTestResultsViewer, { detail_mode: true, }]
    }
  ],

  [ ScrollPanel, scrpanel_struct, { 
      name:        "new_style",
      dock:        dock.fill,
      content_autofill:  [true, 4],
      content_object:    [UnitTestResultsViewer, { detail_mode: false, }]
    }
  ]
]

Let's go through this, step by step.

• It must be an array (and not a struct) because the order matters and structs can not guarantee to have a constant order of items.
• You always create one single array which contains several sub-arrays. Speaking of json or GML, you always create
  [ ...content... ].
• Each of the sub-arrays follows this structure:
  • [ type_to_create, <init_struct>, <style_struct> ] for any non-container item (like the Label objects above) or
  • [ type_to_create, <init_struct>, <style_struct>, [ next-level-subarray], ... ] for containers (like the Panel above, which contains the Labels)
• So you create any hierarchy in the form of array containing a type, init/style structs and another inner array for the elements of the container

Advantages of this approach

• You do not have to deal with the ControlTree itself, no need to care about when and what to .build(), no need to call all those functions.
• Just pure content, pure data.
• Highly dynamic, as you could even build such an array at runtime of your game and create dynamic UIs (like windows for inventories and similar things) specialized for the view you want to show.
• It can be "put together" like Lego pieces at runtime.
• It is compatible with the json format, so you can define your UI freely in your game configuration files, hence you could even "drop" parts of those array from your Race query to create custom details/properties views based on the dropped item from a loot table.