I think Marshall has the right idea.  Other wrappers of his concept besides
the ActiveX could be one for MFC - which I could take advantage of.

Daniel A. White


On Mon, Nov 24, 2008 at 12:04 PM, Marshall Greenblatt <
[EMAIL PROTECTED]> wrote:

> The framework that I envision for embedded clients will be very simple and
> focused, with access to only a subset of the functionality provided by
> chromium's WebKit layer (basically mirroring the functionality that the
> ActiveX control will provide).  Ideally, the user will be completely
> insulated from the underlying chromium layer, similar to how the chromium
> layer insulates users from WebKit objects.
>
> When you say "delegate objects," are you referring to the use of interfaces
> as delegates (like RenderViewHostDelegate, for instance), or are you
> thinking of something more in line with how C# (or managed C++) uses
> delegates?  An example of the latter approach would be wrapping each
> callback in its own object type and then overriding the += and -= operators
> of the host class to provide a shortcut for registering and unregistering
> them.
>
>
> 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 chromium-dev@googlegroups.com
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to