[webkit-dev] Widget / Drawing API thoughts
mjs at apple.com
Sun Jun 19 21:35:36 PDT 2005
On Jun 11, 2005, at 9:05 AM, Kevin Ollivier wrote:
> Hi Justin,
> On Jun 10, 2005, at 3:15 PM, Justin Haygood wrote:
>> Even though I'm nowhere near there yet (got to get JSCore working
>> first ;) ), here is an idea:
>> Have KWQ use cross-platform C/C++ implementations, keeping
>> everything as high level as possible, and use C++ inheritence to
>> inherit from platform specific implementations.
>> for instance, QRegion can be implemented sans Cocoa for the stuff
>> that is already cross platform, but inherit from a KWQRegion which
>> has different implementations for Cocoa, Win32, GTK+, Qt (hey, why
>> not?), wxWidgets, etc...
> I definitely agree something like this would be very helpful, but
> I'm curious as to why you'd want to inherit the platform-specific
> implementation from the base implementation, rather than vice-versa.
> For example, what would be great for us is that the common classes
> all have KWQ(something)Base classes with virtual methods, from
> which we derive toolkit-specific implementations. This is helpful
> because even for completely "toolkit neutral" classes, like
> KWQBrush, we sometimes need to have a way of converting that to or
> from, say, a wxBrush that we can use. So with this approach, we
> could just add our accessor functions to a toolkit-specific
> implementation, and reuse the rest from the common implementation.
> For classes with no real way of having a 'toolkit-independent'
> implementation, base classes could just be stubs.
Looking at the Q-replacement classes in kwq, I think they probably
all fall into two categories:
1) Almost entirely platform-independent, with possibly a bit of
platform-dependent logic for converting to native toolkit types.
QString and QColor would be in this category.
2) Almost entirely platform-dependent, with almost no platform-
So I think there's a way to do this that doesn't rely on inheriting
from special base classes. For both categories 1 and 2, we'd share
the headers, with #ifdefs for the platform-dependent data members and
any native conversion methods. For category 1, define the few
platform-specific conversion functions in a platform-dependent file.
For category 2, put the whole implementation in a different platform-
The problem with inheriting from platform-independent base classes is
that you would have to use multiple inheritance to get the
inheritance hierarchy right. For instance, QCheckBox would have to
inherit from QButton *and* from QCheckBoxBase, which QButton would
have to inherit from QButtonBase. I think this would be needlessly
complex, and I guess whole separate implementations of the widgets
are likely to be fine.
More information about the webkit-dev