On Sat, Aug 9, 2014 at 7:21 AM, charleyb123 . <[email protected]> wrote: > Just a silly question related to the Qt roadmap (I don't want to distract > this weekend's Qt5.4 freeze-activity): > > Qt6 (and even Qt7) has been mentioned on this list in the past year, and I > was curious if there were a "30,000-mile-high-view" of what might be > "on-deck" for consideration. > > A web-search or qt-project.org search doesn't really show much discussion: > https://qt-project.org/search/tag/roadmap > > A Jira Road Map report doesn't really show much: > https://bugreports.qt-project.org/browse/QTBUG#selectedTab=com.atlassian.jira.plugin.system.project:roadmap-panel > > For example, Qt5 might be summarized something like (I'm sure I'm missing > some): > > *- New "modularized-library" infrastructure > *- C++11, function-pointers for signals/slots > *- QML as solid dev/deploy platform > *- Balanced focus on both desktop and mobile > *- Connectivity/Networking improvements > *- Big investments in OpenGL, Qt3D > *- Deployment of new Qt Platform Abstraction > *- Mobile deployment, "App-store" deployment > *- New platforms, (e.g., Android, iOS, Win8, WinRT, BB10, ...) > *- Transition from QtWebKit to QtWebEngine > *- Start of rework on QtPrinter > *- etc. > > IMHO, that's a pretty fantastic list (and I'm sure I've missed some). When > you throw in tremendous advances in QtCreator, embedded-device and > "Boot-to-Qt" support, and work on QBS, and new features like Enginio > (web/cloud), it speaks a very compelling story. > > Possible future items might be something like: > > *- ?? C++14/17 support (recall that the C++ Standards committee is looking > at speculative work to support "modules" and possibly "runtime-reflection", > and I know Thiago has been looking at how that might be relevant to > Qt/signals-slots/role-of-moc) > *- ?? Qt3D advances > *- ?? QML packaging/plugins/deployment work > *- ?? Cross-process signals/slots (pretty please? ;-)) > *- ?? New modules > *- ??
As Robert mentioned, Qt 6 break would be for breaking current features, not adding new ones. Odds are it's going to be driven from the QtQuick/QtQml side, as that's the part with the most stuff we want to break. So when we want to switch to QtQuick 3 and version 3 of the QML language, that's when I expect we'll start planning a Qt 6. We're not there yet, but there are some things in QtQuick which are already scheduled for QtQuick 3 (when we get around to it). In particular the Window type needs to be broken out to be a QML-only wrapper type, based on QQuickItem, instead of exposing QQuickWindow directly. A bunch of properties also where we might want to change the default value, but that's just breaking stuff so it depends on how much of a break we want QtQuick 3 to be. We already know that we want it to be less of a break than QtQuick 1->2; since we don't expect to replace SceneGraph that could mean that QtQuick 3 and QtQuick 2 elements could co-exist on the same scene. It's also expected that the new ModelViews would replace the current ModelViews in QtQuick 3. Given how we haven't even completed the research phase of the new ModelViews, you can see that QtQuick 3 is likely still years away. -- Alan Alpert _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
