Another place you could look for API ideas is the Qt port of WebKit.
http://doc.trolltech.com/main-snapshot/qtwebkit.html
QtWebKit has been always designed to fit into other applications and
not about working for one application. The API is the same across all
platforms and specifically it makes it easy to embedded on any surface
and in a Qt app. It makes building applications like wkhtmltopdf very
easy. Any API that is made should be good enough for Chrome to use
and work on every platform.
As it is today there is a very large amount of setup work that any
third party has to do if they want to embed chromium. A good start
would be attempting to trim down what is required by the test shell.
Moving the dozen or so static functions from glue into a class and
providing default implementations that can be overloaded by the client
if they want, the cache should default to something restrictive, ico
data tables shouldn't need to be explicitly initialized etc. The
larger the amount of code that any client is required to do the harder
it will be to change and the more likely that they will get broken
over time.
-Benjamin Meyer
On Mon, Nov 24, 2008 at 11:06 AM, Amanda Walker <[EMAIL PROTECTED]> wrote:
>
> Putting together a document is great.
>
> While you are working on it, you should take a look at the WebKit
> documentation as a reference point if you're not already; while the
> WebKit embedding method for Windows isn't as rich as NSWebView in
> Cocoa, reading up on both will give you a good idea of the types of
> embedding and extension that the WebKit and Chromium code bases are
> already designed for
>
> As one example, they both make extensive use of "delegate" objects
> instead of individual functions as callbacks--while this isn't a
> common idiom in Windows, it does have some advantages if you're not
> trying to create a drop-in replacement for Microsoft's WebBrowser
> control.
>
> --Amanda
>
> On Mon, Nov 24, 2008 at 10:51 AM, Marshall Greenblatt
> <[EMAIL PROTECTED]> wrote:
>> The ActiveX control that I'm developing for Windows isn't portable, but the
>> underlying chrome-based functionality (like test_shell, for instance) is
>> quite generic. It would be rather easy to break the ActiveX project into
>> two separate components -- one that provides the underlying chrome-based
>> implementation as a simple, streamlined, C++ framework and the other that
>> adds an ActiveX wrapper on top if it. The framework would provide standard
>> implementations for the browser window, message loop and default
>> functionality (printing, context menus, resource loading, etc), allowing us
>> to offer similar functionality and semantics on different platforms and
>> technologies (ActiveX, ObjC, wxWidgets, etc). The embedded client could
>> then customize the default functionality and handle events by registering
>> callback interfaces. For instance, creating a fully functional embedded
>> chrome window using this framework might be as easy as the following:
>>
>> // Create the new browser window object
>> ChromeBrowerWindow *pWnd = new ChromeBrowerWindow();
>>
>> // Register our custom handler if we're interested in intercepting browser
>> events
>> // MyBrowserHandler implements the ChromeBrowserHandler interface
>> MyBrowserHandler handler;
>> pWnd->RegisterHandler(&handler);
>>
>> // Create the browser window parented to |parentWindow| and drawn at the
>> specified location
>> pWnd->Create(parentWindow, xpos, ypos, width, height, flags);
>>
>> // Navigate to a URL
>> pWnd->LoadURL("http://www.google.com";);
>>
>> I'll put together a document describing what I think the framework should
>> look like.
>>
>>
>> On Mon, Nov 24, 2008 at 9:16 AM, Mike Pinkerton <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> On Mac we definitely want an objective-C wrapper around our framework.
>>> That's what WebKit provides, and what all our consumers would
>>> expect/demand.
>>>
>>> On Sun, Nov 23, 2008 at 7:05 AM, Avi Drissman <[EMAIL PROTECTED]> wrote:
>>> > I've experienced CFPlugins, and I've never figured out why they use a
>>> > COM-like system there. It adds a ton of complexity for no real benefit.
>>> >
>>> > I can't speak for other platforms, but using COM on the Mac is not
>>> > needed
>>> > when you have ObjC and its introspection capabilities. I don't see why a
>>> > framework wouldn't do.
>>> >
>>> > Avi
>>> >
>>> > On Sat, Nov 22, 2008 at 11:40 PM, Marshall Greenblatt
>>> > <[EMAIL PROTECTED]> wrote:
>>> >>
>>> >> Hi All,
>>> >>
>>> >> As many of you probably know there's been talk of developing a
>>> >> chrome-based ActiveX (COM) control for Windows. But what about other
>>> >> platforms?
>>> >>
>>> >> For OSX, Apple offers a COM-like framework called "Core Foundation
>>> >> Plug-ins":
>>> >>
>>> >>
>>> >> http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFPlugIns/CFPlugIns.html
>>> >>
>>> >> For linux, there's quite a collection of COM/CORBA-like
>>> >> implementations:
>>> >> http://linas.org/linux/corba.html
>>> >>
>>> >> Or, getting away from COM, we have frameworks such as Qt, gtk+,
>>> >> wxWidgets,
>>> >> etc. What framework would you find the most useful for embedding a
>>> >> browser
>>> >> control in your development project(s) on the linux and/or osx
>>> >> platforms?
>>> >>
>>> >> - Marshall
>>> >>
>>> >>
>>> >>
>>> >>
>>> >
>>> >
>>> > >
>>> >
>>>
>>>
>>>
>>> --
>>> Mike Pinkerton
>>> Mac Weenie
>>> [EMAIL PROTECTED]
>>>
>>>
>>
>>
>> >
>>
>
>
>
> --
> --Amanda
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Chromium-dev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/chromium-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
