Inquiry for Advice

[jarrednicholls]

Hi Marshall,

FIrst off, great work on CEF. It's a great project with a lot of potential.

I'm here to ask for some advice. My goal is to utilize everything in the Chromium architecture, minus the browser process' UI (and related browser "functionality", such as bookmarks et el). So I do want all of the multi-process architecture and IPC, resource loading/caching via "net", and all html5 functionality that requires glue code such as File System API, Drag and Drop, web database, you name it.

CEF is not exactly what I'm looking for. It's very close, but I don't need a library abstracting the Chromium types (and being a step behind Chromium as far as exposing the features), and I would like to keep in tact most of the browser process' functionality (most importantly, its setup of net for resource loading, IPC, spawning of renderer/GPU/plugin processes, etc.) But, hacking away at the browser process code and removing everything I don't want is something I'm trying to avoid. I basically want the Browser instances (chrome/browser/ui/browser.cc) but no UI...and everything else just works. I understand a lot of browser_main would need to be copy/pasted just for setting up the browser process.

Given your work on CEF, do you have any advice on this task? Is there a practical way to create my own gyp project, include the appropriate chromium dependencies (just like CEF), and only copy/paste a minimal amount of init code to then be able to statically include and consume Chromium code to create browser frames that can be painted inside of my own apps' windows? Or am I going down a slippery slope and will find myself having to rip out a shit ton of inter-twined UI code and changing everything? Just wondering if you tried to do what I'm wanting to do first, and then resorted to a basic "embed into single process and re-glue each piece one by one" model? Or did you simply re-glue everything to make a clean API (something I'm not interested in doing)?

Sorry for the long winded post and many questions. I am very interested to replace QtWebKit with Chromium for my work because it is way ahead of the curve in implementing its glue code for all of the major HTML5 features in webkit repo. I am working with my webkit team to finish committing a lot of the Qt glue code for many of the missing HTML5 features, but am interested in using Chromium in the meantime since it's equipped.

Hoping you can provide any bit of guidance! Many thanks ahead of time!

Jarred

[magreenblatt]

Hi Jarred,

You've directly and indirectly asked a lot of questions that should probably be addressed individually. I've paraphrased your post into a series of questions to make the responses clearer.

1. Is it possible to completely change the Chromium multi-process UI without hacking up the existing code?

No. Chromium is not currently designed to allow easy swapping out of the complete UI. Themes can be used to change some aspects of the Chromium look/feel, and some abstraction has been done to support different platforms and frameworks, but that's probably not what you're looking for. As a side note, porting Chromium to Qt has also been discussed in the past but I'm not sure what the current status is.

2. OK, but what if I want to completely replace the UI anyways? What kind of effort would be involved?

Work is currently underway to move all code related to the Chromium UI design (window layout for tabs, gear menu, address bar, etc) into the chrome/browser/ui/ directory [1]. This includes a refactoring of the TabContents class which currently contains layout-related code [2]. Once the moving and refactoring is complete it may be possible to replace the contents of chrome/browser/ui/ with something else. However, keeping significant changes to chrome/browser/ui/ up-to-date with Chromium HEAD would likely be more than a full-time job.

3. What if I don't care about tabs and just want a multi-process Chromium window similar to what I see when running Chromium in App Mode but parented to my application window instead?

Chromium does not currently support the parenting of browser windows to other applications but the changes to enable this usage would be relatively minor. You will need to change browser initialization and tweak some layout-related behavior. Keeping these changes up-to-date with Chromium HEAD would likely require a few hours per week.

4. Can I statically link the Chromium browser process code into my application?

Maybe, but you won't gain anything by doing so. The chrome.exe executable and chrome.dll dynamic library are required for all processes that Chromium executes (renderer, plugin, GPU, etc). If you statically link Chromium you will be duplicating code that must still exist separately in chrome.exe and chrome.dll. Furthermore, you will be introducing an additional maintenance burden.

5. If I don't statically link the Chromium browser process how can my code use it?

I recommend that you use the same approach that Chromium uses. Create a host system that executes chrome.exe with certain command-line flags and communicates with the resulting process via IPC [3]. This is the approach implemented by the CEF2 project [4].

6. Can I statically link an IPC-based Chromium browser host into my application?

Yes. You will need to define the IPC protocol and implement support for it in Chromium, but the host system itself will have only a few Chromium-related dependencies. It will be rather light-weight and easily linked into an existing application.

7. Just wondering if you tried to do what I'm wanting to do first, and then resorted to a basic "embed into single process and re-glue each piece one by one" model? Or did you simply re-glue everything to make a clean API (something I'm not interested in doing)?

When I began working with Chromium in 2008 I explored the multi-process approach and created a basic demo. However, the Chromium developers were not supportive of the idea and I quickly realized the amount of work that would be required to maintain it. After having success with the single-process version of CEF I revisited the multi-process approach and created the CEF2 project as a complete working demo of all the required technologies. The single-process version has seen the most interest up to this point due to its light weight design and close integration with the host application and so I haven't revisited CEF2 since it was released in July.

An important design goal for CEF has always been the creation of a simple and easy-to-use API that insulates the user from the underlying Chromium and WebKit complexity. Understandably, this is not a desirable attribute for all potential consumers.

Hopefully I've answered all of your questions .

Regards,
Marshall

[1] http://groups.google.com/a/chromium.org ... edc56c899a
[2] http://groups.google.com/a/chromium.org ... 3dc5ca14ee
[3] http://www.chromium.org/developers/desi ... munication
[4] viewtopic.php?f=10&t=122

[jarrednicholls]

Hi Marshall,

Thanks very much for the quick reply, and for taking the time to do so! I do believe you have answered my questions, albeit I am left with the age old question "why" pertaining to one of them.

Although my question may have sounded as such, I'm not really looking to replace the UI. Instead, I'm really just trying to do what CEF does, but without abstracting Chromium code...and instead to use the Chromium code verbatim. I'm assuming this is what you do in your library, as I don't see any patches to chromium code. In other words, you're just including and using Chromium code as-is. Is this assumption incorrect? If it's incorrect, then what files in Chromium's trunk did you have to patch, and where are those patches?

Clearly you aren't replicating everything from the Chromium browser process/host in libcef. How does libcef really relate to Chromium in this case? Are you indeed just using the Chromium trunk as an "application framework"? In other words, you are simply re-building a host container for Chromium's webkit glue, and using their base/net/etc. libraries as your "cross-platform API" analogous to Qt or GTK? At least that's how I'm trying to wrap my head around it. I mean, just going through some of the code, it looks like you're re-writing everything the Chromium browser process has already written (File System API, dom storage, etc.), and using their boiler plate code in the same way the browser process does. I'm just making sure I'm on base with that fast-skim observation.

Thanks much,
Jarred

[magreenblatt]

Hi Jarred,

The CEF project has two separate implementations, CEF and CEF2. Both expose an API via a dynamic library that hides implementation details from the host application. However, that's where the similarities end.

CEF is based on the single-process test_shell application and uses the Chromium WebKit API directly with no dependency on the Chromium browser code underneath the chrome/ directory. CEF and test_shell have similar but not identical implementations of application and HTML5 glue code. You can also create an application that uses the Chromium WebKit API directly if you choose, but it will be a single-process implementation, and you will need to copy or implement the same glue code. All changes so far that CEF has required to the Chromium project have been contributed back as part of that project.

CEF2, on the other hand, is multi-process and uses the existing Chromium browser application. CEF2 provides a container implementation that launches chrome.exe as a separate process and communicates with it via IPC. It requires changes to the Chromium project code that will never be accepted as part of that project. Those changes can be found in the branches/cef2/patch directory.

So, in summary, if you want a single-process browser window you can use the same approach as CEF and test_shell. If, however, you want a multi-process browser window you will need to use an approach similar to CEF2. In both cases it will require effort on your part to keep your code up-to-date with the Chromium HEAD revision.

A number of individuals and organizations have done integration work on top of CEF for languages and frameworks such as Delpi, Java, .NET, C# and wxWidgets. You may want to consider building your Qt layer on top of CEF instead of duplicating or re-inventing code as this will likely be less work for you in the long run. Any changes that you contribute back to CEF will benefit from the larger support community.

Regards,
Marshall

[jarrednicholls]

Terrific explanation, and duly noted regarding Qt implementation. Thanks again!