On 6/30/14, 10:06 AM, "Olivier Goffart" <oliv...@woboq.com> wrote: > >I think there should be some kind of long term goal to avoid using >private >headers.
I totally agree with you on that. Private headers are private for a reason. If API from a private header is needed outside the project itself, this is an indication that the API should be available publicly. > > >We need to find a solution so that one need not to inherit from >QObjectPrivate. (There is already QObject::setUserData, but it could be >done >better i guess) > >We need also to identify private APIs that could be polished and made >public. >For some modules such as QtQuick this is probably too hard. >But for new modules such as WebEngine or such, it may be possible to >avoid >dependency on private API. QtQuick is exactly why Qt WebEngine uses private headers. ;-) I think it is not reasonable to tie Qt WebEngine to the version number of Qt. This also implies if we just as an example cherry-pick a critical security fix from chromium to Qt WebEngine, we would have to bump the version number of the whole of Qt. And therefore build and release new packages for everything. - And Qt WebEngine is only one single module. - Zeno _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
