Hey Christian, thanks for the instant answer!

Sounds good with the plain API for the gtk port. After a look at the header files and the main.c mentioned I'm not sure how to deal with the different types that are defined there as return values or function arguments.

GObject, WebKitWebView, and all the other G* and WebKit* , can they simply be mapped to e.g. ulong or alike (just like "handles") to deal with them in function calls from an existing external program that has no knowledge of gtk? As you certainly note I'm not a C programmer at all, nor do I know very much about advanced C API design and DLLs, especially in combination with C++ or Objective C and the bridge between classes and plain C.

Of course this way of integration via a callable function library DLL would also require that these functions are exported from some dll that may not yet exist. I assume that there is no wrapper dll yet that just exports the gtk function layer around webkit, say a gtkwebkit.dll. Most developers will just use the libs when they compile their program - which is quite different with me here (just imagine it is like VisualBasic where you have to import functions with their signature from a dll). So I would have to create an otherwise empty wrapper DLL that just exports the gtk functions that gtk wraps around webkit.dll. Right?

Again, thanks for any pointers

Thomas


Christian Dywan schrieb:
Am Wed, 07 Jan 2009 16:40:48 +0100
schrieb Thomas Brodt <thomas.br...@porabo.ch>:

Hi list

as far as I have learned until now, there are several ways to use
Webkit as an embeddable component in Windows applications. Maybe some
wise on this list could help me out with some more answers that I
couldn't find in days googling around.

One way to use Webkit on windows is the COM component which exposes
some COM Interfaces that can be used to drive Webkit (I use Brent
Fulgham's cairo based port without the Apple DLLs). This approach
seems to work quite well as far as may experiments went. However,
this COM solution requires that webkit.dll is registered with the
Windows OS. This may be an issue in managed environments where
restricted users cannot register the DLL after copying it in the
application directory, so COM won't work for them. Or if several
copies of Webkit in different version for different deployed
applications are installed on a system, this may lead to problems,
because only one path can be registered for the COM component.

The alternative - that I would also prefer over a COM wrapper - would
be a DLL with a plain C callable interface. I just can use DLLs with
their exported functions, not compile my program with dll usage. Does
the gtk+ port support an API that can be used that way? I assume I
would get some kind of handle for webview instances that must be
given to each API call.

Hey Thomas,

with regard to the gtk port:

Just have a look at WebKit/gtk/webkit/*.h for API and
WebKitTools/GtkLauncher/main.c for a simple example. The gtk port
relies on plain C interfaces, based on GObject and it is indeed common
to have a folder with a bunch of dynamic link libraries in the same
place as the application, on Win32 that is.

ciao,
    Christian
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev



_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Reply via email to