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

[bugzilla-daemon at webkit.org]

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





------- Comment #15 from aroben at apple.com  2007-07-23 10:13 PDT -------
(In reply to comment #14)
> (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.

Great.

> > 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).

That seems fine to me.

> 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.

I think using signals is a good idea. I just meant that you should consider
keeping the names of the signals close to the names of the delegate methods,
and the names/responsibilities of the WebKitGtk{Frame,Page} methods similar to
their equivalents on Mac/Windows.

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

Presumably the methods are on WebFrame because they make sense to be called on
any frame -- putting them on Page is not equivalent.

> 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.

That's great. It's good not to develop an API in a bubble.


-- 
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.