Also, I do not know if it is possible, but it would be worth while to see if
we can hook into V8 from the browser model and add our own functions.

Daniel A. White


On Mon, Nov 24, 2008 at 12:06 PM, Daniel A. White
<[EMAIL PROTECTED]>wrote:

> 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