Hi, > The QtWidgets part of it, at least, is feature-parity with Qt 4, so it's technically not a *new* feature. It does, however, mean that you'll have less time to stabilise the code >compared to the rest of Qt. And I do expect this to be an area of serious interest once 5.0 is out: if we don't do a good job, we'll be told desktops no longer matter for >Qt, <yadda yadda yadda. Where do you expect source compatibility to be broken?
The work to be done is (as I see it): - Think of a plugin API/ class structure such for desktop themes. It should be usable for QtWidgets as well as for potential QML desktop components, so. it should probably go to QtGui with no dependency to the QtWidget classes (partially already visible in the QPlatformDialogHelper classes). I seem to remember there were also plans for a separate QtDesktop library .. not sure if that makes sense. It has also has to account for different Desktops on one platform (think KDE/Gnome/Unity on Linux). That requires some thought and some reorganization of classes, I suppose. - Go over the modules and factor out platform stuff like: #if defined(Q_WS_WIN) SystemParametersInfo(SPI_GETDROPSHADOW, 0, &shadow, 0); shadowWidth = shadow ? 0 : 6; } #elsif defined(Q_WS_MAC) shadowWidth = .... #endif The API needs to be as flexible as possible (QVariant themeHint(enum what)). Still, if the feature freeze happens before finishing the reorganization or important stuff that needs to go to those plugins is discovered later on, there is a chance for source compatibility breakage. Friedemann -- Friedemann Kleint Qt Open Source Team _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development