On Jun 20, 2005, at 2:06 PM, Kent Sandvik wrote:
On 6/19/05, Maciej Stachowiak <[EMAIL PROTECTED]> 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
_______________________________________________
webkit-dev mailing list
[email protected]
http://www.opendarwin.org/mailman/listinfo/webkit-dev
