[webkit-dev] Directories and KWQ
Kevin Ollivier
kevino at theolliviers.com
Fri Feb 10 08:57:21 PST 2006
Hi David,
On Feb 10, 2006, at 3:22 AM, David Hyatt wrote:
> On Feb 9, 2006, at 10:56 PM, Kevin Ollivier wrote:
>
>> Hi all,
>>
>> I've been watching the directory moves, and I was wondering if
>> there were any plans on what to do about the KWQ dir, as portions
>> of that will definitely need to be migrated to platform-specific
>> code.
>>
>
> KWQ is going to go away completely.
>
> We basically have two new directories that will ultimately be
> crucial to building a port. These are very much under construction
> right now. Files are moving around a lot.
>
> The first is "platform" and this consists of all the low-level
> constructs that sit underneath the engine. This includes most of
> the old Qt classes from KWQ as well as some additional data
> structures and classes. Most of this directory is cross-platform,
> and platform-specific implementations of objects (like widgets,
> timers, etc.) go under respective platform directories. Right now
> we have two sub-directories for specific operating systems under
> platform, called mac and win.
>
> In addition we have two graphics libraries we are using now:
> CoreGraphics and Cairo. Cairo is itself a cross-platform graphics
> layer, and so we didn't just stick it under the Windows directory.
> Instead we put it under a cairo subdirectory in platform.
>
> A given port can then pick technology pieces it needs based off
> both the target OS (e.g., the mac/win directory) or a particular
> technology like Cairo. For example Windows is using Cairo right
> now but could in theory be plugged into something else. In theory
> the Mac could be plugged into Cairo instead of CoreGraphics.
>
> A wxWidgets port would presumably put low-level code that used
> wxWidgets classes in a wxWidgets subdirectory under platform.
>
> We are also in the process of developing a bridge directory. This
> directory is about the engine communicating "up and out" to an
> enclosing layer. In the Mac's case that layer is WebKit. We have
> native code subdirectories here too (only mac currently).
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? 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. :-/
Kevin
> dave
> (hyatt at apple.com)
>
More information about the webkit-dev
mailing list