On 2/3/13 11:12 PM, "ext Maciej Stachowiak" <m...@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. _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev