[webkit-dev] WebKit Wishes

[noam.rosenthal at nokia.com]

On 2/3/13 11:12 PM, "ext Maciej Stachowiak" <mjs at apple.com> wrote:

>> Maybe the problem is less about the WK1 API layer and more about
>> WebCore/platform.
>
>I'm sure that's one problem, but I am still curious what Eric had in mind.
Yes, me too, and I don't mean to hijack that conversation :)

>> In many other projects, there is a common pattern of "platform
>>adaptation
>> layer", where there is a clear semi-public and stable interface exposed
>>by
>> the middleware, which allows platform adaptations to occur with less
>> intrusive dependencies. WebKit doesn't really have that notion, making
>>it
>> impossible to "port" webkit without either participating in trunk or
>> forking.
>
>I think it would be a good direction to have a better platform adaptation
>layer. Specific measures that I'd support:
>- Incrementally move Source/WebCore/platform/ to Source/Platform/ as
>suggested by Adam et al.
>- Remove knowledge of WebCore-level concepts from platform/ where they
>have crept in
>- Avoid using PLATFORM() or the equivalent in WebCore as much as possible
>(though ENABLE macros are fine of course)
Sounds like we're on the same page.

>I was ready to agree with you about platformContext() before I looked at
>the code. But checking WebCore/rendering/, it looks like the only calls
>to platformContext() are in port-specific theme files. The theme
>implementation is tricky because it needs knowledge of both rendering and
>platform/port-specific styles and drawing code. It seems to me that to
>have a truly clean interface for themes, you'd need to separate the part
>of the code that cares about Rendering classes and the part of the code
>that cares about platform stuff. Just adding a bunch of
>single-platform-only code to GraphicsContext to avoid calling
>platformContext() doesn't seem like it would actually make theme logic
>separate from the core. It's a problem worth solving, but the solution is
>not straightforward.
You're right, I think this used to be a bit worse but looking it again the
situation with WebCore/rendering is not too bad.
Still - GraphicsContext is quite inconsistent. Some of the functions of
that class are implemented in the port specific files (e.g. setAlpha) and
some in GraphicsContext.cpp; Some things are maintained by
GraphicsContextState, some only by the platform context. If there was a
clear contract about what belongs to the port-specific graphics context
and what belongs to the "common" GraphicsContext the differences between
the ports in that realm would be a lot more maintainable. And I think this
can be potentially extended to networking and to other places.