I'd like to share with you some ideas we had about the platform/ directory. First, our aim is to use WebKit on embedded platforms. We did a sample Linux implementation based on SDL. It was easy to see what we needed to implement thanks to the platform/ dir. But hopefully we will have to do many ports, and some parts have to be reusable as is. On way to ease those ports was to abstract all headers in platform/ (only pure virtual methods in classes). Thus, headers in platform would be truly platform-independent. Moreover we avoid the need of adding a #ifdef for each platform. The platform/ dir can then be considered as a Browser Abstraction Layer. We started from Mike Emmel's GDK port, we cut out platform into several subdirs placed in BAL/Implementation : - Events, abstracted events and event loop ; - Fonts ; - Graphics, abstracted GraphicsContext, and files as in platform/graphics/ ; - ImageDecoders ; - Network ; - Types, various cross-platform types ; - Widgets. And in BAL/Interfaces, all abstract headers that should be implemented in BAL/Implementation. We also thought of an abstraction for : - Internationalization (ICU library); - Posix (libm, memory manager for now); - XML (libxml and libxslt). This way, the BAL is independent of WebCore and can be compiled aside. Unit tests have been written and are reusable for each platform. What do you think about this choice for platform/ ? We plan to publish this sample implementation and the abstraction layers impacting changes as soon as we've reached a reasonably stable and mature level. Sebastien. On 12/5/06, Darin Adler <darin@apple.com> wrote:

Recently, we discussed the platform directory a bit in a bug <http:// bugs.webkit.org/show_bug.cgi?id=11596>.

I thought I'd say a few things on this point to the entire list.

The "platform" directory is where we have the platform that the rest of WebCore is built on top of. The primary focus is platform- independent wrappers for platform specific services, like events, graphics systems, as well as some basic data structures.

The platform independent interfaces and implementation are at the top level, and platform-specific implementations go into directories named with the nickname for each platform (e.g. "mac" for Macintosh, "qt" for Qt, "win" for Windows). Since most headers are shared, some platform-specific code is in the headers guarded by appropriate #if statements.

We also expect to have platform-specific implementations in some other places in the source tree. What goes into the platform directory is a platform abstraction that the rest of the library is built on. But in some cases, you can't build the platform specifics into a platform abstraction -- you need platform specifics in the higher level code.

At the moment, a couple of directories that are have this kind of platform-specific code are page and loader. (Much of the code currently in bridge/mac belongs in page/mac.) While we'd like to keep from doing this all over the code, we will need platform specifics outside the platform directory when they can't easily be abstracted into a generic cross-platform concept.

I see signs that people are misunderstanding this approach a bit. For example, FrameQt and PageQt absolutely do not belong in platform/qt. They should be in page/qt instead.

I'm sorry that this wasn't explained clearly enough in the past.

-- Darin _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev