Support for multiple backends

[lhoward]

Creating a separate issue for this. It would be good to support multiple backends in a clean way (i.e. not having to fork SwiftCrossUI).

For embedded applications it would be nice to support LVGL (see LVGLSwift which I am working on at present).

[stackotter]

Thanks for the separate issue; I’m planning on starting on this soon as it’s been requested 3 times now (in one form or another)

[lhoward]

Yeah, I took a look at Tokamak, they seem to have done a good job of using shims to support multiple backends. For my application I'm going to see how hard it will be to prototype using LVGLSwift directly, at least in doing that the wrapper will be more useful.

I just found this today too – could be another interesting backend – https://learn.microsoft.com/en-us/azure/rtos/guix/. Not quite open source, but free for popular MCUs.

[stackotter]

I’ve done a bunch of refactoring and it’s now possible to implement new backends! LVGL might be tricky because it’s different, but the other two backends Ive tried adding experimentally (AppKit and Qt) only took 100 or so lines to get hello world up and running.

[stackotter]

I started looking into creating an LVGL backend, but it looks like I'll have to do some more work on the backend API first. Unfortunately LVGL 'widgets' have to be constructed from the top down (a child can only be created once its parent exists), whereas Qt, Gtk, and AppKit are all the opposite. Hopefully I can find a nice way to generalise it to give backends the flexibility to request certain ordering (which will be easier said than done).

[stackotter]

Actually, I've got a better idea. I can just create a wrapper for LVGL widgets that only actually creates them once they're added to a parent.

[lhoward]

Not sure if the LVGL backend I started (and abandoned) for TokamakUI is any help:

https://github.com/TokamakUI/Tokamak/compare/main...PADL:Tokamak:inferno

[stackotter]

Yeah thanks, I had a look at that. Looks like Tokamak backends are implemented quite differently (and with a lot more code).

Anyway I did manage to get the basics of an LVGL backend implemented (enough for the CounterExample if you removing the .padding(10) modifier which isn't implemented yet). For now I probably won't work on that backend much more unless you'd be interested in using it (because it's probably not a backend that most app devs will need). But it's exciting that it would be possible! If someone wanted to try finishing off the LVGL backend it probably wouldn't take much longer than a day or 2 (the Gtk backend is only 400ish lines).

[lhoward]

That’s exciting! I had provisionally decided to go down the Flutter path but perhaps this is worth taking another look at!

[stackotter]

All good if you decide to go down the Flutter path, it'll probably be more straightforward for you cause it's not so experimental, but the LVGL backend would definitely be a cool thing to come out of you using SwiftCrossUI :) If you do want to I'd be happy to help by implementing the rest of the LVGL backend (but even once implemented it'd need some ironing out along the way to fix layout issues you encounter and stuff, just like the Gtk backend did).

[lhoward]

I’m deep in the non-UI parts of my project so I’ll look into it again when I come up for air. There might be some synergies/interest with the SwiftIO project, too.

[stackotter]

That could be cool 👌

This might not be along the line that you were thinking but I just had the idea 😅:

var body: some ViewContent {
  Led(pin: 4, state: isOn)
  Text(isOn ? "On" : "Off").lcd(dataPin: 5, clockPin: 6)
  Button("Toggle") {
    isOn = !isOn
  }.pin(7)
}

I haven't used lcds in a while so I just made up what types of pins the need, but you get the gist. You could describe hardware interfaces declaratively.

[lhoward]

That sounds perfect for SwiftIO :) My project has so many layers of abstraction, for better or worse, that none of the UI code will know anything about pins ;)

[stackotter]

Since multiple backends are now supported I'll close this issue. But feel free to open another one for the SwiftIO idea