examples: Add uefi-demo

[medhefgo]

This is the UEFI port I wrote some time ago to explorer no_std support in slint. It works fairly well and might be useful to others.

Easy to test with:

rustup target install x86_64-unknown-uefi
cargo build --package uefi-demo --target x86_64-unknown-uefi
qemu-system-x86_64 -bios /usr/share/edk2-ovmf/x64/OVMF.fd -kernel target/x86_64-unknown-uefi/debug/uefi-demo.efi

In theory, i686 and aarch64 are also supported. In practice there are some rust bugs in the way (rust-lang/rust#62729, rust-lang/rust#98254).

[CLAassistant]

All committers have signed the CLA.

[medhefgo]

Here are some screenshots (sadly, the AboutSlint doesn't seem to get rendered/rasterized cleanly).

[tronical]

Wow! This is really really cool. ❤️ The code looks very clean, too.

We'd love to take this in - it's a great show-case :)

One open question in that regard is the licensing. I see two options (but perhaps there are more):

1. we can merge it if you tell us under what license you're contributing this code
2. or you sign our CLA (see the bot's message) and that means we can merge it.

What do you think?

[medhefgo]

CI fails because it's testing rust 1.66, while the UEFI target was stabilized in 1.68. Also, I believe the CI isn't compiling the crate for the x86_64-unknown-uefi target. I'm not sure how to proceed here.

[ogoffart]

We can change the CI scripts to --exclude that example from the normal build (we already exclude the mcu crates)
And then we can add an extra build for that example with the right target.
I'll try have a look at that tomorrow if you haven't done it before.

[medhefgo]

Btw, feel free to ask any question on the UEFI side of things.

Some thoughts I had while working on this:

• I don't get why the WindowAdapter trait is sealed. It imho makes sense for a custom platform implementation to be able to decide/dictate how windows work.
• MinimalSoftwareWindow does not implement window hiding/closing from what I can tell (in fact, it always reports a window as hidden). Because of this, it's also impossible to implement the quit event loop on last window close flow.
• In fact, I don't see a way to hide/minimize/close a window from within slint without doing a round-trip to rust code.
• EventLoopProxy feels weird, and I'd rather have it as part of Platform.
• There is no quit() function to request exiting the event loop from within slint code either.
• Timers should imho also be available as a slint Element.

[ogoffart]

Thanks for the feedback.

I don't get why the WindowAdapter trait is sealed. It imho makes sense for a custom platform implementation to be able to decide/dictate how windows work.

The goal is to un-seal it in the future. We just wanted to have the MVP to work on the MCU to be stable. We still have some work to polish the remaining API.

MinimalSoftwareWindow does not implement window hiding/closing from what I can tell

MinimalSoftwareWindow is meant to be used in a fullscreen mode without window managers. So there is no concept of hiding and closing without a WM. Is there a concept of window in UEFI?

EventLoopProxy feels weird, and I'd rather have it as part of Platform.

Could you elaborate? EventLoopProxy must be Send between threads. But the Platform itself is not Send and need to stay in the UI thread.

There is no quit() function to request exiting the event loop from within slint code either.

True, you need to create a callback that call slint::quit_event_loop().
We could create a builtin function for it, but we are also separating the UI and the business logic, and quitting is part of the business logic.

Timers should imho also be available as a slint Element.

One concept we have is that each Element is "visual" and has a geometry and stuff.
Also Timers are for the business logic.
What would be the usecase for timers as slint element?

[tronical]

Thank you!

[medhefgo]

MinimalSoftwareWindow is meant to be used in a fullscreen mode without window managers. So there is no concept of hiding and closing without a WM. Is there a concept of window in UEFI?

If a Window element could hide/close itself from within slint it would allow for easy ways to implement exiting the main loop without going through EvenLoopProxy. In fact, right now you cannot even do so with native code as MinimalSoftwareWindow hardcodes its visibilty to false.

One concept we have is that each Element is "visual" and has a geometry and stuff.
Also Timers are for the business logic.
What would be the usecase for timers as slint element?

Doing a (safety) countdown is not business logic. ("Are you sure you want to proceed nuking everything from orbit? Nuking in 10s…")
Any sort of delayed UI action (that aren't animations).

[K900]

This is cool, I've actually done a similar thing here: https://gitlab.com/K900/bootloader

Maybe we should try and build a generic UEFI platform implementation as a crate?