[webkit-dev] Widget / Drawing API thoughts

[Maciej Stachowiak]

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- 
independent logic.

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- 
dependent file.

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.

Regards,
Maciej