Qt Modules Maturity Level: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
No edit summary
 
(Link to where less out-of-date information may be found.)
 
(9 intermediate revisions by 4 users not shown)
Line 1: Line 1:
=Qt Modules’ Maturity Levels (Qt 4 to Qt 5 transition)=
[[Category:Developing Qt::Qt Planning::Qt Public Roadmap]]
[[Category:Developing Qt]]
See also [[Maintainers]] for who maintains which module.
 
The available maturity levels are:
; Active Development: Receiving new features, changing quickly, bugs fixed
; Maintained: Receives occasional features, changes slowly, bugs fixed
; Done: No new features, changes very slowly, P2 bugs and up fixed only
; Deprecated: No new features, almost no changes, P1 and security fixes only, new code should not use it, old code should begin porting away
; Removed: Self-explanatory and not coming back
 
The following is out of date.
A more up to date account may be inferred from a recent' release's [https://doc.qt.io/qt-5/qtmodules.html table of modules].
 
= Qt Modules' Maturity Levels (Qt 4 to Qt 5 transition) =


'''''List last modified:''' 13 July 2011''
'''''List last modified:''' 13 July 2011''


The list below contains only what is not in states ''Active'' or ''Maintained''. We felt that the most important thing to do right now was to be really honest about what we (Nokia) are working on and what we’re not working on. This is especially important for people reporting bugs, since it is unlikely that we will fix low-priority issues in subsystems that are in the Done state or lower. What’s not on the list below is then under the state ''Active'' or ''Maintained'', like for example Qt D-Bus. Also note that this list focuses on Qt only, which is the older codebase, containing more legacy.
The list below contains only what is not in states ''Active'' or ''Maintained''. We felt that the most important thing to do right now was to be really honest about what we (Nokia) are working on and what we're not working on. This is especially important for people reporting bugs, since it is unlikely that we will fix low-priority issues in subsystems that are in the Done state or lower. What's not on the list below is then under the state ''Active'' or ''Maintained'', like for example Qt D-Bus. Also note that this list focuses on Qt only, which is the older codebase, containing more legacy.


This first publishing of the list is, by necessity of a blog, a static list. In reality, when Open Governance and Qt 5 work kick in, this list will be very much dynamic. I want to be very clear that the list can change and modules may go up or down in the Level scale. The only things that should not happen are: a) sacrifice quality and b) take Qt in the wrong direction (backwards). As an example of the latter point, functionality that gets Removed from Qt should not be brought back: we don’t want to support <span class="caps">IRIX</span>, the non-Unicode Windows versions or Microsoft Visual Studio 6.0.
This first publishing of the list is, by necessity of a blog, a static list. In reality, when Open Governance and Qt 5 work kick in, this list will be very much dynamic. I want to be very clear that the list can change and modules may go up or down in the Level scale. The only things that should not happen are: a) sacrifice quality and b) take Qt in the wrong direction (backwards). As an example of the latter point, functionality that gets Removed from Qt should not be brought back: we don't want to support IRIX, the non-Unicode Windows versions or Microsoft Visual Studio 6.0.


Let me remind you that ''Done'' is not ''Deprecated''! Done really means “stability and zero regressions are the most important things, so we are not adding features and we are not working on improving performance, but it’s fine to use this code”.
Let me remind you that ''Done'' is not ''Deprecated''! Done really means "stability and zero regressions are the most important things, so we are not adding features and we are not working on improving performance, but it's fine to use this code".


==Modules==
== Modules ==


* '''Active Qt'''<br /> Overall module state: Done<br /> New Maintainer Required
* '''Active Qt'''
* '''Phonon'''<br /> Overall module state: Done inside Qt, Maintained outside of Qt<br /> Reasoning: Qt Multimedia Kit recommended instead; development of Phonon continues and is maintained outside of Qt, by the <span class="caps">KDE</span> community.
Overall module state: Done <br>
* '''qmake'''<br /> Overall module state: Done<br /> Reasoning: stable code, we don’t recommend bringing it up in the level list. Research into a future, more modern buildsystem has started.
New Maintainer Required <br>
* '''XCode integration'''<br /> State: Deprecated<br /> New Maintainer Required.
* '''Phonon'''
* '''Qt Designer'''<br /> State: Done<br /> Reasoning: Qt Quick is recommended for developing UIs from now on, so the new Qt Quick Designer should take over the capabilities of the classic Qt Designer.
Overall module state: Done inside Qt, Maintained outside of Qt <br>
* '''Qt 3 Support'''<br /> Overall module state: Deprecated<br /> Reasoning: Qt 3 Support was provided as a porting layer from Qt 3, so the recommendation is to finish the port. Qt 3 Support will be Removed in Qt 5.
Reasoning: Qt Multimedia Kit recommended instead; development of Phonon continues and is maintained outside of Qt, by the KDE community. <br>
* '''Qt Core'''<br /> Overall module state: Active/Maintained
* '''qmake'''
** QFileSystemWatcher<br /> State: Deprecated<br /> Reasoning: flawed design, a replacement is required. We’re open for ideas in that area.
Overall module state: Done <br>
** Abstract file engines<br /> State: Deprecated<br /> Reasoning: flawed design, this is the wrong level to provide a virtual filesystem, so we don’t recommend taking this over. In Qt 5, this functionality will be Removed.
Reasoning: stable code, we don't recommend bringing it up in the level <br>list. Research into a future, more modern buildsystem has started. <br>
* '''Qt Declarative'''<br /> Overall module state: Active/Maintained
* '''XCode integration'''
** Graphics view support (i.e., <span class="caps">QML</span> 1.x)<br /> State: Done<br /> Reasoning: <span class="caps">QML</span> Scene Graph-based <span class="caps">QML</span> 2 is recommended and will become available in Qt 5.
State: Deprecated <br>
* '''Qt <span class="caps">GUI</span>'''<br /> Overall module state: Active/Maintained<br /> More information about reorganisation of this module, see the Qt 5 blog.
New Maintainer Required. <br>
** <span class="caps">XLFD</span> support for the font system<br /> State: Deprecated<br /> Reasoning: this is obsolete interface in X11 clients as modern systems use fontconfig; doesn’t affect other platforms.
* '''Qt Designer'''
** Graphics Effects<br /> State: Deprecated<br /> Reasoning: flawed design, we don’t recommend taking maintainership of this code.
State: Done <br>
** Graphics View<br /> State: Done<br /> Reasoning: stable code for which stability and reduced risk of regressions is more important; we don’t plan on adding more features.
Reasoning: Qt Quick is recommended for developing UIs from now on, so <br>the new Qt Quick Designer should take over the capabilities of the classic Qt Designer. <br>
** Implicit native child widget<br /> State: Done<br /> Reasoning: flawed design, we don’t recommend taking maintainership of this code.<br /> Note: widgets with explicit native window handles, like Direct3D view, will still be supported.
* '''Qt 3 Support'''
** Printing support<br /> State: Done<br /> New maintainer required.
Overall module state: Deprecated <br>
*** Postscript support – Deprecated<br /> Reasoning: obsolete support, <span class="caps">PDF</span> is enough nowadays.
Reasoning: Qt 3 Support was provided as a porting layer from Qt 3, so <br>the recommendation is to finish the port. Qt 3 Support will be <br>Removed in Qt 5. <br>
** QPainter<br /> State: Done<br /> Reasoning: stable code for which stability and reduced risk of regressions is more important; we don’t recommend bringing the maintainership level up.
* '''Qt Core'''
*** Raster and OpenGL (ES) 2 engines – Maintained.
Overall module state: Active/Maintained <br>
*** Other engines – Done and New Maintainer required.
:* QFileSystemWatcher
** QPainterPath’s “set” operations<br /> State: Deprecated<br /> Reasoning: flawed design, we don’t recommend taking maintainership of this code.
State: Deprecated <br>
** QPicture<br /> State: Deprecated<br /> New maintainer required.
Reasoning: flawed design, a replacement is required. We're open for ideas in that area. <br>
** QSound<br /> State: Deprecated<br /> Reasoning: better solution available in Qt Multimedia Kit.
:* Abstract file engines
** Styles<br /> State: Done<br /> Reasoning: stable code for which stability is extremely important, so we don’t recommend bringing the maturity level back up; Qt Quick-based development is expected for the future of UIs and, with it, Qt Quick-based theming and style possibilities.
State: Deprecated <br>
*** Motif and <span class="caps">CDE</span> styles – Deprecated<br /> Reasoning: obsolete.
Reasoning: flawed design, this is the wrong level to provide a virtual filesystem, so we don't recommend taking this over. In Qt 5, this functionality will be Removed. <br>
** Stylesheets<br /> State: Done<br /> Reasoning: stable code for which stability is extremely important, so we don’t recommend bringing the maturity level back up; Qt Quick-based development is expected for the future of UIs and, with it, Qt Quick-based theming and style possibilities.
* '''Qt Declarative'''
** Widget classes like QPushButton, QLineEdit, etc.<br /> State: Done<br /> Reasoning: stable code for which stability and reduced risk of regressions are important, so we don’t recommend bringing the maturity level back up; Qt Quick-based development is expected for the future of UIs, with Qt Quick Components.
Overall module state: Active/Maintained <br>
** <span class="caps">XIM</span> support<br /> State: Deprecated<br /> Reasoning: flawed design, we don’t recommend taking up maintainership of this code.
:* Graphics view support (i.e., QML 1.x)  
* '''Qt Network'''<br /> Overall module state: Active/Maintained
State: Done <br>
** QHttp and QFtp<br /> State: Deprecated<br /> Reasoning: replaced by QNetworkAccessManager; we welcome research supporting the filesystem functionality of <span class="caps">FTP</span> that is not currently present in QNetworkAccessManager. In Qt 5, these classes will be Removed.
Reasoning: QML Scene Graph-based QML 2 is recommended and will become available in Qt 5. <br>
* '''Qt Script'''<br /> Overall module state: Active/Maintained
* '''Qt GUI'''
** QScriptEngineAgent and related classes<br /> State: Deprecated<br /> Reasoning: flawed design, being replaced by a better design.
Overall module state: Active/Maintained <br>
* '''Qt <span class="caps">SQL</span>'''<br /> Overall module state: Done<br /> New maintainer required.
More information about reorganisation of this module, see the Qt 5 blog. <br>
* '''Qt <span class="caps">SVG</span>'''<br /> Overall module state: Deprecated<br /> New maintainer required<br /> Reasoning: <span class="caps">SVG</span> Full (as opposed to <span class="caps">SVG</span> Tiny) functionality available in Qt WebKit, which should be used instead; we welcome research for a replacement for the <span class="caps">SVG</span>-generating code.
:* XLFD support for the font system  
* '''QtWebKit'''<br /> Overall module state: Active/Maintained
State: Deprecated <br>
** QWebView and QGraphicsWebView<br /> State: Done<br /> Reasoning: moved to a separate library in Qt 5, the main entry point for web views will be the Qt Quick-based “webview” component.
Reasoning: this is obsolete interface in X11 clients as modern systems use fontconfig; doesn't affect other platforms. <br>
* '''Qt <span class="caps">XML</span>'''<br /> Overall module state: Done<br /> Reasoning: QXmlStreamReader and QXmlStreamWriter are recommended instead and are located in the Qt Core module.
:* Graphics Effects
* '''Qt <span class="caps">XML</span> Patterns'''<br /> Overall module state: Done<br /> New maintainer required.
State: Deprecated <br>
Reasoning: flawed design, we don't recommend taking maintainership of this code. <br>
:* Graphics View
State: Done <br>
Reasoning: stable code for which stability and reduced risk of regressions is more important; we don't plan on adding more features. <br>
:* Implicit native child widget
State: Done <br>
Reasoning: flawed design, we don't recommend taking maintainership of this code. <br>
Note: widgets with explicit native window handles, like Direct3D view, will still be supported. <br>
:* Printing support
State: Done <br>
New maintainer required. <br>
::* Postscript support – Deprecated <br>
Reasoning: obsolete support, PDF is enough nowadays. <br>
:* QPainter
State: Done <br>
Reasoning: stable code for which stability and reduced risk of <br>regressions is more important; we don't recommend bringing the <br>maintainership level up. <br>
::* Raster and OpenGL (ES) 2 engines – Maintained.
::* Other engines – Done and New Maintainer required.
:* QPainterPath's "set" operations
State: Deprecated <br>
Reasoning: flawed design, we don't recommend taking maintainership of this code. <br>
:* QPicture
State: Deprecated <br>
New maintainer required. <br>
:* QSound
State: Deprecated <br>
Reasoning: better solution available in Qt Multimedia Kit. <br>
:* Styles
State: Done <br>
Reasoning: stable code for which stability is extremely important, so we <br>don't recommend bringing the maturity level back up; Qt Quick-based development is expected for the future of UIs and, with it, Qt Quick- <br>based theming and style possibilities. <br>
::* Motif and CDE styles – Deprecated
Reasoning: obsolete.
:* Stylesheets
State: Done <br>
Reasoning: stable code for which stability is extremely important, so we <br>don't recommend bringing the maturity level back up; Qt Quick-based development is expected for the future of UIs and, with it, Qt Quick- <br>based theming and style possibilities. <br>
:* Widget classes like QPushButton, QLineEdit, etc.
State: Done <br>
Reasoning: stable code for which stability and reduced risk of <br>regressions are important, so we don't recommend bringing the <br>maturity level back up; Qt Quick-based development is expected for <br>the future of UIs, with Qt Quick Components. <br>
:* XIM support
State: Deprecated <br>
Reasoning: flawed design, we don't recommend taking up maintainership of this code. <br>
* '''Qt Network'''
Overall module state: Active/Maintained  
:* QHttp and QFtp
State: Deprecated <br>
Reasoning: replaced by QNetworkAccessManager; we welcome research <br>supporting the filesystem functionality of FTP that is not currently <br>present in QNetworkAccessManager. In Qt 5, these classes will be Removed.
* '''Qt Script'''
Overall module state: Active/Maintained <br>
:* QScriptEngineAgent and related classes
State: Deprecated <br>
Reasoning: flawed design, being replaced by a better design. <br>
* '''Qt SQL'''
Overall module state: Done <br>
New maintainer required. <br>
* '''Qt SVG'''
Overall module state: Deprecated <br>
New maintainer required <br>
Reasoning: SVG Full (as opposed to SVG Tiny) functionality available in <br> Qt WebKit, which should be used instead; we welcome research for a <br>replacement for the SVG-generating code. <br>
* '''QtWebKit'''
Overall module state: Active/Maintained <br>
:* QWebView and QGraphicsWebView
State: Done <br>
Reasoning: moved to a separate library in Qt 5, the main entry point for web views will be the Qt Quick-based "webview" component. <br>
* '''Qt XML'''
Overall module state: Done <br>
Reasoning: QXmlStreamReader and QXmlStreamWriter are recommended instead and are located in the Qt Core module. <br>
* '''Qt XML Patterns'''
Overall module state: Done <br>
New maintainer required.


==Functionality==
== Functionality ==


* '''Carbon support in Mac OS X'''<br /> State: Done<br /> Reasoning: Cocoa support is available and Carbon cannot be used to create 64-bit applications. We’d like eventually to Deprecate and even Remove this functionality during the Qt 5 lifecycle, as this code is currently a maintenance burden (like Windows non-Unicode was).
* '''Carbon support in Mac OS X'''
* '''HP-UX, <span class="caps">AIX</span> and Solaris support'''<br /> State: Done<br /> New maintainer required.
State: Done <br>
* '''Old Qt solutions archive'''<br /> State: Deprecated<br /> Reasoning: old code, not maintained anymore.
Reasoning: Cocoa support is available and Carbon cannot be used to create 64-bit applications. We'd like eventually to Deprecate and even Remove this functionality during the Qt 5 lifecycle, as this code is currently a maintenance burden (like Windows non-Unicode was). <br>
* '''Bearer Management inside Qt Mobility'''<br /> State: Deprecated for now, will probably be Removed in Qt 5.<br /> Reasoning: the copy of the code maintained in QtNetwork is the recommended interface.
* '''HP-UX, AIX and Solaris support'''
* '''Qt Multimedia inside Qt'''<br /> State: for 4.8 it is Deprecated, in Qt 5 it is replaced by the Qt Multimedia Kit copy with the modularisation of Qt.
State: Done<br>
* '''Phonon copy inside Qt'''<br /> State: Done<br /> Reasoning: a separate release of Phonon, with its own version numbers, is available and can be used instead; the copy inside Qt will not be updated further.
New maintainer required. <br>
* '''Qt WebKit copy inside Qt'''<br /> State: Deprecated<br /> Reasoning: a separate QtWebKit release, with its own version numbers, is available and should be used instead with Qt 4.7 and 4.8, for those looking for updates. In Qt 5, the separate release is reintegrated through the Qt modularisation.
* '''Old Qt solutions archive'''
* '''<span class="caps">QWS</span> (a.k.a. the current Qt for Embedded Linux)'''<br /> State: Done for Qt 4.8<br /> Reasoning: the new Lighthouse-based architecture is recommended for new features and new platforms.
State: Deprecated <br>
* '''Static builds of examples and demos'''<br /> State: Removed<br /> Reasoning: this is not maintained or checked and the Qt binary builds are always dynamic. Static builds aren’t required for reading the source code and learning Qt, they are never deployed to devices.
Reasoning: old code, not maintained anymore. <br>
* '''Static builds on Mac, Windows and Embedded Linux'''<br /> State: Done
* '''Bearer Management inside Qt Mobility'''
* '''Windows CE port'''<br /> State: Done<br /> New maintainer required.
State: Deprecated for now, will probably be Removed in Qt 5. <br>
* '''<span class="caps">WINSCW</span> port'''<br /> State: Done<br /> Reasoning: old and buggy compiler, required only for Symbian simulator builds, should be replaced with a new technology once that is available.
Reasoning: the copy of the code maintained in QtNetwork is the recommended interface. <br>
* '''Qt Multimedia inside Qt'''
State: for 4.8 it is Deprecated, in Qt 5 it is replaced by the Qt Multimedia Kit copy with the modularisation of Qt. <br>
* '''Phonon copy inside Qt'''
State: Done <br>
Reasoning: a separate release of Phonon, with its own version numbers, is available and can be used instead; the copy inside Qt will not be updated further. <br>
* '''Qt WebKit copy inside Qt'''
State: Deprecated <br>
Reasoning: a separate QtWebKit release, with its own version numbers, is<br> available and should be used instead with Qt 4.7 and 4.8, for those <br>looking for updates. In Qt 5, the separate release is reintegrated <br>through the Qt modularisation. <br>
* '''QWS (a.k.a. the current Qt for Embedded Linux)'''
State: Done for Qt 4.8 <br>
Reasoning: the new Lighthouse-based architecture is recommended for new features and new platforms. <br>
* '''Static builds of examples and demos'''
State: Removed <br>
Reasoning: this is not maintained or checked and the Qt binary builds <br>are always dynamic. Static builds aren't required for reading the <br>source code and learning Qt, they are never deployed to devices.
* '''Static builds on Mac, Windows and Embedded Linux'''
State: Done <br>
* '''Windows CE port'''
State: Done <br>
New maintainer required.
* '''WINSCW port'''
State: Done <br>
Reasoning: old and buggy compiler, required only for Symbian simulator builds, should be replaced with a new technology once that is available.


==Changing the list==
== Changing the list ==


The state of a given functionality or module is the choice of the maintainer of that code, who is the ultimate responsible for the quality. So the decision on whether new features and the extent of what other kinds of changes should be accepted or not is also the responsibility of this person. Therefore, to change the state, you have to either convince the current maintainer or become a maintainer yourself.
The state of a given functionality or module is the choice of the maintainer of that code, who is the ultimate responsible for the quality. So the decision on whether new features and the extent of what other kinds of changes should be accepted or not is also the responsibility of this person. Therefore, to change the state, you have to either convince the current maintainer or become a maintainer yourself.


In that light, we have been discussing with current contributors to Qt and asking them whether they would like to volunteer for maintainership of anything. [http://qt.digia.com/ Digia] ''[qt.digia.com]'' has already volunteered find someone to maintain the <span class="caps">AIX</span> and Solaris ports and [http://www.kdab.com/ <span class="caps">KDAB</span>] ''[kdab.com]'' has done the same for Windows CE. Becoming a maintainer for something inside Qt shouldn’t be too hard: it takes time and dedication, because it comes with a responsibility. (For that reason, we’d like people to prove that they can do it first, such as by maintaining a branch first)
In that light, we have been discussing with current contributors to Qt and asking them whether they would like to volunteer for maintainership of anything. [http://qt.digia.com/ Digia] has already volunteered find someone to maintain the AIX and Solaris ports and [http://www.kdab.com/ KDAB] has done the same for Windows CE. Becoming a maintainer for something inside Qt shouldn't be too hard: it takes time and dedication, because it comes with a responsibility. (For that reason, we'd like people to prove that they can do it first, such as by maintaining a branch first)
 
===Categories:===
 
* [[:Category:Developing Qt|Developing_Qt]]
** [[:Category:Developing Qt::Qt-Planning|Qt Planning]]
*** [[:Category:Developing Qt::Qt-Planning::Qt-Public-Roadmap|Qt Public Roadmap]]

Latest revision as of 09:34, 22 May 2019

See also Maintainers for who maintains which module.

The available maturity levels are:

Active Development
Receiving new features, changing quickly, bugs fixed
Maintained
Receives occasional features, changes slowly, bugs fixed
Done
No new features, changes very slowly, P2 bugs and up fixed only
Deprecated
No new features, almost no changes, P1 and security fixes only, new code should not use it, old code should begin porting away
Removed
Self-explanatory and not coming back

The following is out of date. A more up to date account may be inferred from a recent' release's table of modules.

Qt Modules' Maturity Levels (Qt 4 to Qt 5 transition)

List last modified: 13 July 2011

The list below contains only what is not in states Active or Maintained. We felt that the most important thing to do right now was to be really honest about what we (Nokia) are working on and what we're not working on. This is especially important for people reporting bugs, since it is unlikely that we will fix low-priority issues in subsystems that are in the Done state or lower. What's not on the list below is then under the state Active or Maintained, like for example Qt D-Bus. Also note that this list focuses on Qt only, which is the older codebase, containing more legacy.

This first publishing of the list is, by necessity of a blog, a static list. In reality, when Open Governance and Qt 5 work kick in, this list will be very much dynamic. I want to be very clear that the list can change and modules may go up or down in the Level scale. The only things that should not happen are: a) sacrifice quality and b) take Qt in the wrong direction (backwards). As an example of the latter point, functionality that gets Removed from Qt should not be brought back: we don't want to support IRIX, the non-Unicode Windows versions or Microsoft Visual Studio 6.0.

Let me remind you that Done is not Deprecated! Done really means "stability and zero regressions are the most important things, so we are not adding features and we are not working on improving performance, but it's fine to use this code".

Modules

  • Active Qt

Overall module state: Done
New Maintainer Required

  • Phonon

Overall module state: Done inside Qt, Maintained outside of Qt
Reasoning: Qt Multimedia Kit recommended instead; development of Phonon continues and is maintained outside of Qt, by the KDE community.

  • qmake

Overall module state: Done
Reasoning: stable code, we don't recommend bringing it up in the level
list. Research into a future, more modern buildsystem has started.

  • XCode integration

State: Deprecated
New Maintainer Required.

  • Qt Designer

State: Done
Reasoning: Qt Quick is recommended for developing UIs from now on, so
the new Qt Quick Designer should take over the capabilities of the classic Qt Designer.

  • Qt 3 Support

Overall module state: Deprecated
Reasoning: Qt 3 Support was provided as a porting layer from Qt 3, so
the recommendation is to finish the port. Qt 3 Support will be
Removed in Qt 5.

  • Qt Core

Overall module state: Active/Maintained

  • QFileSystemWatcher

State: Deprecated
Reasoning: flawed design, a replacement is required. We're open for ideas in that area.

  • Abstract file engines

State: Deprecated
Reasoning: flawed design, this is the wrong level to provide a virtual filesystem, so we don't recommend taking this over. In Qt 5, this functionality will be Removed.

  • Qt Declarative

Overall module state: Active/Maintained

  • Graphics view support (i.e., QML 1.x)

State: Done
Reasoning: QML Scene Graph-based QML 2 is recommended and will become available in Qt 5.

  • Qt GUI

Overall module state: Active/Maintained
More information about reorganisation of this module, see the Qt 5 blog.

  • XLFD support for the font system

State: Deprecated
Reasoning: this is obsolete interface in X11 clients as modern systems use fontconfig; doesn't affect other platforms.

  • Graphics Effects

State: Deprecated
Reasoning: flawed design, we don't recommend taking maintainership of this code.

  • Graphics View

State: Done
Reasoning: stable code for which stability and reduced risk of regressions is more important; we don't plan on adding more features.

  • Implicit native child widget

State: Done
Reasoning: flawed design, we don't recommend taking maintainership of this code.
Note: widgets with explicit native window handles, like Direct3D view, will still be supported.

  • Printing support

State: Done
New maintainer required.

  • Postscript support – Deprecated

Reasoning: obsolete support, PDF is enough nowadays.

  • QPainter

State: Done
Reasoning: stable code for which stability and reduced risk of
regressions is more important; we don't recommend bringing the
maintainership level up.

  • Raster and OpenGL (ES) 2 engines – Maintained.
  • Other engines – Done and New Maintainer required.
  • QPainterPath's "set" operations

State: Deprecated
Reasoning: flawed design, we don't recommend taking maintainership of this code.

  • QPicture

State: Deprecated
New maintainer required.

  • QSound

State: Deprecated
Reasoning: better solution available in Qt Multimedia Kit.

  • Styles

State: Done
Reasoning: stable code for which stability is extremely important, so we
don't recommend bringing the maturity level back up; Qt Quick-based development is expected for the future of UIs and, with it, Qt Quick-
based theming and style possibilities.

  • Motif and CDE styles – Deprecated

Reasoning: obsolete.

  • Stylesheets

State: Done
Reasoning: stable code for which stability is extremely important, so we
don't recommend bringing the maturity level back up; Qt Quick-based development is expected for the future of UIs and, with it, Qt Quick-
based theming and style possibilities.

  • Widget classes like QPushButton, QLineEdit, etc.

State: Done
Reasoning: stable code for which stability and reduced risk of
regressions are important, so we don't recommend bringing the
maturity level back up; Qt Quick-based development is expected for
the future of UIs, with Qt Quick Components.

  • XIM support

State: Deprecated
Reasoning: flawed design, we don't recommend taking up maintainership of this code.

  • Qt Network

Overall module state: Active/Maintained

  • QHttp and QFtp

State: Deprecated
Reasoning: replaced by QNetworkAccessManager; we welcome research
supporting the filesystem functionality of FTP that is not currently
present in QNetworkAccessManager. In Qt 5, these classes will be Removed.

  • Qt Script

Overall module state: Active/Maintained

  • QScriptEngineAgent and related classes

State: Deprecated
Reasoning: flawed design, being replaced by a better design.

  • Qt SQL

Overall module state: Done
New maintainer required.

  • Qt SVG

Overall module state: Deprecated
New maintainer required
Reasoning: SVG Full (as opposed to SVG Tiny) functionality available in
Qt WebKit, which should be used instead; we welcome research for a
replacement for the SVG-generating code.

  • QtWebKit

Overall module state: Active/Maintained

  • QWebView and QGraphicsWebView

State: Done
Reasoning: moved to a separate library in Qt 5, the main entry point for web views will be the Qt Quick-based "webview" component.

  • Qt XML

Overall module state: Done
Reasoning: QXmlStreamReader and QXmlStreamWriter are recommended instead and are located in the Qt Core module.

  • Qt XML Patterns

Overall module state: Done
New maintainer required.

Functionality

  • Carbon support in Mac OS X

State: Done
Reasoning: Cocoa support is available and Carbon cannot be used to create 64-bit applications. We'd like eventually to Deprecate and even Remove this functionality during the Qt 5 lifecycle, as this code is currently a maintenance burden (like Windows non-Unicode was).

  • HP-UX, AIX and Solaris support

State: Done
New maintainer required.

  • Old Qt solutions archive

State: Deprecated
Reasoning: old code, not maintained anymore.

  • Bearer Management inside Qt Mobility

State: Deprecated for now, will probably be Removed in Qt 5.
Reasoning: the copy of the code maintained in QtNetwork is the recommended interface.

  • Qt Multimedia inside Qt

State: for 4.8 it is Deprecated, in Qt 5 it is replaced by the Qt Multimedia Kit copy with the modularisation of Qt.

  • Phonon copy inside Qt

State: Done
Reasoning: a separate release of Phonon, with its own version numbers, is available and can be used instead; the copy inside Qt will not be updated further.

  • Qt WebKit copy inside Qt

State: Deprecated
Reasoning: a separate QtWebKit release, with its own version numbers, is
available and should be used instead with Qt 4.7 and 4.8, for those
looking for updates. In Qt 5, the separate release is reintegrated
through the Qt modularisation.

  • QWS (a.k.a. the current Qt for Embedded Linux)

State: Done for Qt 4.8
Reasoning: the new Lighthouse-based architecture is recommended for new features and new platforms.

  • Static builds of examples and demos

State: Removed
Reasoning: this is not maintained or checked and the Qt binary builds
are always dynamic. Static builds aren't required for reading the
source code and learning Qt, they are never deployed to devices.

  • Static builds on Mac, Windows and Embedded Linux

State: Done

  • Windows CE port

State: Done
New maintainer required.

  • WINSCW port

State: Done
Reasoning: old and buggy compiler, required only for Symbian simulator builds, should be replaced with a new technology once that is available.

Changing the list

The state of a given functionality or module is the choice of the maintainer of that code, who is the ultimate responsible for the quality. So the decision on whether new features and the extent of what other kinds of changes should be accepted or not is also the responsibility of this person. Therefore, to change the state, you have to either convince the current maintainer or become a maintainer yourself.

In that light, we have been discussing with current contributors to Qt and asking them whether they would like to volunteer for maintainership of anything. Digia has already volunteered find someone to maintain the AIX and Solaris ports and KDAB has done the same for Windows CE. Becoming a maintainer for something inside Qt shouldn't be too hard: it takes time and dedication, because it comes with a responsibility. (For that reason, we'd like people to prove that they can do it first, such as by maintaining a branch first)