[chromium-dev] Re: Embedded Browser Control Synopsis
It's a fair amount of work, you have enough time to implement that? I can't tell about whether we'd accept the patches or not. I'd accept the move of printing classes to base though. From what I read, you want a custom interface, so no activex control nor XPCOM? Is this windows-only? M-A 2008/9/20 Marshall Greenblatt [EMAIL PROTECTED]: Hi All, As I've mentioned a few times on this list, I'm developing an embedded browser control based on the test_shell project. Below is a synopsis of the design that I've implemented. If there is interest in seeing this included as part of the chromium code base then I'll make an effort to re-factor it into something that matches chromium's code style requirements and submit it for consideration. If it's close to something that might be interesting then I'd be happy to consider any required changes. Otherwise, I'll keep it a separate project and find a good home for it. Any comments or suggestions are welcome. Regards, Marshall OVERVIEW The interface for the browser control is written in C using standard Windows data types and API functions. All strings are null-terminated and stored in wide character format. I decided on this design to keep the implementation and usage simple, minimize dependencies for the calling application, support i8n, and facilitate utilization from both C and C++. The browser control is hosted in a DLL and exports a single initialization function that accepts two arguments. The first argument is a structure that specifies initialization parameters. These parameters include the URL, arguments to CreateWindowEx(), and an application callback for browser events. The second parameter is a pointer to a thread handle. The chrome event handler, and all browser window procedures, run in a separate thread created by the initialization function. This thread will terminate automatically after all browser windows have been destroyed. EVENTS All notification from the browser to the application is handled via events passed to the application callback function. The application callback function accepts four arguments and returns a true or false value indicating whether it handled the event. The arguments accepted are (a) the handle of the browser window that the event originates from, (b) an arbitrary context pointer that the application can specify during initialization, (c) the event ID and (d) a pointer to the event data structure. All event data structures passed to the callback function are managed by the browser implementation and do not need to be freed by the application. For some events, values can be returned to the browser implementation by means of pointers in the event structure. The GlobalAlloc() function is used with the GPTR flag to allocate data for this purpose, and any data passed back to the browser implementation will be freed after use. Callback events currently supported are: - Window Created. Sent when a new browser window is created. The browser initialization function does not block, and therefore the first browser window handle will also be returned via this event. - Window Message. Every window message received by the browser's window procedure will be passed to the application callback for optional handling. The application could, for instance, intercept a WM_COMMAND message and change the default behavior of the control. - Before Popup. The application can cancel the creation of a popup window. - Before Browse. The application can cancel navigation. Information provided with this event includes the URL, post data and request headers. - Load Start. The browser is about to begin loading a URL. - Load End. The browser has finished loading a URL. - Resource Start. The browser is about to begin loading a resource. The application can provide an alternate data source (in-memory buffer, for instance) or cancel the load. The default behavior of the browser implementation is to load the resource in the same manner as test_shell. - Resource End. The browser has finished loading a resource. - Update Address Bar. Change the address bar to the specified string. This is sent after navigation is committed and before the page has begun loading. - Update Title. Change the title to the specified string. This is sent while the page is loading. - Before Menu. The browser is about to show a context menu. The application can either cancel the menu or show a custom menu in its place. The default behavior of the browser implementation is to show a basic context menu based on the disposition type. - Get Menu Label. Called one time for each item in a default context menu before that menu is displayed. The application can change the text from the English default to something else (a different language, for instance). - Get Print Header Footer. Called after the web view is rendered to the print context but before the page is ended. The application can
[chromium-dev] Re: Embedded Browser Control Synopsis
Hi M-A, On Sat, Sep 20, 2008 at 9:39 AM, Marc-Antoine Ruel [EMAIL PROTECTED]wrote: It's a fair amount of work, you have enough time to implement that? I can't tell about whether we'd accept the patches or not. I'd accept the move of printing classes to base though. I've already implemented the control as described in the synopsis. It's still a complete mess, of course, so I won't bother anyone to look at the sources yet. Most of the capability that I needed was demonstrated in the test_shell project. The patches that I've submitted over the last week provide the additional base functionality that was missing. I borrowed context menus and printing from other parts of the code base, so I still need to factor out those dependencies. Other than that, it's just a matter of design decisions and style ;-). I'll submit any changes that also make sense for test_shell as separate patches for consideration. As far as a time line for cleaning up the whole project and preparing it for submission, I'd say more than weeks and less than months. I'll only bother if there's a middling chance that it would be accepted -- which is why I've submitted the design for consideration. It would definitely help to have the Google style verification tools, so I might wait for those. From what I read, you want a custom interface, so no activex control nor XPCOM? I intentionally avoided using COM-like technologies because I find them cumbersome, annoying and difficult to understand and document properly. Also, using COM interfaces from C should be banned as a form of torture. The lack of COM in the main chromium code base is one of the primary reasons why I chose it as the basis for this project. I've already implemented similar projects based on IWebBrowser2 and I was extremely dissatisfied with the myriad ugly workarounds required. From the custom interface prospective, though, I would suggest that using the Windows messaging system does not qualify as a custom interface any more than defining your own COM classes would. Unless you're suggesting a chromium-based clone of IWebBrowser2? Is this windows-only? The current implementation is Windows-only, but there's no reason why it couldn't be ported to other systems. We would just need to make changes similar to the work currently going on for test_shell (abstract the interface, etc). M-A --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Embedded Browser Control Synopsis
Ok fine, I can't give you any guidance if your changes would be accepted, sorry. That seems interesting though and I'd be interested in adding printing support to test_shell. M-A 2008/9/20 Marshall Greenblatt [EMAIL PROTECTED]: Hi M-A, On Sat, Sep 20, 2008 at 9:39 AM, Marc-Antoine Ruel [EMAIL PROTECTED] wrote: It's a fair amount of work, you have enough time to implement that? I can't tell about whether we'd accept the patches or not. I'd accept the move of printing classes to base though. I've already implemented the control as described in the synopsis. It's still a complete mess, of course, so I won't bother anyone to look at the sources yet. Most of the capability that I needed was demonstrated in the test_shell project. The patches that I've submitted over the last week provide the additional base functionality that was missing. I borrowed context menus and printing from other parts of the code base, so I still need to factor out those dependencies. Other than that, it's just a matter of design decisions and style ;-). I'll submit any changes that also make sense for test_shell as separate patches for consideration. As far as a time line for cleaning up the whole project and preparing it for submission, I'd say more than weeks and less than months. I'll only bother if there's a middling chance that it would be accepted -- which is why I've submitted the design for consideration. It would definitely help to have the Google style verification tools, so I might wait for those. From what I read, you want a custom interface, so no activex control nor XPCOM? I intentionally avoided using COM-like technologies because I find them cumbersome, annoying and difficult to understand and document properly. Also, using COM interfaces from C should be banned as a form of torture. The lack of COM in the main chromium code base is one of the primary reasons why I chose it as the basis for this project. I've already implemented similar projects based on IWebBrowser2 and I was extremely dissatisfied with the myriad ugly workarounds required. From the custom interface prospective, though, I would suggest that using the Windows messaging system does not qualify as a custom interface any more than defining your own COM classes would. Unless you're suggesting a chromium-based clone of IWebBrowser2? Is this windows-only? The current implementation is Windows-only, but there's no reason why it couldn't be ported to other systems. We would just need to make changes similar to the work currently going on for test_shell (abstract the interface, etc). M-A --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Embedded Browser Control Synopsis
Hi M-A, On Sat, Sep 20, 2008 at 1:50 PM, Marc-Antoine Ruel [EMAIL PROTECTED]wrote: Ok fine, I can't give you any guidance if your changes would be accepted, sorry. That seems interesting though and I'd be interested in adding printing support to test_shell. M-A No worries, your questions are exactly the kind of feedback that I'm looking for :-) Thanks, 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Embedded Browser Control Synopsis
On Sep 20, 2:22 pm, Marshall Greenblatt [EMAIL PROTECTED] wrote: Hi M-A, On Sat, Sep 20, 2008 at 1:50 PM, Marc-Antoine Ruel [EMAIL PROTECTED]wrote: Ok fine, I can't give you any guidance if your changes would be accepted, sorry. That seems interesting though and I'd be interested in adding printing support to test_shell. If would be great if our printing system could be separated from the main browser process. It would be much easier to write single-process test shell tests for this functionality. All that would be necessary for integration into the browser would be a proxying layer (I think this is how plugins work now). Brett --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
