On Aug 25, 2009, at 12:57 PM, Xan Lopez wrote:
On Tue, Aug 25, 2009 at 10:44 PM, Kristian Rietveld<k...@gtk.org>
wrote:
On Tue, Aug 25, 2009 at 9:35 PM, Xan Lopez<x...@gnome.org> wrote:
WebKit is the native layer on top of WebCore offered by each port
for
their platform, so the answer to that is: yes, WebKitGTK provides
GObject APIs which are all "specific" to it.
Right, so another question: does the GObject API contain stuff that
is
not possible in the native layers for other platforms?
At this point in time it's mostly the other way around: there are
still some APIs missing that the other more mature ports have, but we
are closing the gap quickly. Do you have in mind anything specific
though?
Does Webkit-GTK handle parts of GTK+ theming that are not
possible using the Carbon shim approach you are
suggesting?
I'm not sure of what that Carbon shim approach is or how it works,
but
WebKitGTK+ uses the current GTK+ theme for all its rendering,
including web forms, media controls, etc.
If the Carbon shim approach does not take the GTK+ theme / fonts into
account, there is a fair chance that the WebKit "control" will look
kind of out-of-place in a GTK+ application. Especially if it also
involves web form and media controls.
What do you think?
Yeah, it would look out of place theming-wise, but probably also in
other little things/interactions like bindings, copy/paste, etc. I
think it general it makes lots of sense to use WebKitGTK+ if you are
doing a GTK+ app, the library is not that big :)
Thank you both for hashing this out for me. I'll persevere with
getting Webkit-Gtk to build with quartz, then. I'm not sure I agree
that it's "not that big": WebKit.framework clocks in at 78M.
Regards,
John Ralls
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list