[webkit-dev] Widget / Drawing API thoughts

[Maciej Stachowiak]

On Jun 20, 2005, at 2:06 PM, Kent Sandvik wrote:

> On 6/19/05, Maciej Stachowiak <mjs at apple.com> wrote:
>
>
>>> 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.
>>
>
> Yes, it would be cleaner if each platform had their own
> platform-specific implementation in a separate source directory, if
> there's anything common that never needs a platform-specific file, it
> could be placed in a src/common dir or something similar. Note that
> you could have C++ member functions for a class that could be
> implemented in the system-specific dir, *as well as* common member
> function implementations that don't need any platform code.
>
> One step in the current build tree would be to separate the KWQ header
> files into a separate directory, and move the existing implementation
> files into a macosx dir, as I assume most of the code is
> macosx-centric, anyway. Then there could be a migration moving some of
> the code into a src/common or something similar.
>
> I could help out with that in case this part of the project starts,
> but usually it's best if one person does the big surgical operation
> and checks it all in.

I was thinking of maybe a tree structure like this

WebCore
     khtml
     bridge (stuff from kwq that's for bridging to a higher level API  
library, not about replacing Qt/KDE)
     kwq (strictly Qt/KDE replacements)
         headers
         common
         macosx

Then gtk could be added as a peer directory to macosx (and hopefully  
in the future xwwindows, symbian, win32, and so forth).

One complicating factor here is the fact that we are planning to redo  
the way form controls are done soon. We want to make the layout  
engine draw them directly instead of using platform-native widgets,  
so instead of the various Qt widget classes we'd mostly just end up  
with a theme API for drawing the native look.

Perhaps temporarily we could set up the tree to work with either  
model, so ports can convert to the theme API approach on their own  
schedule.

Any thoughts from Nokia folks on how this would affect the Gtk+ or  
symbian ports?

Regards,
Maciej