[webkit-dev] Porting Gtk+WebCore

[Kevin Ollivier]

Hi Kent,

On Jun 10, 2005, at 2:24 AM, Kent Sandvik wrote:

> On 6/10/05, Maciej Stachowiak <mjs at apple.com> wrote:
>
>> There's really several different things in the KWQ directory:
>>
>> 1) Fairly platform-agnostic replacements for things like data
>> structures and QString (QDict is one exception here, but we'll be
>> changing that to not rely on CFDictionary any more). These could just
>> be used for any platform that uses KWQ instead of the real Qt.
>>
>
> Hmm, CF Lite (Core Foundation Lite)? The only issue I see is the
> license that is neither BSD nor LGPL for the CFLite sources... But
> those could then be ported across various platforms, already working
> for Linux), and the data structures and so forth are nice, string
> classes that support Unicode, unless there's too much overlap between
> KQW and CFLite...

BTW, I wanted to point out that when we started wxWebCore, we  
evaluated using CFLite, only to find that the software no longer  
builds outside of OS X/Darwin (even w/patches applied) and hasn't for  
some time.

In order to get it to build, I had to go back to using the CFLite  
sources from initial Panther releases, which was the version used in  
the CFLite tutorial on the ADC web site. (even some subsequent 10.3.x  
releases of CFLite didn't build) In addition, in newer versions,  
there are now several places where CFLite references private OS X/ 
Darwin headers. ;-/ It's possible we could have got it to work  
somehow, but we decided that we couldn't use CFLite for our port if  
it wasn't being maintained in a cross-platform manner.

It would, of course, be great if CFLite were made to work cross- 
platform again and have Windows support added. But IMHO, looking at  
the sources, it's probably an easier task to remove CF from common  
bits of KWQ and JSCore (as there isn't a whole lot) than it is to  
have someone maintaining CFLite cross-platform and being sure it  
builds on Windows as well, etc. There's lots of CF code in the  
platform-specific part, but that's closely tied with Cocoa, so we had  
to re-implement those bits anyways, and it was easier just to use our  
own APIs for that. So far, that's been our experience.

Thanks,

Kevin