[webkit-dev] Directories and KWQ
hyatt at apple.com
Fri Feb 10 16:07:42 PST 2006
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.
(hyatt at apple.com)
More information about the webkit-dev