[Webkit-unassigned] [Bug 14678] [gdk] API Drafting

[bugzilla-daemon at webkit.org]

http://bugs.webkit.org/show_bug.cgi?id=14678





------- Comment #14 from freyther at handhelds.org  2007-07-23 02:00 PDT -------
(In reply to comment #11)
> Nothing in WebKit/gtk should be in the WebCore namespace (though I realize that
> right now many things are in WebCore that should be in WebKit/gtk). I think you
> can move everything in webkitgtkprivate.cpp out of the WebCore namespace. Would
> be good to move ChromeClientGdk, too, though that could be a separate patch.

I have started with moving ChromeClientGdk into WebKitGtk namespace.

> +    if (!cresult)
> +        return false;
> +    else {
> +        result = UTF8Encoding().decode(cresult, strlen(cresult));
> +        g_free(cresult);
> +        return true;
> +    }

I forgot that, the final patch will have that changed as well.


> r=me, though I think it would be nice to get someone with GTK+ experience to
> have a look at it (maybe Alp Toker?). You should also keep in mind what Maciej
> said about the benefits of keeping the API relatively close to the Mac/Windows
> API.

Maciej did some handwaving that there is something in the WebKitQt API he
didn't like and I might have already followed that. IMHO WebView <->
WebKitGtkPage. I have decided against the name View as IMHO this will trigger
people to search for a Model as well (The toolkits using some flavor of
Model-View-Controler have people trained to search for a model when they see
the name View).

The good thing about WebView and its delegates is the grouping. You group
policy, ui, form handling,... nicely. But with C++ and C/GObject I think using
plain signals for informational events/notification/changes feels native. For
the WebKitPolicyDelegate, after a small discussion with my GSoC mentor, we will
go with signals with a default handler. This allows to connect to the signal or
subclass them and will give a native feeling.
So the plan is to have methods found in WebView in WebKitGtkPage, most of
WebFrame in WebKitGtkFrame. The delegates will be implementes as signals
emitted mostly from WebKitGtkPage. It will be enough to just connect to
WebKitGtkPage to get everything needed.

For some methods where you do [[webView _mainFrame] xyz:...] I'm tempted to
place them in WebKitGtkPage directly and already did so.

I have not used the WebView myself, just had a look at the Examples installed
in /Developers/Examples, but I think the APIs will be rouhgly similiar.


I have integrated WebKitGtkPage into my OpenMoko RSSReader, and there is a
first version of midori using WebKitGtkPage as well. So the API is to some
degree already usable and will slowly grow.


> It's great to see all those WebCore headers gone from GdkLauncher!

:)


-- 
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.