[webkit-dev] Directories and KWQ

[Kevin Ollivier]

Hi David,

On Feb 10, 2006, at 4:07 PM, David Hyatt wrote:

> On Feb 10, 2006, at 8:57 AM, Kevin Ollivier wrote:
>
>> I guess my question then is how long it will take for it this to  
>> be implemented, and how much change will we see in terms of the  
>> API from the old KWQ classes?
>
> It's an ongoing process that will take a while (a couple of months  
> at least).   As far as individual classes, the approach has  
> varied.  In some cases we're eliminating classes completely (we did  
> that with QPaintDevice and QPaintDeviceMetrics for example).  In  
> other cases we move the class more or less as is but plan major  
> architectural changes to how they work (Timers are an example of  
> this).  Finally in some cases we move the class and leave the API  
> completely alone (QMemArray -> Array).
>
> In cases where the layer was using more Qt classes than we really  
> needed, we're streamlining and eliminating those classes to make  
> the code simpler and more readable.  (A Qt implementation could  
> still easily use those classes to implement our streamlined layer.)
>
>> I'm talking with people interested in contributing to a port and  
>> it sounds like their interest is in having a port in a matter of a  
>> few months. (We also have a lot of KWQ stuff that's already been  
>> moved over to wx that we'd like to make use of.) So I'd like to,  
>> of course, capitalize on that and help try to move the port forward.
>>
>> I have no problem throwing stuff in platform, and using classes  
>> like String instead of QString (except that we will need wxString<- 
>> >String helper functions, of course), but I was wondering if  
>> there's some way we could get to work using the existing codebase  
>> without making radical alterations later, or perhaps getting some  
>> instructions as to what APIs we would need to conform to so that  
>> we can write straight to the new APIs rather than start on  
>> existing ones.
>>
>> Thanks, and sorry for all the questions. :-/
>
> I see a few options here:
>
> (1) Have your port live in our tree, which would at least mean that  
> developers could move/rename your files at the same time they do  
> others.  The upside is you stay current.  The downside is we'd  
> probably be breaking you all the time.
>
> (2) Track our changelogs very closely and make similar changes in  
> your tree.  (Would probably be pretty hard.)
>
> (3) Wait for our restructuring to finish, continue with your port  
> off a branch of our tree (is that what you're using now?), and then  
> move your code to our new layer afterwards.
>
> There is no single document that can describe everything we plan to  
> do for each class because frankly we don't know what we're going to  
> do with each class yet.  Right now we're relying on a second  
> porting effort (on Win32) to help us figure out what we need to do.

I've thought about this, and I think it's best to start with #1. If  
it doesn't work out, we can always make the decision to branch and do  
periodic merges if we feel that's what we need to do, but I think  
we'll eventually want to be in your tree anyways, and so I think the  
idea of keeping pace with the main tree is at least worth a try.  
Would this be a problem for you guys?

We're currently using a branch, but I've found that things like the  
proper timing to do a merge are tricky to determine, and if the merge  
leads to significant conflicts, we may have to fix quite a bit of  
stuff before our tree builds again, and I think it's easier on people  
to spend a couple hours each weekend fixing any breakages rather than  
making a major project of it after a merge.

Thanks for all your help!

Kevin

> dave
> (hyatt at apple.com)
>