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 insert a > custom header/footer string at any of six predefined locations (top left, > top center, top right, bottom left, bottom center, bottom right) or do > custom drawing on the print context. Information provided with this event > includes the current URL, title, page number, total pages, print context, > page bounding box and DPI scale factor. > - Execute JavaScript. A method has been executed on the "window.embed" > object. All JavaScript arguments are provided with this event and the > application can specify a return value or cause a JavaScript "no method > found" error to be generated. > > > COMMANDS > > All commands from the application to the browser control are sent using > SendNotifyMessage() or related functions. Simple commands, such as view > source or print screen, are sent as WM_COMMAND messages. The wParam > argument for the WM_COMMAND message is a combination of both the message > event ID and the event target (main frame or focused frame). > > Commands currently supported via WM_COMMAND messages are: > > - Exit. Destroy the browser application window. > - Back, Forward, Reload and Stop Load. Control navigation of the target > frame. > - Undo, Redo, Cut, Copy, Paste, Delete, Select All. Control selection on > the target frame. > - Print. Print the target frame. > - View Source. Save the target frame's HTML source to a temporary file and > open it in the default text viewing application. > > Commands that require complex arguments, such as load string or create > window, are sent via custom windows messages. All data passed to the > browser control for custom windows messages is allocated using GlobalAlloc() > with the GPTR flag and freed by the browser implementation after use. > > Commands currently supported via custom windows messages are: > > - Load URL. Load the specified URL into an optionally specified target > frame. > - Load String. Load the specified string into the main browser frame with an > optionally specified dummy URL. > - Execute JavaScript. Execute an arbitrary JavaScript command. > - Create Window. Create a new browser window. The application specifies > the URL and arguments to CreateWindowEx(). > > > FUTURE WORK > > The following capabilities still need to be implemented: > > - Provide access to and support manipulation of the DOM structure. > - Design an easy way to dynamically mix application-provided windows with > web content in the browser window. > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to [email protected] 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 -~----------~----~----~----~------~----~------~--~---
