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
_______________________________________________
webkit-qt mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
