[Development] Feature freeze date?

[Friedemann Kleint]

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