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