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

[Simon Hausmann]

On Monday, October 10, 2011 07:42:18 PM ext Caio Marcelo de Oliveira Filho wrote:
> 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.

I guess that would be fine, too.

> > 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"?

$NOW + x ;-)

It's not uncommon that people would like to "catch" JS alerts for example. I believe these virtual functions in QWebPage
are frequently re-implemented. 
 
> > 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.

Yeah, the Dialog doesn't have to be structured. I thought of it the same way
as you did.
 
> 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.

It's the context menu where I thought a bit more structure would make it
easier to customize. But after what you said I'm not sure anymore :). We should
just try it out I guess.


Simon