[chromium-dev] Re: Embedding Chromium
Hi Darin, On Thu, Nov 13, 2008 at 7:14 PM, Darin Fisher [EMAIL PROTECTED] wrote: There is no existing COM-style Chrome component that can be easily embedded for web rendering. -Darin Do you (or Google, or Chromium) have a preference when it comes to COM frameworks? It would be nice to have an ActiveX control eventually accepted as part of the Chromium code base. Would something implemented using pure COM C++ and MIDL have a better chance of acceptance than something implemented using ATL, for instance? 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Embedding Chromium
On Thu, Nov 13, 2008 at 11:42 PM, Darin Fisher [EMAIL PROTECTED] wrote: I'm familiar with straight COM C++ and MIDL and can imagine how that might look, but I don't know enough about the issues with ATL. I've heard some objections to ATL in the past. At any rate, it'd be good to see a more detailed proposal before committing to anything. In general, I think it could be reasonable for the chromium repository to be home to other projects derived from the chromium source. Ok, let's talk about possible designs :-) I think it would be nice to leverage chromium's multi-process architecture in a COM context. The chromium browser process would be hosted in a local COM server executable. Each browser window requested by the container application (and created by the COM server) would be a separate webcore process managed by the browser process, similar to how tabs are handled in Chrome. The COM runtime could transparently handle LRPC marshaling between the container application and the COM browser process, and the browser process could communicate with the webcore process using IPC per the usual methods. If a webcore process crashes then neither the container application nor the browser process is taken down as a result. We could even use the same sad tab graphics (if that's not IP infringement) and allow the webcore process to be reloaded without necessarily requiring intervention from the container application. -Darin 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: not using PLATFORM(GTK)
On Fri, Oct 17, 2008 at 1:58 PM, Adam Treat [EMAIL PROTECTED] wrote: On Thursday 16 October 2008 8:04:19 pm Evan Martin wrote: What we discussed today is the leftover bits: those not covered by CHROMIUM but potentially by GTK (for example, font drawing). What I think we concluded was that any place that would call into GTK would likely need a connection to the X server (for example again, font drawing) and our renderers will not have that access. So it seems we'll be better off not setting PLATFORM(GTK) and instead using a mixture of CHROMIUM and whatever more unix-specific bits we can. (We'll still be linking to GTK for theme drawing.) Some of us were talking about this topic on #chromium-dev earlier and I think we came to the same conclusion. The bits that are in WebCore/platform do not really need GTK API for implementation. For font handling you can even use harfbuzz directly. In fact, I would suggest you don't even need GTK for theme drawing. It seems silly to me to link WebKit with all of GTK for the sole purpose of drawing forms in webpages according to the GTK theme. Moreover, the trend among web developers is to style these controls themselves using CSS. I would suggest that an elegant solution for Chromium on Linux (and perhaps for Chromium altogether on all platforms) is to implement a custom form drawing theme that would directly use WebKit rendering API's. I would have to disagree with the idea of a single chromium theme for forms across all platforms, as I consider it important on most platforms to match the native look and feel. This is especially relevant when you consider how different Windows 2000, Windows XP and Windows Vista look from each other. There's also a limit on what can be accomplished with CSS. One of the most annoying aspects of Microsoft's WebBrowser2 control, for instance, is that it doesn't honor the platform theme, and so you see Windows 2000 style buttons on all platforms (imagine how that looks when all of the other buttons in an application are Vista-themed). And we all know how militant Mac users are about their UI. Just my 2 cents :-) In other words, you could create a RenderThemeCrossPlatform that would use WebCore::GraphicsContext API to manually draw various form controls. In fact, I have a basic start of such a theme and would be happy to share it and continue implementing the rest of the form controls. Cheers, Adam 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 -~--~~~~--~~--~--~---
[chromium-dev] Adding embedded NPAPI plug-in capability
Hi All, The context for this conversation is the chromium-based embedded browser control described in a previous thread: http://groups.google.com/group/chromium-dev/browse_thread/thread/5b23e1a218811b3d I'm exploring the best way to embed a plug-in within the browser control where the plug-in is part of the container application instead of being loaded from a separate DLL. As a simple usage case, consider an application where the user interface is hosted within an embedded browser window, and the application-specific functionality is rendered using a plug-in within that browser window. I see two possible approaches for supporting this capability: A) Write a custom WebPluginDelegate implementation and return an instance from WebViewDelegate::CreatePluginDelegate(). B) Add support for embedded plug-ins to the existing NPAPI framework. My personal preference is B, as we could then make use of the plug-in management capabilities already provided by the NPAPI framework. In order to implement B I propose two changes to NPAPI classes: 1) Add the following method to NPAPI::PluginLib: static PluginLib* CreatePluginLib(const struct InternalPluginInfo ipi); 2) Add the following method to NPAPI::PluginList: void LoadPlugin(const struct InternalPluginInfo ipi); The method in #2 will internally call the method in #1. #2 would be called by the container application on startup to register its custom plug-in type with the system. struct InternalPluginInfo ipi; // populate the ipi structure // register the custom plug-in type with the system NPAPI::PluginList::Singleton()-LoadPlugin(ipi); Since the InternalPluginInfo structure would no longer be strictly internal it may also be appropriate to give it a different name. Does this proposal sound like a reasonable solution to the problem? Is there perhaps a better approach that I'm missing? Any comments or suggestions would be greatly appreciated :-) 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Adding embedded NPAPI plug-in capability
Hi Amanda, On Thu, Oct 16, 2008 at 3:53 PM, Amanda Walker [EMAIL PROTECTED] wrote: On Thu, Oct 16, 2008 at 3:20 PM, Marshall Greenblatt [EMAIL PROTECTED] wrote: I'm exploring the best way to embed a plug-in within the browser control where the plug-in is part of the container application instead of being loaded from a separate DLL. As a simple usage case, consider an application where the user interface is hosted within an embedded browser window, and the application-specific functionality is rendered using a plug-in within that browser window. I see two possible approaches for supporting this capability: A) Write a custom WebPluginDelegate implementation and return an instance from WebViewDelegate::CreatePluginDelegate(). B) Add support for embedded plug-ins to the existing NPAPI framework. My personal preference is B, as we could then make use of the plug-in management capabilities already provided by the NPAPI framework. Hi Marshall, Can you go into some more specifics about the advantages of (b) over (a), as you see them? At least at first glance, this seems like exactly the sort of thing that the WebPluginDelegate would be great for. I originally considered approach (a) until I took a closer look at the implementation in webplugin_delegate_impl.cc. There's some important functionality in webplugin_delegate_impl.cc, including support for windowed vs. windowless plugins, that I would have to duplicate and keep an eye on in my own implementation. It seemed that NPAPI might be a better choice because (1) it's a well-documented and (hopefully) stable API, (2) I wouldn't have to duplicate existing webplugin_delegate_impl.cc capabilities, and (3) I wouldn't have to worry about keeping up with future webplugin_delegate_impl.cc changes. That all being said, I'm amenable to being convinced otherwise :-). --Amanda 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: V8 global context and V8 differences between chromium and gears
Hi Mike,
On Wed, Oct 1, 2008 at 1:02 PM, Mike Belshe [EMAIL PROTECTED] wrote:
Generally, I don't think you should touch the bridge (btw - the bridge is
going away as we reconcile differences w/ webkit- it will be the
scriptController, I believe).
I don't have source in front of me; but there is a file like np_v8_util
or np_v8_object where there are some conversion utilities for converting v8
types to NPObjects. This routine (v8array to NPObject) probably belongs in
there (for v8). I'm fairly clueless about the JSC code. (we used to refer
to JavaScriptCore as KJS; but we now refer to it as JSC since that is the
proper name)
I'd assume that you'd create the NPObject direct from the CppBoundClass by
calling this function. The last problem is making your newly created object
reachable from your JS code; and for that, I think there is a BindTo
call (I believe it is on the bridge), which allows you to hang a custom
property off the window object.
While you described what you are trying to do (make arrays from C++
accessible to JS), I need more context to understand the best way to hook
into the system.Are you augmenting an existing CppBoundObject? Or
creating something new?
Mike
Sorry for not being clear -- I posted about this in a separate message on
the chromium-dev list about a week ago. The overall goal is to add the
following methods to the existing webkit/glue/CppVariant class in the least
intrusive manner possible. The new JS Array NPObject would be created in
the Set() methods and assigned to the NPVariant underlying the CppVariant
instance.
// Methods for assigning vectors of different data types
void Set(const std::vectorstd::wstring value);
void Set(const std::vectorint32_t value);
void Set(const std::vectordouble value);
void Set(const std::vectorbool value);
// Evaluate the elements in the NPObject and determine
// the most appropriate vector data type to use.
enum VectorType {
VECTOR_TYPE_STRING,
VECTOR_TYPE_INT32,
VECTOR_TYPE_DOUBLE,
VECTOR_TYPE_BOOLEAN
};
VectorType GetVectorTypeHint() const;
// Methods for retrieving vectors of different data types
std::vectorstd::wstring ToStringVector() const; // this method already
exists
std::vectorint32_t ToInt32Vector() const;
std::vectordouble ToDoubleVector() const;
std::vectorbool ToBooleanVector() const;
Adding these methods will make it easier to use JS array objects as
arguments and return values for CppBoundClass callback functions.
I see that, as you mentioned, JSBridge will disappear with the pending
chrome_webkit_merge_branch merge. It was supposed to land on trunk
yesterday, but I guess it got postponed? In any case, I'll look around in
chrome_webkit_merge_branch and try to identify the appropriate place to add
the CreateSimpleArrayObject() methods that will do the actual NPObject
creation work.
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
-~--~~~~--~~--~--~---
[chromium-dev] Re: Pass the invoked JavaScript method name as an argument to the fallback callback
Hi Feng, If you wouldn't mind, please give us your opinion on this question. Evan Martin says you might have already responded, but if you did we've somehow managed to misplace it :-(... Thanks, Marshall On Wed, Sep 24, 2008 at 10:45 PM, Marshall Greenblatt [EMAIL PROTECTED] wrote: Hi Evan/Feng, On Wed, Sep 24, 2008 at 10:09 PM, [EMAIL PROTECTED] wrote: I just remembered some of this code might not work. Feng, do you remember changing this code? (It was in May 2008.) http://codereview.chromium.org/3175/diff/7/211 File webkit/glue/cpp_bound_class.cc (right): http://codereview.chromium.org/3175/diff/7/211#newcode157 Line 157: return (methods_.find(ident) != methods_.end() || fallback_callback_.get()); Hmm, I remember this causing problems in some bit of code. I wonder if I could find it... ah, yes. The commit message was (from Feng): The fix [to not test fallback_callback] in cpp_bound_class.cc is a bonus. I talked to evanm that the check in incorrect. It does not work properly with NPObject binding code. Without the proposed change to CppBoundClass::HasMethod() the fallback callback will never actually be called, because HasMethod() must return true before Invoke() will be executed. I did wonder, though, why the comments didn't match the actual code :-). In current sources, the fallback callback is only used in three places: webkit\glue\cpp_binding_example.cc(25): BindFallbackMethod(CppBindingExample::fallbackMethod); webkit\glue\cpp_bound_class_unittest.cc(26): BindFallbackMethod(state ? webkit\tools\test_shell\layout_test_controller.cc(118): BindFallbackMethod(LayoutTestController::fallbackMethod); So, for the chrome browser project, fallback_callback_.get() should always be NULL. Is there something else outside of the chromium repository that we need to be concerned about? http://codereview.chromium.org/3175 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: WebKit merge landing tomorrow afternoon
Hi Eric, Is there a document somewhere that describes the changes that we can expect? Regards, Marshall On Mon, Sep 29, 2008 at 6:00 PM, Eric Seidel [EMAIL PROTECTED] wrote: We plan to land the webkit_merge_branch onto trunk tomorrow afternoon. http://src.chromium.org/svn/branches/chrome_webkit_merge_branch/ We still have a bunch of failures: http://build.chromium.org/buildbot/waterfall/waterfall?builder=Webkit%20(merge)http://build.chromium.org/buildbot/waterfall/waterfall?builder=Webkit%20%28merge%29 but we plan to mark all failing tests as fixable so that the bot will be green, and then work to fix the failing tests once the code is in trunk. We plan to fix all 17 remaining crashing tests between now and when we land on trunk. This means that trunk will be closed for 1-2 hours tomorrow afternoon. This merge has been 9 weeks in the making, it's time for us to finally move it onto trunk and work with the whole team to fix our remaining issues. Thank you for your understanding in this issue. -eric --~--~-~--~~~---~--~~ 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] Correct way to create an NPObject for assignment to CppVariant
Hi All, What is the correct way to create an NPObject for assignment to a CppVariant instance? The CppVariant instance in this case represents the return value from a CppBoundClass callback. For example, is it necessary to create my own static class object, or can I use V8NPObjectClass (or some other class) that already exists? To create an NPObject that represents a JavaScript Array, do I need to do more to the NPObject then setting length and numeric index properties? Thanks in advance for your time. 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 -~--~~~~--~~--~--~---
[chromium-dev] Adding additional vector handling methods to CppVariant
Hi All,
I'd like to add a full compliment of vector handling methods to the
webkit/glue/CppVariant class. The methods I'm proposing are as follows:
// Methods for retrieving vectors of different data types
std::vectorstd::wstring ToStringVector() const; // this method already
exists
std::vectorint32_t ToInt32Vector() const;
std::vectordouble ToDoubleVector() const;
std::vectorboolean ToBooleanVector() const;
// Methods for assigning vectors of different data types
void Set(const std::vectorstd::wstring value);
void Set(const std::vectorstd::int32_t value);
void Set(const std::vectorstd::double value);
void Set(const std::vectorstd::boolean value);
// Method to evaluate the first element in the NPObject and provide a hint
as to
// the most appropriate vector data type to use
enum VectorType {
VECTOR_TYPE_STRING,
VECTOR_TYPE_INT32,
VECTOR_TYPE_DOUBLE,
VECTOR_TYPE_BOOLEAN
};
VectorType GetVectorTypeHint() const;
Does the method naming scheme sound reasonable? Any objections to the type
hint concept? isStringVector(), isInt32Vector(), etc, aren't necessarily
appropriate because the NPObject isn't inherently of any particular vector
type -- we're just converting on the fly to the requested type.
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
-~--~~~~--~~--~--~---
[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
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: Accessing the invoked method name from the JavaScript callback
Hi Evan, On Fri, Sep 19, 2008 at 2:13 PM, Evan Martin [EMAIL PROTECTED] wrote: I believe within a given execution context it's synchronous, but for cleanliness anyway I'd prefer 2 or 3. 2 sounds more sane to me; the only reason we have a fallback callback (I believe) is for one test. I'd be happy to review such a patch. The patch for #2 is here: http://codereview.chromium.org/3175 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Retrieving pending request data before the request is submitted
Hi Brett, The below patch adds GetHttpHeaders(), HasRequestPostData() and GetRequestPostData() methods to the WebRequest class. http://www.magpcss.net/patches/chromium_weburlrequest_newfields_rev2228.diff Are you the right person to review this, or is there someone else I should contact? 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 -~--~~~~--~~--~--~---
