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
-~----------~----~----~----~------~----~------~--~---
