Hi Ben, I appreciate you taking the time to discuss these issues. Hopefully we can come to an arrangement that will work for all of us.
On Sun, Nov 16, 2008 at 10:05 PM, Ben Goodger (Google) <[EMAIL PROTECTED]>wrote: > > I don't think we want to support Chrome UI disembodied from the Chrome > browser. Much of it is designed with a certain amount of cohesion in > mind which wouldn't work in an embedding situation, and represent > functionality which we do not now nor probably ever want to make a > long term commitment to support. I agree with you on this point. I believe the best solution is to add "theme" support to chrome similar to the visual styles support provided by Windows XP. Client applications would then have an interface for the custom drawing of UI elements. It can be reasonably assumed, for instance, that all modern browsers will have window frames, tabs, location bars and status bars. Embedded clients may also choose to take advantage of these capabilities. An interface that supported custom drawing of these controls while maintaining the underlying functionality should be a good thing for everybody. It would allow embedded clients to use the operating system theme by default while allowing chrome to use its own custom theme. I don't see adding support for custom themes in the browser base as being a huge implementation issue. All chrome window frame drawing, for instance, is already handled by a single base class (BrowserFrame) that we then extend for the drawing of XP- and Vista- styled frames. It should be relatively painless to re-factor the chrome browser base to make objects like BrowserFrame more easily extensible by the outside world. The more difficult project might be theming WebKit, but that's an issue independent of the chrome browser core. > At any rate, it's typical of web > frame embedding APIs to defer this functionality to the client. I think most people would agree that IWebBrowser2 represents the de facto standard in embedded browser components. Here is a brief summary of features that IWebBrowser2 supports with little to no custom coding required by the client: - Printing support with print preview - Fully functional context-sensitive right-click menus - Security (zone) access model for loading web content - Client interception and loading of resource streams - DOM access/manipulation - File download management - JS bi-directional communication These are all features that, in chrome, are mostly provided by the browser code base, if at all. In order to support these features in a chromium-based ActiveX control we need to either access the browser implementation or re-implement them from scratch. I think re-implementing them would be the harder option to justify from a support standpoint. As an added bonus, if we provide features in the chrome ActiveX control that go beyond what Microsoft provides -- like support for theming, tabs and a multi-process architecture -- then so much the better for us and our users. > > This concern is solely related to UI. Hopefully the above responses have provided a possible solution for alleviating your UI concerns :-). > This is why I am referring you > to RenderViewHost, which is the lower level object that provides just > the page rendering/event receiving element built on top of the > multi-process architecture, as well as a rich array of delegate > methods that can be implemented by the embedding app to customize > functionality as required. > > What functionality do you require? What kind of app are you building? Please refer to this thread for additional background on what we're trying to achieve: http://groups.google.com/group/chromium-dev/browse_thread/thread/9d6f282f68c77528# > > > -Ben Regards, Marshall > > > On Sun, Nov 16, 2008 at 4:35 PM, Marshall Greenblatt > <[EMAIL PROTECTED]> wrote: > > Hi Ben, > > > > On Sun, Nov 16, 2008 at 6:21 PM, Ben Goodger (Google) <[EMAIL PROTECTED]> > > wrote: > >> > >> Any embedding should _not_ touch the browser code (and changes to this > >> code to support it won't be accepted). WebContents/etc is probably the > >> highest level you want to get. I would probably suggest re-using > >> RenderViewHost. It has the fewest constraints and offers the user most > >> customization. > > > > Thank you for your feedback. It's good to know Google's opinion on this > > important issue. If you review previous emails you'll see that our > intent > > with the ActiveX control is to use existing browser functionality without > > re-implementing it. Perhaps we can agree on a > > re-organization/modularization of the browser code that will allow all of > us > > to satisfy our needs. > > > >> > >> -Ben > > > > Regards, > > Marshall > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
