Dynamic composition of application parts

[oklemencic]

In all the examples I have so far only seen that the UI for the whole application is defined upfront statically. The only dynamic aspects are conditionals and repetition like documented at https://slint-ui.com/releases/0.2.0/docs/cpp/markdown/langref.html#repetition

Is there a way to achieve some truly dynamic composition (other than including all possible widget types and binding the visibility of those).

One of my use cases for this is a kind of "report representation" consisting of multiple elements that are put one after the other. But there are 5-10 different element types (e.g. image, SVG, text, table, chart, etc.). Ideally I can create the widget via code and then attach it in some way in the "main page".

[ogoffart]

Currently this is a bit awkward and we're open to find out what kind of syntax this could have.

Several options are available.

1. Use several for for each kind of elements

property <[ImageInfo]> images;
property <[SvgInfo]> svgs;
property <[TextInfo]> texts;
//...
for it in images : Image { ... }
for it in svgs : Svg { ... }
for it in texts : Text { ... }

2. use a a bunch of if

for it in items : Rectangle {
   // this could clearly benefit to have some C-style `enum` in the language
   if (it.type == 0) : Image { ... }
   if (it.type == 1) : Svg { ... }
   if (it.type == 2) : Text { ... }
}

the if make sure only one element is instantiated.

I was thinking maybe there should be some kind of a switch or something to select an element amongst some.

But what would be the ideal solution that would work for you? What kind of syntax would you use for it.

[akiross]

Option 1 seems ok if the number of types of elements is limited. I couldn't find in the docs a way to push/append something from slint code: in the todo sample that is done via rust (the todo_added adds a TodoItem to the list): is it necessary to do this in the host code (rust/c++)?
That's Ok, but adds a bit to the awkwardness of using that approach.

[tronical]

Yes, adding elements to a model needs to be done in Rust or C++. The VecModel in Rust or VectorModel in C++ have functions for that.

[oklemencic]

I was more thinking of a solution via code, e.g. by providing some way to create a "child control" via code and then add it to the main control. I am not sure if the current approach to generate the item_tree could be adapted to make item nodes dynamically.

The second place where this would be really helpful is for composing whole applications. In my case, I am having 10-30 different screens, where the user can navigate to. Now I would need to add all those screens to the main window and use the "if approach". But additionally this would also require to bind all the properties via the main window (see example code below).

export MainWindowViewModel := {
        property <int> activeScreen;
	property <Screen1ViewModel> screen1Model;
	property <Screen2ViewModel> screen2Model;
	property <Screen3ViewModel> screen3Model;
	...
}

MyWindow := MainWindow  {

	property <MainWindowViewModel> model;

	if (model.activeScreen == 0): Screen1 {
		model: model.screen1Model
	}
	if (model.activeScreen == 1): Screen2 {
		model: model.screen2Model
	}
	if (model.activeScreen == 2): Screen3 {
		model: model.screen3Model
	}
}

Or is there a different way to do that?

[al-sabr]

I would recommend to take a look at how the apache flex framework implements ListView with Item renderers.

https://flex.apache.org/asdoc/spark/components/List.html#includeExamplesSummary

https://flex.apache.org/asdoc/spark/components/supportClasses/ItemRenderer.html

A tutorial can be accessed here : https://www.peachpit.com/articles/article.aspx?p=1676705

YouTube : https://m.youtube.com/watch?v=sXCYFQexAcY

[chrsoo]

I trying to find a UI framework for implementing an INDIGO application in Rust.

INDIGO is highly dynamic and the number of devices and their properties are not known at design time. Also a device might be added or removed at any point in runtime, and the same goes for their properties.

At first blush, Slint looks like a very good candidate but given that I cannot change the UI programmatically as discussed here and indicated in #4620, Slint is unfortunately a no-go for my project. :-(

I am not in a position to say exactly how that support should work, but suffice it to say that I need to be able to react to INDIGO events and add/remove device and property components/widgets from closures registered on the INDIGO model that I am developing.

[hunger]

@chrsoo: What are these devices? It's trivial to add data to a Model, so if a device is just a bunch of data, then that is perfectly doable in Slint, whatever that data is... independent of number of data elements or how volatile the set of data is. We do have a Property Editor written in Slint in our live preview... that does show an arbitrary list of properties (with a limited and known set of types to choose from for each property). It is pretty simple to build something like that.

It does get tricky when a device requires a custom UIs that is defined per device or even defined by the device itself. We do not have a tailor-made solution for such a use case yet. We do have an internal element we use to embed your UI into the live preview, but that is internal for the time being (and rust only). That could be built into something that works quite well for such dynamic use cases in the future. I doubt that helps you, as you seem to need something now.

[chrsoo]

@hunger well, the real-world devices are things like focus motors for telescopes, astronomy cameras, normal DSL, computerised astronomy mounts, guide cameras, heaters, dome control units, and everything else that can be connected to a computer network under the stars.

From an OT/IT perspective and in terms of the UI devices are just a name that groups properties that in term groups items which are named key/value pairs. Each property is a type - text, number, switch, light, or blob. Around 20 interfaces define a standard set of required properties but custom properties can also be defined for any device. A more detailed description can be found over at rust-lang.org.

A generic UI could have one UI widget per property type. A more advanced UI could have a few standard widgets for the different interface types. The point though, is that devices, properties, and items appear and disappear dynamically at runtime not much if anything can be assumed about the specific configuration at run-time.

So... what I need to do for a generic UI is basically a master detail view where the master contains a list of device names, with the detail view containing an arbitrary number of properties, each with an arbitrary number of items (all of the same type and using the same widget). And where the devices, properties, and items all can be added/removed at an arbitrary point in time by messages coming in on the INDIGO bus. Is this possible with Slint?

[hunger]

So the entire thing could look a bit like this?

enum ValueKind {
   Foo,
}

struct Value {
    // this is ugly as Slint has no rust-like enums yet: We are unrolling all possible data we
    // want to associate with an enum value plus a discriminator (kind) into one struct here!
    kind: ValueKind,
    value-string: string,
    value-int: int,
    ...
}

struct Property {
    key: string,
    value: Value,
}

struct Device {
    name: string,
    properties: [Property],
}

component MainWindow {
    in property <[Device]> devices;
    
    VerticalLayout {
        for device in root.devices: Rectangle {
             Text {
                 text: device.name
             }
             for property in device.properties {
                  Text {
                      text: property.key;
                  }
                  if property.value.kind == ValueKind.Foo: Text {
                      text: "I'm a Foo property";
                  }
                  ... more if clauses for the other ValueKinds ...
             }
        }
    }
}

You can then from your business logic manages a VecModel of Devices, which in turn contain another VecModel of Properties, unserting/updating data in that model as needed.

Note that you really want to update the existing data, not throw out the entire set and recreate the entire model: That would lead to all the widgets getting recreated, loosing their state.

Our PropertyEditor in the live preview (go to slintpad.com, enter "Edit" mode, the thing on the right side) does something like that. The code can be found here: https://github.com/slint-ui/slint/blob/master/tools/lsp/ui/views/preview-view.slint

I hope that gives a bit of inspiration :-)

[chrsoo]

Thanks! I will have a look.

[moolight-seashell]

Hii
Do we have news on this ?

and yep if we want to make basicaly a "mutiple documents interface" with dynamic layouts

each document as a "component" with a backend / controller

this can only be acheve properly from code i guess
a custiom slint syntax cannot realy solve this with a proper way

do we have an "api" to walk and edit the "dom" ?

[npwoods]

I'll second the idea that ideally, there would be a way to manually alter the control hierarchy without properties, callbacks and models. Properties, callbacks and models are great... 95% of the time.

In my application, context menus are a particular pain. The logic to generate them is almost completely on the application side, and I have to create very basic models and properties to carry things over to Slint land. This works, but is awkward and sometimes necessitates obnoxious hacks (e.g. - certain items being duplicated because in certain conditions they can be submenus)