[webkit-qt] Road towards initial WebKit2 API for Qt 5.0

Alexis Menard alexis.menard at openbossa.org
Wed Dec 7 14:25:33 PST 2011


On Wed, Dec 7, 2011 at 4:29 PM,  <simon.hausmann at nokia.com> wrote:
>
> On Dec 6, 2011, at 9:18 PM, ext Jesus Sanchez-Palencia wrote:
>
> Hi,
>
> I like the way the API looks already and it seems to me that for reaching
> this "minimal set" we don't need much more. Perhaps we need the history API
> to land and fix the bugs Simon and Laszlo have opened.
>
>
> Yeah, what about the history? I'm having difficulties telling whether the
> model for back/forward is totally _right_ (it certainly looks pretty though
> :). I'd like to hear Tor Arne and Alexis' opinion here. What do you
> guys think? Is the history model a no-brainer to put it or do we need to
> cook it? What do the others think?
>

The patch is there, I put the history models as experimental. Each
model today has only two roles but the old WK1 API had more data from
each history item (icon, originalUrl and so on). Maybe in the meantime
that we don't know yet which field is good to have, not good to have
we can let it to experimental. Maybe later we can move it to the
public API.

>
> I also agree that having web context (and therefore download, etc) either as
> an experimental QML API or either as a private C++ one is something that we
> still need to figure out.
>
> Simon, I know it was meant to be just a mock-up, but there is also the
> preferences item we can get through the webview and set its properties,
> right?
>
>
> To be honest, I would prefer to see "preferences" move to experimental. (Not
> possible right now due to the qml bug, but with the next Qt update on Friday
> we
> should be able to fix that). The reason is because the preferences are
> backed by WKPreferences, which is tied to a page group actually.
>
> I'd rather see us figure out the page group thing first before making
> preferences public, and I don't see anything critical in there, apart from
> maybe
> enabling/disabling JavaScript & Plugins that say an email reader app may
> need. That may not be a case supported though only the public API right now.
>
>
>>    property Item page;
>
>
> I'm not fully aware of the use-cases of this. I couldn't find any qml tests
> using it and we don't use it on snowshoe as well. So then I agree with
> Jocelyn and I'm up with moving this to experimental and keep it aligned with
> Simon's "criteria" of what stays or not in experimental.
>
>
> Good point. Does anybody else have an opinion here?
>
>
>>
>>    function loadHtml(html, baseUrl) {}
>
>
> I support keeping this API as it is. I think it's crystal clear like that.
>
>
> Me, too.
>
>
>
> And I like the way QtWebKit has been moving since the past few weeks. :)
>
>
> It's one hell of a ride right now - the good kind :)
>
>
> Simon
>
>
> _______________________________________________
> webkit-qt mailing list
> webkit-qt at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
>



-- 
Alexis Menard (darktears)
Software Engineer
INdT Recife Brazil


More information about the webkit-qt mailing list