On Jun 20, 2005, at 2:06 PM, Kent Sandvik wrote:
On 6/19/05, Maciej Stachowiak <mjs@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