[chromium-dev] Re: Quick and dirty chrome embedding test

[Marshall Greenblatt]

Hi Brett,

On Tue, Nov 18, 2008 at 2:27 PM, Brett Wilson <[EMAIL PROTECTED]> wrote:

>
> On Tue, Nov 18, 2008 at 11:19 AM, Marshall Greenblatt
> <[EMAIL PROTECTED]> wrote:
>

> > Thanks for your input, I think I understand now.  Both the Windows
> message
> > loop and the chrome task queue co-exist in the MessageLoop class via
> > Delegate and Dispatcher implementations.  Chrome uses the Windows message
> > loop as a means for managing the task queue (via WM_TIMER calls), so
> there
> > should be no need for me to post Windows messages directly to the UI
> > thread.  Instead, to call a Browser object method (like GoBack()) from a
> > separate thread I should execute MessageLoopForUI::current()->PostTask()
> > (which is itself thread-safe) to have the UI thread execute a method that
> I
> > provide, which would in turn make the Browser method call.
>
> Kind of. MessageLoopForUI doesn't give ui the UI message loop. It
> gives you the current message loop assuming that it's a UI "type" of
> loop. You'll have to track independently which message loop the UI
> message loop is. We usually pass this information into the objects
> that live on the secondary threads when they start.


Am I correct in thinking that there's only one UI message loop per process
(created in BrowserMain())?  If so, I'd be curious to know why a pointer to
the UI message loop isn't available from the global BrowserProcess instance.


>
>
> Brett


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: Quick and dirty chrome embedding test

[Brett Wilson]

On Tue, Nov 18, 2008 at 11:59 AM, Marshall Greenblatt
<[EMAIL PROTECTED]> wrote:
> Hi Brett,
>
> On Tue, Nov 18, 2008 at 2:27 PM, Brett Wilson <[EMAIL PROTECTED]> wrote:
>>
>> On Tue, Nov 18, 2008 at 11:19 AM, Marshall Greenblatt
>> <[EMAIL PROTECTED]> wrote:
>>
>> > Thanks for your input, I think I understand now.  Both the Windows
>> > message
>> > loop and the chrome task queue co-exist in the MessageLoop class via
>> > Delegate and Dispatcher implementations.  Chrome uses the Windows
>> > message
>> > loop as a means for managing the task queue (via WM_TIMER calls), so
>> > there
>> > should be no need for me to post Windows messages directly to the UI
>> > thread.  Instead, to call a Browser object method (like GoBack()) from a
>> > separate thread I should execute MessageLoopForUI::current()->PostTask()
>> > (which is itself thread-safe) to have the UI thread execute a method
>> > that I
>> > provide, which would in turn make the Browser method call.
>>
>> Kind of. MessageLoopForUI doesn't give ui the UI message loop. It
>> gives you the current message loop assuming that it's a UI "type" of
>> loop. You'll have to track independently which message loop the UI
>> message loop is. We usually pass this information into the objects
>> that live on the secondary threads when they start.
>
> Am I correct in thinking that there's only one UI message loop per process
> (created in BrowserMain())?  If so, I'd be curious to know why a pointer to
> the UI message loop isn't available from the global BrowserProcess instance.

The BrowserProcess object is not threadsafe and can only be used on
the UI thread. The UI thread could be stored, but it's worked fine to
pass it when we need it.

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

[chromium-dev] Re: Quick and dirty chrome embedding test

[Brett Wilson]

On Tue, Nov 18, 2008 at 11:19 AM, Marshall Greenblatt
<[EMAIL PROTECTED]> wrote:
> Hi Brett,
>
> On Tue, Nov 18, 2008 at 11:12 AM, Brett Wilson <[EMAIL PROTECTED]> wrote:
>>
>> On Tue, Nov 18, 2008 at 7:14 AM, Marshall Greenblatt
>> <[EMAIL PROTECTED]> wrote:
>> > Hi Brett,
>> >
>> > On Tue, Nov 18, 2008 at 9:56 AM, Brett Wilson <[EMAIL PROTECTED]>
>> > wrote:
>> >>
>> >> On Tue, Nov 18, 2008 at 6:50 AM, Marshall Greenblatt
>> >> <[EMAIL PROTECTED]> wrote:
>> >> > Hi All,
>> >> >
>> >> > Is it safe to create (via Browser::Create*()) and/or access Browser
>> >> > object
>> >> > instances from multiple threads?  In other words, I need to choose
>> >> > one
>> >> > of
>> >> > the following options:
>> >>
>> >> No, the entire UI of Chrome is single-threaded and is not threadsafe.
>> >> If you need things to access it from multiple threads, you will need
>> >> to synchronize everything.
>> >
>> > Is there a thread-safe method equivalent to the PostMessage() WinAPI
>> > call
>> > for adding events to the browser MessageLoop?
>>
>> PostMessage should already be thread safe.
>
> Thanks for your input, I think I understand now.  Both the Windows message
> loop and the chrome task queue co-exist in the MessageLoop class via
> Delegate and Dispatcher implementations.  Chrome uses the Windows message
> loop as a means for managing the task queue (via WM_TIMER calls), so there
> should be no need for me to post Windows messages directly to the UI
> thread.  Instead, to call a Browser object method (like GoBack()) from a
> separate thread I should execute MessageLoopForUI::current()->PostTask()
> (which is itself thread-safe) to have the UI thread execute a method that I
> provide, which would in turn make the Browser method call.

Kind of. MessageLoopForUI doesn't give ui the UI message loop. It
gives you the current message loop assuming that it's a UI "type" of
loop. You'll have to track independently which message loop the UI
message loop is. We usually pass this information into the objects
that live on the secondary threads when they start.

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

[chromium-dev] Re: Quick and dirty chrome embedding test

[Marshall Greenblatt]

Hi Ben,

On Tue, Nov 18, 2008 at 1:37 PM, Ben Goodger (Google) <[EMAIL PROTECTED]>wrote:

>
> Why are you creating a Browser object? What does that have to do with
> embedding?
>
> -Ben


Please review the reference implementation for a better understanding of how
I'm currently using Browser objects:

http://codereview.chromium.org/10973


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: Quick and dirty chrome embedding test

[Marshall Greenblatt]

Hi Brett,

On Tue, Nov 18, 2008 at 11:12 AM, Brett Wilson <[EMAIL PROTECTED]> wrote:

>
> On Tue, Nov 18, 2008 at 7:14 AM, Marshall Greenblatt
> <[EMAIL PROTECTED]> wrote:
> > Hi Brett,
> >
> > On Tue, Nov 18, 2008 at 9:56 AM, Brett Wilson <[EMAIL PROTECTED]>
> wrote:
> >>
> >> On Tue, Nov 18, 2008 at 6:50 AM, Marshall Greenblatt
> >> <[EMAIL PROTECTED]> wrote:
> >> > Hi All,
> >> >
> >> > Is it safe to create (via Browser::Create*()) and/or access Browser
> >> > object
> >> > instances from multiple threads?  In other words, I need to choose one
> >> > of
> >> > the following options:
> >>
> >> No, the entire UI of Chrome is single-threaded and is not threadsafe.
> >> If you need things to access it from multiple threads, you will need
> >> to synchronize everything.
> >
> > Is there a thread-safe method equivalent to the PostMessage() WinAPI call
> > for adding events to the browser MessageLoop?
>
> PostMessage should already be thread safe.


Thanks for your input, I think I understand now.  Both the Windows message
loop and the chrome task queue co-exist in the MessageLoop class via
Delegate and Dispatcher implementations.  Chrome uses the Windows message
loop as a means for managing the task queue (via WM_TIMER calls), so there
should be no need for me to post Windows messages directly to the UI
thread.  Instead, to call a Browser object method (like GoBack()) from a
separate thread I should execute MessageLoopForUI::current()->PostTask()
(which is itself thread-safe) to have the UI thread execute a method that I
provide, which would in turn make the Browser method call.

I also found this document helpful in understanding the message system:
http://dev.chromium.org/developers/design-documents/threading


>
>
> Brett


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: Quick and dirty chrome embedding test

[Ben Goodger (Google)]

Why are you creating a Browser object? What does that have to do with embedding?

-Ben

On Tue, Nov 18, 2008 at 6:50 AM, Marshall Greenblatt
<[EMAIL PROTECTED]> wrote:
> Hi All,
>
> Is it safe to create (via Browser::Create*()) and/or access Browser object
> instances from multiple threads?  In other words, I need to choose one of
> the following options:
>
> A) Synchronize all Browser object creation and access via the main process
> thread ("single thread model" in COM parlance)
> B) Allow each Browser object to be created and managed by its own separate
> thread ("single-threaded apartment model" in COM parlance), or
> C) Allow any thread to create and/or access any Browser object at any time
> ("multi-threaded apartment model" in COM parlance)
>
> For background information on COM threading models see these documents:
> http://msdn.microsoft.com/en-us/library/ms809971.aspx
> http://msdn.microsoft.com/en-us/library/9t07f8b4(VS.80).aspx
>
> 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: Quick and dirty chrome embedding test

[Brett Wilson]

On Tue, Nov 18, 2008 at 7:14 AM, Marshall Greenblatt
<[EMAIL PROTECTED]> wrote:
> Hi Brett,
>
> On Tue, Nov 18, 2008 at 9:56 AM, Brett Wilson <[EMAIL PROTECTED]> wrote:
>>
>> On Tue, Nov 18, 2008 at 6:50 AM, Marshall Greenblatt
>> <[EMAIL PROTECTED]> wrote:
>> > Hi All,
>> >
>> > Is it safe to create (via Browser::Create*()) and/or access Browser
>> > object
>> > instances from multiple threads?  In other words, I need to choose one
>> > of
>> > the following options:
>>
>> No, the entire UI of Chrome is single-threaded and is not threadsafe.
>> If you need things to access it from multiple threads, you will need
>> to synchronize everything.
>
> Is there a thread-safe method equivalent to the PostMessage() WinAPI call
> for adding events to the browser MessageLoop?

PostMessage should already be thread safe.

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

[chromium-dev] Re: Quick and dirty chrome embedding test

[Marshall Greenblatt]

Hi Brett,

On Tue, Nov 18, 2008 at 9:56 AM, Brett Wilson <[EMAIL PROTECTED]> wrote:

>
> On Tue, Nov 18, 2008 at 6:50 AM, Marshall Greenblatt
> <[EMAIL PROTECTED]> wrote:
> > Hi All,
> >
> > Is it safe to create (via Browser::Create*()) and/or access Browser
> object
> > instances from multiple threads?  In other words, I need to choose one of
> > the following options:
>
> No, the entire UI of Chrome is single-threaded and is not threadsafe.
> If you need things to access it from multiple threads, you will need
> to synchronize everything.


Is there a thread-safe method equivalent to the PostMessage() WinAPI call
for adding events to the browser MessageLoop?


>
>
> Brett


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: Quick and dirty chrome embedding test

[Brett Wilson]

On Tue, Nov 18, 2008 at 6:50 AM, Marshall Greenblatt
<[EMAIL PROTECTED]> wrote:
> Hi All,
>
> Is it safe to create (via Browser::Create*()) and/or access Browser object
> instances from multiple threads?  In other words, I need to choose one of
> the following options:

No, the entire UI of Chrome is single-threaded and is not threadsafe.
If you need things to access it from multiple threads, you will need
to synchronize everything.

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

[chromium-dev] Re: Quick and dirty chrome embedding test

[Marshall Greenblatt]

Hi All,

Is it safe to create (via Browser::Create*()) and/or access Browser object
instances from multiple threads?  In other words, I need to choose one of
the following options:

A) Synchronize all Browser object creation and access via the main process
thread ("single thread model" in COM parlance)
B) Allow each Browser object to be created and managed by its own separate
thread ("single-threaded apartment model" in COM parlance), or
C) Allow any thread to create and/or access any Browser object at any time
("multi-threaded apartment model" in COM parlance)

For background information on COM threading models see these documents:
http://msdn.microsoft.com/en-us/library/ms809971.aspx
http://msdn.microsoft.com/en-us/library/9t07f8b4(VS.80).aspx

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: Quick and dirty chrome embedding test

[Marshall Greenblatt]

Hi M-A,

On Mon, Nov 17, 2008 at 3:04 PM, Marc-Antoine Ruel <[EMAIL PROTECTED]>wrote:

>
> To add to Amanda's email (I wrote it at the same time)
>
> You seem overly cautious of saying that you don't want to creating
> anything that would compete with Chromium or Google Chrome. Keep in
> mind that we actually don't really care. Otherwise, the sources
> wouldn't be under BSD license.


I'm glad to see that this isn't an issue.  I would hate for you, or anyone
else, to choose not to support my efforts simply because you misunderstood
my intentions.  I've gotten a lot good feedback from you in the past, and
I'm hoping for a lot more in the future as well :-).


>
>
> Be warned that as in most open source projects, a lot of people talk
> and not many contribute. Don't be too optimistic on third party
> effort. I mean, if you want something to be done, you're better to
> schedule as if you would completely write and maintain it.


Point well taken.


>
>
> You can use the world-writable wiki
> http://code.google.com/p/chromium/w/list to store documents.


Thank you, I'll look into this.


>
>
> Your design will depend on what you actually want to leverage: the
> rendering engine, the multiprocess&sandbox, the basic ui support? At
> first you had talked about using the test_shell shim code to implement
> something that just works. I think it's a feasible idea but this is
> better to just implement RenderViewHost.


This time around I'm starting with the approach of "include everything" and
then I'll remove the things that aren't actually needed.  Even if it ends up
eventually being thrown away, it gives me (and hopefully others) a better
understanding of browser internals.  As a side note, I would not have
attempted this project without first implementing the test_shell-based
approach, as it provided necessary background knowledge.


>
> For instance, out-of-process control execution comes "free" from
> ActiveX so if you just want to host the browser out of process, you
> actually don't need to do anything to achieve that. You just need to
> have your interfaces have the attribute oleautomation and the default
> marshaler will take care of the plumbing. I don't know how much
> experience you have on out of process COM but it's quite easy.


As you say, it's quite possible that the IPC-based multi-process component
will be redundant.  I'll definitely keep my eyes open for a convenient way
to discard it during my continued experimentation.



>
>
> Then, if what you want is mostly the rendering engine, simply creating
> an "activex port" of webkit would probably do the thing. I'm actually
> surprised nobody did that yet. You could probably borrow as much as
> you need from the chromium port.
>
> Then if you want the UI, bookmark&download management (I still wonder
> why), etc, then it makes sense to reuse the browser.lib.


Bookmark management isn't something I, personally, would want for an
embedded client.  That will likely be another thing to go by the wayside.


>
>
> M-A


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: Quick and dirty chrome embedding test

[Marshall Greenblatt]

Hi Amanda,

On Mon, Nov 17, 2008 at 3:01 PM, Amanda Walker <[EMAIL PROTECTED]> wrote:

>
> > As has been mentioned by others, I could more easily fork chrome and
> develop
> > whatever I choose.  However, I prefer an approach that will allow me to
> > contribute my changes back to the chrome project as a whole.  I've
> > demonstrated this preference with a number of changes, admittedly small,
> > that I've implemented in the past.  I have no expectation that new
> changes I
> > make will be accepted.  I'm positive, however, that they won't be
> accepted
> > if I don't first make the effort to discuss them with the chromium
> > development team.  That is why, up to this point, the discussion has been
> > primarily abstract -- issues this important should not be decided by one
> > individual, especially when that individual (myself) is not intimately
> > familiar with the design choices behind current chromium internals.
>
> While I understand that perspective, I also have to say that with this
> team, an individual saying "I think we should do X via method Y, and
> here's a working proof of concept" get much farther, much faster than
> "how should we do X?"  Even if the first prototype gets thrown away, a
> concrete proof of concept always helps to scope the problem, identify
> unexpected complications or side issues, etc.


I agree with you, and that was why I was a bit surprised by the initial slew
of negative responses.  I'm currently in the process of turning the example
that started this thread into a COM implementation, which I'll then post for
additional feedback.  After that, I'll begin pulling things out of browser
core and see how it goes...


>
>
> > I'm not asking chromium or Google to commit development resources to this
> > project.  I'm simply seeking ideas and feedback on how we can make our
> > changes in a way that would beneficial to the chromium project as a
> whole.
> > Most of the feedback so far have been along the lines of "use
> > RenderViewHost." Unfortunately, this advice is incompatible with what
> we're
> > trying to achieve (again, see parent thread).
>
> Well, it (or the analogous code in test_shell) does seem to be the
> closest to IWebBrowser2, and would be a great place to start, since
> it's in effect chromium's internal embedding interface.  I suspect
> that's why people have been pointing you in that direction.


I have already implemented a working embedded client based on test_shell,
with much assistance from developers on this list. More information on that
client is available in this thread:

http://groups.google.com/group/chromium-dev/browse_thread/thread/5b23e1a218811b3d

That's where I first ran into the core browser bundling problem.  Since then
I've been pondering how to provide additional functionality without
re-implementing, and that's what led to this discussion.  Changing the
interface to be COM-based seemed like a natural next step as well.


>
>
> > This is exactly why I'm seeking input at this point in the development
> > process.  Again, we need to know about the far-reaching implementation
> > concerns before we go out and write code.
>
> Fair enough--on the other hand, some of those concerns will be quite
> invisible until someone goes out and writes a proof of concept.  It's
> a balancing act.
>
> > Just as an example, I've seen nothing to indicate that I can get (a)
> > multi-process architecture support, (b) printing support or (c) context
> > menus without either accessing the browser base or re-implementing them.
>
> It seems to me that you could get all of those with RenderViewHost,
> though you might have to crib a bit.  You certainly wouldn't need the
> whole browser module, though.
>
> > This is a very good idea.  Can I add content under
> > http://sites.google.com/a/chromium.org/dev/developers/design-documents,
> or
> > should I look elsewhere?
>
> Hmm, that's a good question.  I don't know, off hand, but I'll see if
> I can find out.
>
> --Amanda


Again, thank you for taking the time to respond to my questions.

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: Quick and dirty chrome embedding test

[Marc-Antoine Ruel]

To add to Amanda's email (I wrote it at the same time)

You seem overly cautious of saying that you don't want to creating
anything that would compete with Chromium or Google Chrome. Keep in
mind that we actually don't really care. Otherwise, the sources
wouldn't be under BSD license.

Be warned that as in most open source projects, a lot of people talk
and not many contribute. Don't be too optimistic on third party
effort. I mean, if you want something to be done, you're better to
schedule as if you would completely write and maintain it.

You can use the world-writable wiki
http://code.google.com/p/chromium/w/list to store documents.

Your design will depend on what you actually want to leverage: the
rendering engine, the multiprocess&sandbox, the basic ui support? At
first you had talked about using the test_shell shim code to implement
something that just works. I think it's a feasible idea but this is
better to just implement RenderViewHost.

For instance, out-of-process control execution comes "free" from
ActiveX so if you just want to host the browser out of process, you
actually don't need to do anything to achieve that. You just need to
have your interfaces have the attribute oleautomation and the default
marshaler will take care of the plumbing. I don't know how much
experience you have on out of process COM but it's quite easy.

Then, if what you want is mostly the rendering engine, simply creating
an "activex port" of webkit would probably do the thing. I'm actually
surprised nobody did that yet. You could probably borrow as much as
you need from the chromium port.

Then if you want the UI, bookmark&download management (I still wonder
why), etc, then it makes sense to reuse the browser.lib.

M-A

On Mon, Nov 17, 2008 at 3:01 PM, Amanda Walker <[EMAIL PROTECTED]> wrote:
>
> On Mon, Nov 17, 2008 at 1:48 PM, Marshall Greenblatt
> <[EMAIL PROTECTED]> wrote:
>> It's clear from core developer comments, I think, that providing an ActiveX
>> control is not a priority for the core chromium or Google development
>> teams.  I've gotten the strong impression that if someone doesn't take
>> advocacy ownership of this issue it will continue to go nowhere -- perhaps
>> it's a false impression.
>
> I think it's an incomplete impression.  Right now, the core Google
> team is focused on getting the Windows version out of beta and getting
> the Mac and Linux versions into beta.  Anything else is going to be
> low priority for a while, but this doesn't mean that that's always
> going to be true.  This isn't the first time embedding has come up,
> and we're quite sincere when we ask some of these questions about
> requirements--if you're trying to embed chromium in your app, you have
> a much clearer picture of what you need than we do :-).  While at
> least for the very near term, most of our cycles are on bug fixing and
> additional platforms, it doesn't mean we're not quite interested in
> what people have to say, or what people implement.
>
>>  I've volunteered myself for the advocacy job
>> (which I would be happy to give up if someone else would like it), and I've
>> taken steps to begin code-based exploration.  My interest here is solely a
>> working browser control based on chrome that satisfies a finite set of
>> design goals (see parent thread).  I'm not seeking to write a web browser,
>> as has been suggested, no is my intent to release a product that competes
>> with chrome.
>
> That's great, and we'd all be very interested to see what those
> explorations produce.  One thing that many of us are wary of, from
> prior experience, is design-by-committee, especially when the
> designers aren't also the implementors.  A working demo will capture
> much more interest than theoretical discussion will, I suspect.
>
>> As has been mentioned by others, I could more easily fork chrome and develop
>> whatever I choose.  However, I prefer an approach that will allow me to
>> contribute my changes back to the chrome project as a whole.  I've
>> demonstrated this preference with a number of changes, admittedly small,
>> that I've implemented in the past.  I have no expectation that new changes I
>> make will be accepted.  I'm positive, however, that they won't be accepted
>> if I don't first make the effort to discuss them with the chromium
>> development team.  That is why, up to this point, the discussion has been
>> primarily abstract -- issues this important should not be decided by one
>> individual, especially when that individual (myself) is not intimately
>> familiar with the design choices behind current chromium internals.
>
> While I understand that perspective, I also have to say that with this
> team, an individual saying "I think we should do X via method Y, and
> here's a working proof of concept" get much farther, much faster than
> "how should we do X?"  Even if the first prototype gets thrown away, a
> concrete proof of concept always helps to scope the problem, identify
> unexpected complications 

[chromium-dev] Re: Quick and dirty chrome embedding test

[Amanda Walker]

On Mon, Nov 17, 2008 at 1:48 PM, Marshall Greenblatt
<[EMAIL PROTECTED]> wrote:
> It's clear from core developer comments, I think, that providing an ActiveX
> control is not a priority for the core chromium or Google development
> teams.  I've gotten the strong impression that if someone doesn't take
> advocacy ownership of this issue it will continue to go nowhere -- perhaps
> it's a false impression.

I think it's an incomplete impression.  Right now, the core Google
team is focused on getting the Windows version out of beta and getting
the Mac and Linux versions into beta.  Anything else is going to be
low priority for a while, but this doesn't mean that that's always
going to be true.  This isn't the first time embedding has come up,
and we're quite sincere when we ask some of these questions about
requirements--if you're trying to embed chromium in your app, you have
a much clearer picture of what you need than we do :-).  While at
least for the very near term, most of our cycles are on bug fixing and
additional platforms, it doesn't mean we're not quite interested in
what people have to say, or what people implement.

>  I've volunteered myself for the advocacy job
> (which I would be happy to give up if someone else would like it), and I've
> taken steps to begin code-based exploration.  My interest here is solely a
> working browser control based on chrome that satisfies a finite set of
> design goals (see parent thread).  I'm not seeking to write a web browser,
> as has been suggested, no is my intent to release a product that competes
> with chrome.

That's great, and we'd all be very interested to see what those
explorations produce.  One thing that many of us are wary of, from
prior experience, is design-by-committee, especially when the
designers aren't also the implementors.  A working demo will capture
much more interest than theoretical discussion will, I suspect.

> As has been mentioned by others, I could more easily fork chrome and develop
> whatever I choose.  However, I prefer an approach that will allow me to
> contribute my changes back to the chrome project as a whole.  I've
> demonstrated this preference with a number of changes, admittedly small,
> that I've implemented in the past.  I have no expectation that new changes I
> make will be accepted.  I'm positive, however, that they won't be accepted
> if I don't first make the effort to discuss them with the chromium
> development team.  That is why, up to this point, the discussion has been
> primarily abstract -- issues this important should not be decided by one
> individual, especially when that individual (myself) is not intimately
> familiar with the design choices behind current chromium internals.

While I understand that perspective, I also have to say that with this
team, an individual saying "I think we should do X via method Y, and
here's a working proof of concept" get much farther, much faster than
"how should we do X?"  Even if the first prototype gets thrown away, a
concrete proof of concept always helps to scope the problem, identify
unexpected complications or side issues, etc.

> I'm not asking chromium or Google to commit development resources to this
> project.  I'm simply seeking ideas and feedback on how we can make our
> changes in a way that would beneficial to the chromium project as a whole.
> Most of the feedback so far have been along the lines of "use
> RenderViewHost." Unfortunately, this advice is incompatible with what we're
> trying to achieve (again, see parent thread).

Well, it (or the analogous code in test_shell) does seem to be the
closest to IWebBrowser2, and would be a great place to start, since
it's in effect chromium's internal embedding interface.  I suspect
that's why people have been pointing you in that direction.

> This is exactly why I'm seeking input at this point in the development
> process.  Again, we need to know about the far-reaching implementation
> concerns before we go out and write code.

Fair enough--on the other hand, some of those concerns will be quite
invisible until someone goes out and writes a proof of concept.  It's
a balancing act.

> Just as an example, I've seen nothing to indicate that I can get (a)
> multi-process architecture support, (b) printing support or (c) context
> menus without either accessing the browser base or re-implementing them.

It seems to me that you could get all of those with RenderViewHost,
though you might have to crib a bit.  You certainly wouldn't need the
whole browser module, though.

> This is a very good idea.  Can I add content under
> http://sites.google.com/a/chromium.org/dev/developers/design-documents, or
> should I look elsewhere?

Hmm, that's a good question.  I don't know, off hand, but I'll see if
I can find out.

--Amanda

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Chromium-dev" group.
To post to this group, send email to chromiu

[chromium-dev] Re: Quick and dirty chrome embedding test

[Marshall Greenblatt]

Hi Amanda,

On Mon, Nov 17, 2008 at 10:48 AM, Amanda Walker <[EMAIL PROTECTED]> wrote:

>
> On Mon, Nov 17, 2008 at 10:19 AM, Marshall Greenblatt
> <[EMAIL PROTECTED]> wrote:
> > Hi M-A,
> >
> > We all know that development issues can become emotional for those
> closely
> > involved with them.  Lets all please make an extra effort not to assume
> the
> > worst about other people's intentions or meanings.
>
> I don't think anyone is doing that--we're just trying to figure out
> what you're trying to do.


I'm happy to hear that :-).  As a resident on multiple message lists I live
in constant fear of flame wars, which tend to be the antithesis of
productive conversation.


> You keep talking in the abstract, so it's a
> little hard to follow.


>
> > The intent with these comments is to address Ben's stated concerns about
> > whether the current chrome UI look/feel would be appropriate for an
> embedded
> > context.  Everyone so far has agreed that it would not.  Most people
> wishing
> > to utilize the chrome code base have no desire to develop a competing
> > product.  We simply wish to utilize existing chrome capabilities in our
> > applications without re-implementing them.
>
> Hmm.  "Everyone," "most people," "we," ... so, are you representing a
> development team?  That hasn't been clear to me--I've been assuming
> you've been speaking for yourself.


>
> What we've had so far (at least on chromium-dev) are a bunch of people
> asking "so, how could I embed chromium in my application?", along with
> a variety of suggestions about how to do it (both short-term, using
> test_shell as a basis, and long-term, where ideas like COM servers
> have come up).  This is all good discussion.


I'm glad that you asked this question.  At the moment I'm speaking primarily
for myself, but also for other people who have shared with me their ideas
and desires for an embedded ActiveX control based on chrome. I've counted 5
so far, but I'll leave it to them to decide if they wish to become active
contributors.

It's clear from core developer comments, I think, that providing an ActiveX
control is not a priority for the core chromium or Google development
teams.  I've gotten the strong impression that if someone doesn't take
advocacy ownership of this issue it will continue to go nowhere -- perhaps
it's a false impression.  I've volunteered myself for the advocacy job
(which I would be happy to give up if someone else would like it), and I've
taken steps to begin code-based exploration.  My interest here is solely a
working browser control based on chrome that satisfies a finite set of
design goals (see parent thread).  I'm not seeking to write a web browser,
as has been suggested, no is my intent to release a product that competes
with chrome.

As has been mentioned by others, I could more easily fork chrome and develop
whatever I choose.  However, I prefer an approach that will allow me to
contribute my changes back to the chrome project as a whole.  I've
demonstrated this preference with a number of changes, admittedly small,
that I've implemented in the past.  I have no expectation that new changes I
make will be accepted.  I'm positive, however, that they won't be accepted
if I don't first make the effort to discuss them with the chromium
development team.  That is why, up to this point, the discussion has been
primarily abstract -- issues this important should not be decided by one
individual, especially when that individual (myself) is not intimately
familiar with the design choices behind current chromium internals.



>
>
> > While forking is always an option with an open source project, it is
> never a
> > decision to be taken lightly.  I maintain hope that we can all peacefully
> > coexist in the same code base.
>
> Well, Chromium is intentionally licensed mostly under a BSD-style
> license.  Anyone really is welcome to do whatever they want with the
> code (we've already had one complete fork that we're aware of).
> However, that doesn't mean that anyone's changes will be accepted into
> the main project--it just means that people or teams that want to take
> it in a different direction will have to do more of the work to
> maintain it.  I'll note that this is, in effect, how the Chromium team
> has been functioning relative to WebKit until our recent drive to
> un-fork, so it's not an unfamiliar approach for us.
>
> > Unfortunately, the chrome ActiveX team is a small group of developers
> with
> > limited development time and resources.
>
> Ah, I hadn't realized that a team had organized around the ActiveX
> idea.  Out of curiosity, what sort of resources have you brought
> together, and who else is involved?


The resources brought together so far are: 1 part-time advocate willing to
do development (myself), and 5 people providing input.  I'm hopeful that as
the ActiveX concept is fleshed out more people will contribute ideas and/or
code.

I'm not asking chromium or Google to commit development resources to t

[chromium-dev] Re: Quick and dirty chrome embedding test

[Amanda Walker]

On Mon, Nov 17, 2008 at 10:19 AM, Marshall Greenblatt
<[EMAIL PROTECTED]> wrote:
> Hi M-A,
>
> We all know that development issues can become emotional for those closely
> involved with them.  Lets all please make an extra effort not to assume the
> worst about other people's intentions or meanings.

I don't think anyone is doing that--we're just trying to figure out
what you're trying to do.  You keep talking in the abstract, so it's a
little hard to follow.

> The intent with these comments is to address Ben's stated concerns about
> whether the current chrome UI look/feel would be appropriate for an embedded
> context.  Everyone so far has agreed that it would not.  Most people wishing
> to utilize the chrome code base have no desire to develop a competing
> product.  We simply wish to utilize existing chrome capabilities in our
> applications without re-implementing them.

Hmm.  "Everyone," "most people," "we," ... so, are you representing a
development team?  That hasn't been clear to me--I've been assuming
you've been speaking for yourself.

What we've had so far (at least on chromium-dev) are a bunch of people
asking "so, how could I embed chromium in my application?", along with
a variety of suggestions about how to do it (both short-term, using
test_shell as a basis, and long-term, where ideas like COM servers
have come up).  This is all good discussion.

> While forking is always an option with an open source project, it is never a
> decision to be taken lightly.  I maintain hope that we can all peacefully
> coexist in the same code base.

Well, Chromium is intentionally licensed mostly under a BSD-style
license.  Anyone really is welcome to do whatever they want with the
code (we've already had one complete fork that we're aware of).
However, that doesn't mean that anyone's changes will be accepted into
the main project--it just means that people or teams that want to take
it in a different direction will have to do more of the work to
maintain it.  I'll note that this is, in effect, how the Chromium team
has been functioning relative to WebKit until our recent drive to
un-fork, so it's not an unfamiliar approach for us.

> Unfortunately, the chrome ActiveX team is a small group of developers with
> limited development time and resources.

Ah, I hadn't realized that a team had organized around the ActiveX
idea.  Out of curiosity, what sort of resources have you brought
together, and who else is involved?

> Re-implementing existing functionality is not currently an option for us.
> Modifying the existing browser code base to expose existing functionality is
> an option.  I hope that the chromium developers and Google are willing to
> work with us so that the final solution is beneficial for everybody.

We're certainly willing to work with people who have ideas or
contributions, but that doesn't mean that we're willing to jump on
board the first implementation idea to come by.  Chromium already has
mechanisms to do much of what you're describing, but embedding more of
the browser code has some far-reaching implications--it's not as
simple as "wrap a COM server around what's already there".

> As you say, IWebBrowser2 would need to be extended.  As with any successful
> development project we plan to take baby steps the whole way.  We have not
> committed to supporting IWebBrowser2, but are considering it as a means for
> providing a basic level of compatibility with existing clients.  If we
> choose to go with IWebBrowser2 then we will extend its capabilities only at
> the appropriate time.

Have you set up a wiki or something with some of these
ideas/decisions/etc. that we could take a look at?   That might help.

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

[chromium-dev] Re: Quick and dirty chrome embedding test

[Marshall Greenblatt]

Hi M-A,

On Mon, Nov 17, 2008 at 9:02 AM, Marc-Antoine Ruel <[EMAIL PROTECTED]>wrote:

>
> 2008/11/16 Marshall Greenblatt <[EMAIL PROTECTED]>:
> > 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
>
> Ah I see, it took me a while to realize but you don't want to embed
> it, you want to create a custom UI above the chromium browser. Ok well
> then it's mostly a fork you are looking to. Otherwise, like I and Ben
> said, for a truly embedded html viewer, RenderViewHost is the best
> place to hook.


I should also mention that Mozilla supports themes:

https://developer.mozilla.org/en/Themes

Perhaps this can be used as a basis for our own support.



>
>
>
> > 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.
>
> Tabs? You cannot provide tabs with IWebBrowser2 without adding a new
> interface and major UI coordination. You should look at implementing
> the base functionality first before looking at complex issues like tab
> support.
>
> Actually, do you really need to do anything at all? I mean, if you
> want to have a help center browser, have you thought about using:
> path\to\chrome.exe
> --user-data-dir=path\to\my\help\center\tmp-data-dir
> --app=path\to\my\help\center\index.html
>
> M-A


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: Quick and dirty chrome embedding test

[Marshall Greenblatt]

Hi M-A,

We all know that development issues can become emotional for those closely
involved with them.  Lets all please make an extra effort not to assume the
worst about other people's intentions or meanings.

On Mon, Nov 17, 2008 at 9:02 AM, Marc-Antoine Ruel <[EMAIL PROTECTED]>wrote:

>
> 2008/11/16 Marshall Greenblatt <[EMAIL PROTECTED]>:
> > 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
>
> Ah I see, it took me a while to realize but you don't want to embed
> it, you want to create a custom UI above the chromium browser.


The intent with these comments is to address Ben's stated concerns about
whether the current chrome UI look/feel would be appropriate for an embedded
context.  Everyone so far has agreed that it would not.  Most people wishing
to utilize the chrome code base have no desire to develop a competing
product.  We simply wish to utilize existing chrome capabilities in our
applications without re-implementing them.


> Ok well
> then it's mostly a fork you are looking to.


While forking is always an option with an open source project, it is never a
decision to be taken lightly.  I maintain hope that we can all peacefully
coexist in the same code base.


> Otherwise, like I and Ben
> said, for a truly embedded html viewer, RenderViewHost is the best
> place to hook.


Unfortunately, the chrome ActiveX team is a small group of developers with
limited development time and resources.  We are all developing other
applications full-time (or part-time) that we hope will one day be able to
use chrome as an embedded browser component.  I'm sure you've read all of
the messages in this thread, but here's an review of what we're trying to
accomplish just to be clear:

1. Easy implementation and use by the client-side developer, preferably in
the language of their choice.
2. Provide as much browser-like functionality as possible by default.
3. Allow the client to override, customize or disable default functionality
if desired.
4. Minimize changes to the existing chromium code base, and avoid
duplication of existing functionality if possible.
5. Take advantage of new features, bug fixes and enhancements to chromium
while requiring minimal changes to the "embedded component."

Re-implementing existing functionality is not currently an option for us.
Modifying the existing browser code base to expose existing functionality is
an option.  I hope that the chromium developers and Google are willing to
work with us so that the final solution is beneficial for everybody.


>
>
>
> > 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.
>
> Tabs? You cannot provide tabs with IWebBrowser2 without adding a new
> interface and major UI coordination. You should look at implementing
> the base functionality first before looking at complex issues like tab
> support.


As you say, IWebBrowser2 would need to be extended.  As with any successful
development project we plan to take baby steps the whole way.  We have not
committed to supporting IWebBrowser2, but are considering it as a means for
providing a basic level of compatibility with existing clients.  If we
choose to go with IWebBrowser2 then we will extend its capabilities only at
the appropriate time.


>
>
> Actually, do you really need to do anything at all? I mean, if you
> want to have a help center browser, have you thought about using:
> path\to\chrome.exe
> --user-data-dir=path\to\my\help\center\tmp-data-dir
> --app=path\to\my\help\center\index.html


This is a fine idea for somebody looking for a completely independent help
viewer, and I encourage anyone with that purpose in mind to try this
solution.  Many of us, however, use embedded browsers as an integral part of
our application user interface.  For us it's necessary to have a level of
fine-grained control over the browser's behavior that is not currently
available with chrome.


>
>
> M-A


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: Quick and dirty chrome embedding test

[Marc-Antoine Ruel]

2008/11/16 Marshall Greenblatt <[EMAIL PROTECTED]>:
> 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

Ah I see, it took me a while to realize but you don't want to embed
it, you want to create a custom UI above the chromium browser. Ok well
then it's mostly a fork you are looking to. Otherwise, like I and Ben
said, for a truly embedded html viewer, RenderViewHost is the best
place to hook.


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

Tabs? You cannot provide tabs with IWebBrowser2 without adding a new
interface and major UI coordination. You should look at implementing
the base functionality first before looking at complex issues like tab
support.

Actually, do you really need to do anything at all? I mean, if you
want to have a help center browser, have you thought about using:
path\to\chrome.exe
 --user-data-dir=path\to\my\help\center\tmp-data-dir
 --app=path\to\my\help\center\index.html

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: Quick and dirty chrome embedding test

[Marshall Greenblatt]

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

[chromium-dev] Re: Quick and dirty chrome embedding test

[Ben Goodger (Google)]

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. At any rate, it's typical of web
frame embedding APIs to defer this functionality to the client.

This concern is solely related to UI. 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?

-Ben

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

[chromium-dev] Re: Quick and dirty chrome embedding test

[Marshall Greenblatt]

Hi Ken,

Thank you for your very concise analysis of the licensing question :-).

Regards,
Marshall

On Sun, Nov 16, 2008 at 8:25 PM, Ken Berry <[EMAIL PROTECTED]> wrote:

>
> Marshall,
>
> You should ask your attorney if you need to change the language of
> your licensing disclosures, but the answer is yes, you can extract any
> code snippets or whole systems that you want.  Chrome is already a
> derived work of MPL-licensed code, so nothing is changed overall.
>
> However, if you were to scatter MPL-licensed code throughout Chrome,
> you would either have to carefuly identify each instance or make the
> whole of Chrome subject to the MPL as well as the other licenses for
> each library.  Right now, Google-produced code is under the BSD
> license alone (as you say, the packages Chrome uses have other
> licenses), and the whole of Chrome is a derived work under all of the
> licenses involved.
>
> I think the only practical consideration is whether you might someday
> want to change Chrome to NOT be a MPL derived work.  As it is now, if
> you eliminated 5 libraries, MPL would no longer apply.  On the other
> hand, so what?  The MPL grants a non-exclusive royalty free right to
> copy, distribute, and modify that is no more onerous than the other
> open source licenses that apply.
>
> I am not an attorney, but a developer.  If this were my project, I
> would simply make my final work subject to the licenses of all the
> parts, and then freely slice, dice, mix, and match to accomplish
> whatever programming goal  was at hand.  The only exception would be
> code that I was using temporarily, and then I would keep it carefully
> segregated and intact.
>
> I suggest consulting the attorney not so much to ask if you can chop
> up the code (the term in the license is "modify" and the license says
> you can), but because the license page you gave the URL to would have
> to be somewhat different.  Also, there may be reasons that Google does
> not want to be forever tied to anything but the BSD license.
> Presumably that has been considered when the Chromium project was
> started.
>
> Ken
>
> On Sun, 16 Nov 2008 17:45:55 -0500, you wrote:
>
> >On Sun, Nov 16, 2008 at 5:32 PM, Daniel A. White <[EMAIL PROTECTED]
> >wrote:
> >
> >> Well they are already using some MPL code.
> >> http://code.google.com/chromium/terms.html :P
> >
> >
> >Hmm.  I think most of the code currently licensed under MPL is kept as
> >separate libraries (npapi, npsr, etc).  I'm not sure if us copying code
> >piecemeal from an MPL-licensed project would make a difference.
> >
> >
> >>
> >>
> >> An idea from me - allow styling of ui components. Hehe.
> >
> >
> >Perhaps we should consider UI themes, with functionality similar to how
> >theme drawing is handled on Windows:
> >
> >http://msdn.microsoft.com/en-us/library/ms997646.aspx
> >
> >Does WebKit already have and/or is it considering this concept?
> >
> >
> >>
> >>
> >> Daniel A. White
> >
> >
>
> >
>

--~--~-~--~~~---~--~~
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: Quick and dirty chrome embedding test

[Ken Berry]

Marshall,

You should ask your attorney if you need to change the language of
your licensing disclosures, but the answer is yes, you can extract any
code snippets or whole systems that you want.  Chrome is already a
derived work of MPL-licensed code, so nothing is changed overall.

However, if you were to scatter MPL-licensed code throughout Chrome,
you would either have to carefuly identify each instance or make the
whole of Chrome subject to the MPL as well as the other licenses for
each library.  Right now, Google-produced code is under the BSD
license alone (as you say, the packages Chrome uses have other
licenses), and the whole of Chrome is a derived work under all of the
licenses involved.  

I think the only practical consideration is whether you might someday
want to change Chrome to NOT be a MPL derived work.  As it is now, if
you eliminated 5 libraries, MPL would no longer apply.  On the other
hand, so what?  The MPL grants a non-exclusive royalty free right to
copy, distribute, and modify that is no more onerous than the other
open source licenses that apply.

I am not an attorney, but a developer.  If this were my project, I
would simply make my final work subject to the licenses of all the
parts, and then freely slice, dice, mix, and match to accomplish
whatever programming goal  was at hand.  The only exception would be
code that I was using temporarily, and then I would keep it carefully
segregated and intact.  

I suggest consulting the attorney not so much to ask if you can chop
up the code (the term in the license is "modify" and the license says
you can), but because the license page you gave the URL to would have
to be somewhat different.  Also, there may be reasons that Google does
not want to be forever tied to anything but the BSD license.
Presumably that has been considered when the Chromium project was
started.

Ken

On Sun, 16 Nov 2008 17:45:55 -0500, you wrote:

>On Sun, Nov 16, 2008 at 5:32 PM, Daniel A. White <[EMAIL PROTECTED]>wrote:
>
>> Well they are already using some MPL code.
>> http://code.google.com/chromium/terms.html :P
>
>
>Hmm.  I think most of the code currently licensed under MPL is kept as
>separate libraries (npapi, npsr, etc).  I'm not sure if us copying code
>piecemeal from an MPL-licensed project would make a difference.
>
>
>>
>>
>> An idea from me - allow styling of ui components. Hehe.
>
>
>Perhaps we should consider UI themes, with functionality similar to how
>theme drawing is handled on Windows:
>
>http://msdn.microsoft.com/en-us/library/ms997646.aspx
>
>Does WebKit already have and/or is it considering this concept?
>
>
>>
>>
>> Daniel A. White
>
>

--~--~-~--~~~---~--~~
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: Quick and dirty chrome embedding test

[Marshall Greenblatt]

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

[chromium-dev] Re: Quick and dirty chrome embedding test

[Ben Goodger (Google)]

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.

-Ben

On Sun, Nov 16, 2008 at 12:10 AM, Marshall Greenblatt
<[EMAIL PROTECTED]> wrote:
> On Sat, Nov 15, 2008 at 1:37 AM, Marshall Greenblatt
> <[EMAIL PROTECTED]> wrote:
>>
>> To test the feasibility of turning Chrome into a multi-process ActiveX
>> control I'm going to implement a simple experiment sans COM.  The goal of
>> this experiment is to have a client application launch chrome.exe
>> programatically as a separate process, and have the chrome process then
>> create its frame as a child window of the client application, at a position
>> that the client application specifies.  The client application will (a)
>> spawn the chrome.exe process passing it an HWND and target window rectangle
>> via command-line arguments, and (b) terminate the chrome.exe process when it
>> exits.  Other than that, the chrome process will be completely independent
>> of the client application (for now).
>
> The working implementation of this experiment is available here:
> http://codereview.chromium.org/10973
>
> Implementation highlights:
>
> 1. Add a new EMBEDDED BrowserType value in browser\browser_type.h
> 2. Add new members and setters/getters to the Browser and BrowserView
> classes to support storage and retrieval of a parent HWND value in
> browser\browser.h and browser\views\frame\browser_view.h
> 3. Add two new command-line switches that are checked by
> BrowserInit::LaunchBrowserImpl() in browser\browser_init.cc to create a
> Browser object of type EMBEDDED.
> 4. Add new EmbeddedFrame and EmbeddedNonClientView classes in
> browser\views\frame that are used for EMBEDDED Browsers by
> BrowserFrame::CreateForBrowserView() in
> browser\views\frame\browser_window_factory.cc.
> 5. Add a new IsEmbedded() method to the TabContentsDelegate class in
> tab_contents_delegate.h and update dependant classes.
> 6. Add a simple client application in browser\client that loads chrome using
> the embedded flags.
> 7. Various crash and assert fixes.
>
> Any comments or suggestions are welcome :-).
>
> The next step will be defining the COM interface.  Chrome currently uses ATL
> in a number of places (do a search for ), so using ATL to program
> the COM interfaces should be an acceptable choice.
>
> 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: Quick and dirty chrome embedding test

[Marshall Greenblatt]

On Sun, Nov 16, 2008 at 5:32 PM, Daniel A. White <[EMAIL PROTECTED]>wrote:

> Well they are already using some MPL code.
> http://code.google.com/chromium/terms.html :P


Hmm.  I think most of the code currently licensed under MPL is kept as
separate libraries (npapi, npsr, etc).  I'm not sure if us copying code
piecemeal from an MPL-licensed project would make a difference.


>
>
> An idea from me - allow styling of ui components. Hehe.


Perhaps we should consider UI themes, with functionality similar to how
theme drawing is handled on Windows:

http://msdn.microsoft.com/en-us/library/ms997646.aspx

Does WebKit already have and/or is it considering this concept?


>
>
> Daniel A. White

--~--~-~--~~~---~--~~
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: Quick and dirty chrome embedding test

[Daniel A. White]

Well they are already using some MPL code.
http://code.google.com/chromium/terms.html :P

An idea from me - allow styling of ui components. Hehe.

Daniel A. White


On Sun, Nov 16, 2008 at 5:20 PM, Marshall Greenblatt <[EMAIL PROTECTED]
> wrote:

> On Sun, Nov 16, 2008 at 5:15 PM, Marshall Greenblatt <
> [EMAIL PROTECTED]> wrote:
>
>>
>> The advantages would be immediate access for people who use only the basic
>> IWebBrowser2 capabilities (which is probably most of the user base), and the
>> option to borrow COM code from XULRunner :-).
>>
>
> Well, perhaps not that last one.  Would anyone care to render an opinion on
> borrowing code from an MPL-licensed project for inclusion in chrome?
>
> http://www.mozilla.org/MPL/MPL-1.1.html
>
>
> >
>

--~--~-~--~~~---~--~~
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: Quick and dirty chrome embedding test

[Marshall Greenblatt]

On Sun, Nov 16, 2008 at 5:15 PM, Marshall Greenblatt <[EMAIL PROTECTED]
> wrote:

>
> The advantages would be immediate access for people who use only the basic
> IWebBrowser2 capabilities (which is probably most of the user base), and the
> option to borrow COM code from XULRunner :-).
>

Well, perhaps not that last one.  Would anyone care to render an opinion on
borrowing code from an MPL-licensed project for inclusion in chrome?

http://www.mozilla.org/MPL/MPL-1.1.html

--~--~-~--~~~---~--~~
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: Quick and dirty chrome embedding test

[Marshall Greenblatt]

On Sun, Nov 16, 2008 at 3:32 PM, thetrueaplus <[EMAIL PROTECTED]>wrote:

>
> I know Microsoft has this interface.  IWebBrowser2.
>
> http://msdn.microsoft.com/en-us/library/aa752127(VS.85).aspx
>
> Gecko's ActiveX component implements this.


What do people think?  Should we implement a partial plug-in replacement for
IWebBrowser2, similar to Mozilla's implementation, or go our own way?

This page describes the interfaces that Mozilla implements:
http://www.iol.ie/~locka/mozilla/control.htm
I don't think they've added much, if any, additional capabilities since
rolling it into XULRunner.

If we choose to clone IWebBrowser2 we can always selectively implement
and/or extend it.  The advantages would be immediate access for people who
use only the basic IWebBrowser2 capabilities (which is probably most of the
user base), and the option to borrow COM code from XULRunner :-).

--~--~-~--~~~---~--~~
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: Quick and dirty chrome embedding test

[thetrueaplus]

I know Microsoft has this interface.  IWebBrowser2.

http://msdn.microsoft.com/en-us/library/aa752127(VS.85).aspx

Gecko's ActiveX component implements this.
--~--~-~--~~~---~--~~
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: Quick and dirty chrome embedding test

[Marshall Greenblatt]

On Sat, Nov 15, 2008 at 1:37 AM, Marshall Greenblatt <[EMAIL PROTECTED]
> wrote:

> To test the feasibility of turning Chrome into a multi-process ActiveX
> control I'm going to implement a simple experiment sans COM.  The goal of
> this experiment is to have a client application launch chrome.exe
> programatically as a separate process, and have the chrome process then
> create its frame as a child window of the client application, at a position
> that the client application specifies.  The client application will (a)
> spawn the chrome.exe process passing it an HWND and target window rectangle
> via command-line arguments, and (b) terminate the chrome.exe process when it
> exits.  Other than that, the chrome process will be completely independent
> of the client application (for now).


The working implementation of this experiment is available here:
http://codereview.chromium.org/10973

Implementation highlights:

1. Add a new EMBEDDED BrowserType value in browser\browser_type.h
2. Add new members and setters/getters to the Browser and BrowserView
classes to support storage and retrieval of a parent HWND value in
browser\browser.h and browser\views\frame\browser_view.h
3. Add two new command-line switches that are checked by
BrowserInit::LaunchBrowserImpl() in browser\browser_init.cc to create a
Browser object of type EMBEDDED.
4. Add new EmbeddedFrame and EmbeddedNonClientView classes in
browser\views\frame that are used for EMBEDDED Browsers by
BrowserFrame::CreateForBrowserView() in
browser\views\frame\browser_window_factory.cc.
5. Add a new IsEmbedded() method to the TabContentsDelegate class in
tab_contents_delegate.h and update dependant classes.
6. Add a simple client application in browser\client that loads chrome using
the embedded flags.
7. Various crash and assert fixes.

Any comments or suggestions are welcome :-).

The next step will be defining the COM interface.  Chrome currently uses ATL
in a number of places (do a search for ), so using ATL to program
the COM interfaces should be an acceptable choice.

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: Quick and dirty chrome embedding test

[Daniel A. White]

I am excited to see this going forth.  It will really open up developers
options once this is fully operational.  Thanks!

Daniel A. White


On Sat, Nov 15, 2008 at 6:55 PM, Marshall Greenblatt <[EMAIL PROTECTED]
> wrote:

> Hi M-A,
>
> Thank you for your questions :-).
>
> On Sat, Nov 15, 2008 at 2:21 PM, Marc-Antoine Ruel <[EMAIL PROTECTED]>wrote:
>
>>
>> Have you thought about other possible implementations?
>
>
> We're still very much in the exploratory stage, and so all options are
> currently on the table.  The final solution will need to balance a number of
> overlapping concerns in order to be feasible from both a usage and
> development perspective.  Here they are, numbered for ease of reference but
> not necessarily importance.
>
> 1. Easy implementation and use by the client-side developer, preferably in
> the language of their choice.
> 2. Provide as much browser-like functionality as possible by default.
> 3. Allow the client to override, customize or disable default functionality
> if desired [1].
> 4. Minimize changes to the existing chromium code base, and avoid
> duplication of existing functionality if possible.
> 5. Take advantage of new features, bug fixes and enhancements to chromium
> while requiring minimal changes to the "embedded component."
>
> A nice plus would be delivering the embedded component as part of the
> normal chromium software distribution channels.  That way we can ensure that
> all users benefit from chromium improvements without embedded clients being
> left behind (as happened with MS's web browser control).
>
>
> [1] In my experience embedded browser clients generally come in one of two
> flavors.  There are clients who need a viewer with minimal application
> control and there are clients who need the embedded browser to act as an
> integrated part of the user interface.  The embedded control that I envision
> would support the first type of client by default while allowing the second
> type of client whatever level of control they need.  Some examples of the
> advanced interfaces we'll eventually support:
>
> A. Security considerations.  Allow the client application to set zone
> permissions and control what type of content can be loaded.
> B. Resource streams.  The client application can intercept or initiate
> resource load requests and provide in-memory data streams.
> C. DOM manipulation.  The client application can access and manipulate the
> DOM programmatically.
> D. Host client plug-ins.  Render in-page plug-ins that are actually
> components belonging to the client application.
> E. Full JS support.  Allow the client to make JS calls to the browser, and
> visa-versa.
>
>
>>
>>
>> - Create a thin activex control that would load chrome.dll and use it
>> in-process so you could use it mostly unmodified. (You'd need to
>> integrate some modifications first)
>
>
> Can you provide a bit more information about what changes you foresee
> needing to make in order to load chrome.dll in-process?
>
>
>>
>>
>> - Forget about the browser component and reimplement
>> RenderProcessHost, RenderViewHost, RenderWidgetHost, etc. Actually,
>> you don't need this for embedding.
>
>
> The re-implementation is something that I've already done, in a manner
> similar to the test_shell project.  Unfortunately we then loose numbers 2, 4
> and 5 in the above requirements list.
>
>
>> You probably just need to split
>> browser.lib in two and just keep the relevant hosting part.
>
>
> This is something that is likely to happen as we gain a better
> understanding of what pieces are extraneous for the embedded component.
> There's no requirement that we use the existing chrome.exe or chrome.dll in
> the final implementation -- it's just convenient for now.
>
>
>>
>>
>> Do you think you would gain much by making it out of process?
>
>
> This is a tough question to answer.  I think the major gain is in
> stability, similar to why chrome hosts tabs and plug-ins in separate
> processes.  If I were an application developer using chrome as the basis for
> a help system then I wouldn't want my application going down if chrome
> crashes.  After all, help isn't central to the application's main purpose.
> If, on the other hand, I'm using chrome as the basis for my user interface
> then a crash in chrome could be fatal for my application irrespective of
> whether it's in-process or out of process.
>
> The final answer to this question will probably come from the
> implementation side.  For instance, if we find significant performance
> advantages to one approach over the other, or if there's a feature that can
> only be implemented using a particular approach.
>
>
>>
>>
>> M-A
>
>
> 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 mo

[chromium-dev] Re: Quick and dirty chrome embedding test

[Marshall Greenblatt]

Hi M-A,

Thank you for your questions :-).

On Sat, Nov 15, 2008 at 2:21 PM, Marc-Antoine Ruel <[EMAIL PROTECTED]>wrote:

>
> Have you thought about other possible implementations?


We're still very much in the exploratory stage, and so all options are
currently on the table.  The final solution will need to balance a number of
overlapping concerns in order to be feasible from both a usage and
development perspective.  Here they are, numbered for ease of reference but
not necessarily importance.

1. Easy implementation and use by the client-side developer, preferably in
the language of their choice.
2. Provide as much browser-like functionality as possible by default.
3. Allow the client to override, customize or disable default functionality
if desired [1].
4. Minimize changes to the existing chromium code base, and avoid
duplication of existing functionality if possible.
5. Take advantage of new features, bug fixes and enhancements to chromium
while requiring minimal changes to the "embedded component."

A nice plus would be delivering the embedded component as part of the normal
chromium software distribution channels.  That way we can ensure that all
users benefit from chromium improvements without embedded clients being left
behind (as happened with MS's web browser control).


[1] In my experience embedded browser clients generally come in one of two
flavors.  There are clients who need a viewer with minimal application
control and there are clients who need the embedded browser to act as an
integrated part of the user interface.  The embedded control that I envision
would support the first type of client by default while allowing the second
type of client whatever level of control they need.  Some examples of the
advanced interfaces we'll eventually support:

A. Security considerations.  Allow the client application to set zone
permissions and control what type of content can be loaded.
B. Resource streams.  The client application can intercept or initiate
resource load requests and provide in-memory data streams.
C. DOM manipulation.  The client application can access and manipulate the
DOM programmatically.
D. Host client plug-ins.  Render in-page plug-ins that are actually
components belonging to the client application.
E. Full JS support.  Allow the client to make JS calls to the browser, and
visa-versa.


>
>
> - Create a thin activex control that would load chrome.dll and use it
> in-process so you could use it mostly unmodified. (You'd need to
> integrate some modifications first)


Can you provide a bit more information about what changes you foresee
needing to make in order to load chrome.dll in-process?


>
>
> - Forget about the browser component and reimplement
> RenderProcessHost, RenderViewHost, RenderWidgetHost, etc. Actually,
> you don't need this for embedding.


The re-implementation is something that I've already done, in a manner
similar to the test_shell project.  Unfortunately we then loose numbers 2, 4
and 5 in the above requirements list.


> You probably just need to split
> browser.lib in two and just keep the relevant hosting part.


This is something that is likely to happen as we gain a better understanding
of what pieces are extraneous for the embedded component.  There's no
requirement that we use the existing chrome.exe or chrome.dll in the final
implementation -- it's just convenient for now.


>
>
> Do you think you would gain much by making it out of process?


This is a tough question to answer.  I think the major gain is in stability,
similar to why chrome hosts tabs and plug-ins in separate processes.  If I
were an application developer using chrome as the basis for a help system
then I wouldn't want my application going down if chrome crashes.  After
all, help isn't central to the application's main purpose.  If, on the other
hand, I'm using chrome as the basis for my user interface then a crash in
chrome could be fatal for my application irrespective of whether it's
in-process or out of process.

The final answer to this question will probably come from the implementation
side.  For instance, if we find significant performance advantages to one
approach over the other, or if there's a feature that can only be
implemented using a particular approach.


>
>
> M-A


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: Quick and dirty chrome embedding test

[Marc-Antoine Ruel]

Have you thought about other possible implementations?

- Create a thin activex control that would load chrome.dll and use it
in-process so you could use it mostly unmodified. (You'd need to
integrate some modifications first)

- Forget about the browser component and reimplement
RenderProcessHost, RenderViewHost, RenderWidgetHost, etc. Actually,
you don't need this for embedding. You probably just need to split
browser.lib in two and just keep the relevant hosting part.

Do you think you would gain much by making it out of process?

M-A

On Sat, Nov 15, 2008 at 1:37 AM, Marshall Greenblatt
<[EMAIL PROTECTED]> wrote:
> Hi All,
>
> To test the feasibility of turning Chrome into a multi-process ActiveX
> control I'm going to implement a simple experiment sans COM.  The goal of
> this experiment is to have a client application launch chrome.exe
> programatically as a separate process, and have the chrome process then
> create its frame as a child window of the client application, at a position
> that the client application specifies.  The client application will (a)
> spawn the chrome.exe process passing it an HWND and target window rectangle
> via command-line arguments, and (b) terminate the chrome.exe process when it
> exits.  Other than that, the chrome process will be completely independent
> of the client application (for now).
>
> To demonstrate the overall concept I've created a pair of basic (non-chrome)
> "client" and "server" applications.  The source and VS2005 projects are
> available here:
>
> http://www.magpcss.net/patches/interprocex1.zip
>
> Build both in debug mode and then run the client application.  The client
> application will launch the server application with command-line arguments
> that cause the server application to create and render a child window (red
> rectangle) in the client.  When the client application exits the server
> application is also terminated.
>
> If anyone has comments or suggestions I'd love to hear from you.  Otherwise,
> you may consider this a heads-up and background on what may be a series of
> very strange questions over the next few days :-).
>
> 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
-~--~~~~--~~--~--~---