[webkit-dev] Directories and KWQ

[David Hyatt]

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.

dave
(hyatt at apple.com)