Sam and I talked about this at length over coffee this evening. He and I agreed, this conversation should be less about #ifdefs and more about abstractions. I'm sure I'm clear on which abstractions we need for Chromium (beyond ScriptController, and GraphicsContext), certainly not as clear as Darin or Amanda would be. Code examples could help here.
-eric p.s. Also, my comment earlier about leniency was more seeking to avoid the intentional or unintentional filibuster of Chromium additions to WebKit. We (Chromium) want to live out of WebKit's tree. To do so will require a number of changes (mostly not to core classes). Few of those changes should be #ifdefs. I in no way wish to propose "lowering" of WebKit's high coding standards, simply realizing that as WebKit did with the initial Mac port (on KWQ), the initial Windows port, the landing of SVG code, or the landing of any large section of code, our Chromium code will not be perfect when it lands. But we'd like to get it in to webkit.org as soon as possible to get our hackers hacking with the rest of WebKit on core WebKit improvements, instead of just on our port maintenance. p.p.s. I should also note that Amanda is currently focused on the Mac port, while changes you've seen from myself and others are about our Windows port. We owe you a lot of Windows code yet, but Amanda's primary concern (as I understand it) is how to lay the foundation for a successful Mac port of Chromium. Since we're open this time around, we'd like to share as much code with the Apple-Mac-WebKit up-front, instead of forking so many files as we did for our Windows port. On Wed, Sep 24, 2008 at 10:44 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: > > On Sep 24, 2008, at 10:10 PM, Amanda Walker wrote: > >> On Wed, Sep 24, 2008 at 7:25 PM, Maciej Stachowiak <[EMAIL PROTECTED]> >> wrote: >>> On Sep 24, 2008, at 3:36 PM, Darin Fisher wrote: >>>> I don't think anything about our port implies hosted in a rendering >>>> subprocess. Our port works perfectly well in a single process >>>> traditional >>>> browser model. We build two embedding apps based on our port of >>>> WebKit: >>>> test_shell and chrome. The former is like a mash-up of DRT and >>>> Spinneret. >>> >>> OK; that appears to disagree with what Amanda said above. >> >> Not really--our architectural changes were made to support >> multiprocess rendering, but they do not require it. test_shell still >> renders into a bitmap and then blits that to the OS window, it just >> does it all within a single process. But all of the drawing, event >> handling, geometry management, etc. go through the same set of host & >> delegate interfaces that the multiprocess app does, rather than >> talking to the top level view(s) directly. The implementations of >> those interfaces in test_shell are just a lot simpler. > > What do you think would be a more accurate (but succinct) way to > describe the purpose of the changes or the feature they enable? Is > "multi-process" close enough to accurate or is there a better way to > put it? I ask because I am hoping we can pick some ifdef flags that > are based on the features being added or the technologies being used, > and not just a catchall based on the embedding product. As I mentioned > before, our experience with catchall ifdefs like that has been poor, > and once they get into the source they can be a lot of work to untangle. > > Regards, > Maciej > > _______________________________________________ > webkit-dev mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
