[webkit-qt] WK2 QML api discussions, round 1

[Caio Marcelo de Oliveira Filho]

Hello Simon,

Thanks for this email!

> 2) Resource handling
>    experimental {
>
>        schemeDelegates: [
>            "about": { // handler function takes "request" and "response" parameter
>                if (request.url = "about:browser")
>                    response.send("....");
>        ]
>
>    }
>
> }
>

My suggestion here would be that schemeDelegates take a list of
"SchemeHandler" objects (with appropriate properties),
instead of taking scheme -> JS function pairs. It will mimick the same
solution we have for states and handle nicely
the case of making one of those handlers in C++. Depending on the
data-sources used by these handlers, this can be
very convenient.


> 3) Dialogs (Alert, Confirmation)
> 4) Context Menu
>
> We kind of put those into the same category and realized that there are two things we want:
>
> 1) A sensible out-of-the-box behaviour/implementation
> 2) The ability (in the future) to customize.

Can you elaborate what you mean by "in the future"?


> We figured one possible "QML" way of doing the customization would be by using a pattern similar to the delegate
> components in the item views:

Cool. In the discussion for JS Dialogs, we reached a similar pattern,
however we felt that this level of customization
was too much for dialogs. But I think it's fine trying it inside
"experimental" extension.



> WebView {
>
>    experimental {
>
>        uiDelegate {
>
>            alertDialog: Component{
>                Dialog {
>                    ....
>                }
>            }
>
>            contextMenuItem: MenuItem { } // Properties set by WK2 implementation
>
>            contextMenu: Component {
>                property list<Item> contextMenuItems; // Property set by WK2 implementation
>
>                ContextMenu {
>                    MenuLayout {
>                        children: contextMenuItems;
>                    }
>                }
>            }
>
>        }
>
>    }
>
> }

I would go for a less structured API, at least for starting. In the
dialog, is enough that once we instantiate the
object from the component, we set some property with alert message and
expect a signal (dismiss or something like that)
to be emitted.

For the context menu, I think we should start with the same idea. One
component, that's filled with data via the properties (maybe
just a "model" property) and emits signals that we watch.


Cheers,

-- 
Caio Marcelo de Oliveira Filho
OpenBossa - INdT