Top-level Window type in DSL

[brianberns]

This pull request adds Window and KeyBinding types to the DSL. Example:

    let view (state: State) (dispatch) =
        Window.create [
            Window.title $"Hello {state.Name}!"
            Window.icon icon
            Window.sizeToContent SizeToContent.WidthAndHeight
            Window.child (
                TextBox.create [
                    TextBox.text state.Name
                    TextBox.onTextChanged (NameChanged >> dispatch)
                ]
            )
            Window.keyBindings [
                KeyBinding.create [
                    KeyBinding.key Key.F11
                    KeyBinding.execute (fun _ ->
                        FullScreen true
                            |> dispatch)
                ]
                KeyBinding.create [
                    KeyBinding.key Key.Escape
                    KeyBinding.execute (fun _ ->
                        FullScreen false
                            |> dispatch)
                ]
            ]
        ]

[JaggerJo]

Really nice work!

A few things:

• In the hello world example you added there is still a host window. If we define Windows anyway we could also create them that way. I can take a stab at this once I'm back from vacation in ~2 weeks.

• can we rename the sample? And also add a component based sample app?

• The changes in the patcher need consideration. I'd prefer not to have special cases case for IView

Looking forward to merging this. Think it's really useful 👍

[JaggerJo]

We could adapt the component system a bit so we could have a WindowComponent (needs a better name tho).

could look like this:

WindowComponent.create(fun ctx ->
    ctx.attrs [
        Window.title $"Hello {state.Name}!"
        Window.icon icon
        Window.sizeToContent SizeToContent.WidthAndHeight
    ]

    TextBlock.create [
        TextBlock.text "Hello"
    ]
)

This would make the HostWindow optional.

@brianberns what do you think?

[brianberns]

Thanks. Glad you like it!

I agree that we might want to get rid of HostWindow eventually, but I didn't want to go that far in my first attempt. Having a window component is probably a good idea but is an area I haven't explored yet. We also have to consider backwards compatibility for existing apps.

The patcher change I made is ugly because I didn't want to break existing code. This is another part of the architecture that I'm still learning, so I will defer to you on the best way to integrate.

I'd be happy to rename the example app. Should we call it something like "TopLevelWindow"? It's just a tiny app I made for testing purposes, so we could also replace it with something better, or just upgrade the other examples to use Window instead of having a new example at all.

[JaggerJo]

Thanks. Glad you like it!

I agree that we might want to get rid of HostWindow eventually, but I didn't want to go that far in my first attempt. Having a window component is probably a good idea but is an area I haven't explored yet. We also have to consider backwards compatibility for existing apps.

We definitely need to keep the existing implementation so we don't break existing code (that's always the top priority). But we make it simpler to write new apps that now don't need to use the HostWindow (but still can).

The patcher change I made is ugly because I didn't want to break existing code. This is another part of the architecture that I'm still learning, so I will defer to you on the best way to integrate.

We might get away with close to zero changes to the patcher from what I've seen now.

I'd be happy to rename the example app. Should we call it something like "TopLevelWindow"? It's just a tiny app I made for testing purposes, so we could also replace it with something better, or just upgrade the other examples to use Window instead of having a new example at all.

We can defer that. Maybe we can integrate the sample in an existing sample application once we solve the remaining issues.