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
([EMAIL PROTECTED])
_______________________________________________
webkit-dev mailing list
[email protected]
http://www.opendarwin.org/mailman/listinfo/webkit-dev
