Qt Modules' Maturity Level: The list

Published Thursday May 12th, 2011
107 Comments on Qt Modules' Maturity Level: The list
Posted in News, Open Governance, Qt

Last week, I blogged about the framework of levels we’re proposing to use for Qt in the context of Open Governance and future development. I said then that we had also taken the time to look into what code we have in Qt and decide what level it should be in. Today, I’d like to share the list that was the result of that work.

First of all, please understand that this applies to future releases of Qt, most importantly Qt 4.8 and 5.0. Since we never add or remove features to existing and current release series, the framework doesn’t apply there, except as in what kind of bugfixes we might be accepting. For example, a bugfix for a corner case could potentially introduce regressions, so the community needs to take into account the quality level of the code and the ability to execute regression and release testing before accepting said commits. Moreover, it’s also possible to obtain differentiated support for past releases from other companies, especially from Digia. This is however outside the scope Open Governance.

Second, 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 QtDBus. 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, so I’ll be importing it into the Qt Developer Network to be edited and kept up-to-date. So 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.

Finally, 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”.

The list


  • ActiveQt
    Overall module state: Done
    New Maintainer Required
  • Phonon
    Overall module state: Done inside Qt, Maintained outside of Qt
    Reasoning: QtMultimediaKit 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.
  • Qt3Support
    Overall module state: Deprecated
    Reasoning: Qt3Support was provided as a porting layer from Qt 3, so the recommendation is to finish the port. Qt3Support will be Removed in Qt 5.
  • QtCore
    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.
  • QtDeclarative
    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.
  • QtGui
    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 functionality in X11 as modern systems use client-side fonts; 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 QtMultimediaKit.
    • 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.
  • QtNetwork
    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.
  • QtScript
    Overall module state: Active/Maintained 

    • QScriptEngineAgent and related classes
      State: Deprecated
      Reasoning: flawed design, being replaced by a better design.
  • QtSql
    Overall module state: Done
    New maintainer required.
  • QtSvg
    Overall module state: Deprecated
    New maintainer required
    Reasoning: SVG Full (as opposed to SVG Tiny) functionality available in QtWebKit, 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.
  • QtXml
    Overall module state: Done
    Reasoning: QXmlStreamReader and QXmlStreamWriter are recommended instead and are located in the QtCore module.
  • QtXmlPatterns
    Overall module state: Done
    New maintainer required.


  • 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 MultimediaKit 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

As I said before, this list should live in the Qt Developer Network wiki, where it will be updated as the states change. So how do they change?

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)

More discussions on this should begin with Open Governance and the Qt contributors Summit.

Do you like this? Share it
Share on LinkedInGoogle+Share on FacebookTweet about this on Twitter

Posted in News, Open Governance, Qt


Thiago Macieira says:

Let me just repeat in case someone forgets:

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”.

Stephen Chu says:

If QPicture is deprecated, why does it require a maintainer? And QPrintPreviewWidget uses it to render the preview, right?

If QtSvg is deprecated what method will be offered to render a SVN image into QImage without having to link against the whole QtWebKit? This is especially important on ( older ) mobile devices.

Felix says:

So you’re basically telling, qmake will not be fixed by you guys to generate Xcode projects for the current (4.x) and future Xcode versions? Is this some kind of forcing your own IDE onto the Mac developers? Please tell me you’re kidding!

@Thiago Thanks for the update. Apart from the latest list living in Qt Dev Network, how about Qt Assistant dynamically updating the state of each module/file and display it within the help. I feel Qt Assistant is more close to developers writing code – the state/reasoning displayed there itself would be more helpful and productive.

Aekold says:

For some packages it is said “a separate release is available and should be used instead with Qt 4.7 and 4.8” (in case of webkit). Will newer versions of WebKit still be included in .tar.gz archives of Qt releases or it should be downloaded and compiled separately too?

tewc says:

Overall module state: Deprecated
New Maintainer Required
Reasoning: Deal with Microsoft

Is deprecating QtSvg a good thing for KDE? We are using SVG rendering and writing in several KDE applications and as I know it works rather well as simple and fast SVG writer/renderer.

Thiago Macieira says:

@Davide: the reason why QtSvg is Deprecated, not just Done, is that QtSvg could have some problems following the SVG Tiny 1.2 specification closely (it probably does, if the complaints are any indication). If it were Done, fixing divergences to the spec would be required. We don’t want to have that effort, when a much more powerful SVG engine (implementing SVG Full) is available in QtWebKit.

Thiago Macieira says:

@Christian: for QtSvg, we really think you should use QtWebKit for rendering an SVG into a QImage.

@Felix: yes, we’re saying we’re not going to work on generating XCode projects, other than keep the current code compiling. We like Creator and we think you should give it a try. Still, note that qmake can generate Makefiles and you can always use Qt code in XCode without the qmake integration.

@Aekold: Qt 4.8 will probably contain an unchanged QtWebKit from Qt 4.7. But if you read yesterday’s blog, you’ll see the QtWebKit 2.2 release is coming. With Qt 5, there’s no “bundled copy”, it’s all modularised.

@tewc: very funny.

Have you any benchmark of QtSvg compared to QtWebKit about simple things rendering?

giowck says:

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

Please fix this! Very important feature….

Thiago Macieira says:

@giowck: yes, it’s a very important feature. But the design is flawed, it can’t be fixed. We need a new solution and we’re open for ideas. Please join us in discussing the possibilities for Qt 5 and how we can do this.

@Thiago: I understand but you should explore anyway performances issues with QtWebKit. SVG rendering is critical for the plasma shell (and for other apps).

Thiago Macieira says:

@Davide: That’s where the “New Maintainer Required” part comes into play. We really don’t have time or energy to work on everything, so we’re being very honest and saying what those things are, so others who do have the time, interest and/or energy do step up.

JarJarThomas says:

I realise i get really lost in between in qt.
I remember with qt3 it was rather simple. There was the trolltech website,
i could download it there, i had everything, i knew it worked together.

Now i am really lost. I tried to find out how to make better use of qt, especially qml and other more advanced stuff.
I find the gitourious website with some git repositories without documentation or whatelse.
I see dev website cant find anything about it,
i see here references to modules like qtquick 2.0 or qtmultimediakit without any additional informations.
A reference to a phonon outside of qt without any reference how to find it.

i may by a whiner but …. HEEELLLP !!!
I don’t want to spend half a year work just to get the stuff together.

Kid Pro Quo says:

I had already copied this list into the wiki. (http://developer.qt.nokia.com/wiki/Qt_Modules_Maturity_Level) before I noticed you said you were going to do it yourself. I hope this isn’t duplicating efforts.

Thiago Macieira says:

@Kid: Thanks! No, I hadn’t started doing this, so thanks for doing it before I had to.

André Pönitz says:

@JarJarThomas: Qt 3 development was mainly done behind closed doors. You got a release every now and then, without being able to neither notice nor influence (much) the intermediate stages. Development is more in the open nowadays, so you get exposed to more details of the process, like the labs.qt.nokia.com blogs about planned, ongoing or just finished work.

Quite a few people think this is a good thing. If you think otherwise, just don’t read the blogs and get the Qt SDK for download at http://qt.nokia.com/downloads. Whatever is “ready” gets bundled there, after some time.


Thiago, you said that you remove fileengines. Will be there any replacement? I’ve talked to Konstantin Ritt, however i didn’t get any useful information (only reasons why fileengines are removed). What can be used for creating virtual filesystems?
Also, you say that widgets status is done. Is this same for itemviews? In fact, there are a lot of bugs – QColumnView’s extended selection even not implemented (i.e. epmty function), QListView view crashes sometimes while dragging and so on. What about them?

QtSvg is invaluable for generating SVG images through QPainter. I don’t see how this can be ever be replaced by WebKit. I’m fine if you just keep QtSvg as a backend of QPainter (and/or even drop the module and integrate it in QtGui), but I wouldn’t suggest dropping the functionality.

Kelvie says:

Just wondering, are inter-module dependencies going to be looked at? Right now, to get a very basic QML program running, it depends on about many megabytes worth of libraries, including many of the libraries that are marked as “Done” here.

mikecomputing says:

About QNetworkManager and FTP support. It would be awesome to have SFTP support also.

Stefan Majewsky says:

@mikecomputing: You probably want KIO, and the Qt5-induced binary-incompatible break in KDE Platform is the perfect chance to make KIO accessible to the average Qt developer by modularizing kdelibs.

Shmerl says:

Does it mean that if I want to wire a graphical applications which manipulates SVG I’ll need to use QtWebKit for that? It sounds like an overkill.

@Kelvie: part of this effort is to split some of this up, into smaller chunks – like widgets being moved into a seperate widgets module instead of sitting in QtGui when they’re basically not being used.

But, strange as it may sound, a few larger libraries is actually more sensible than many smaller ones in a lot of ways. Symbol resolution (and thus load times) should be a lot quicker, etc.

aportale says:

Like many commenters, I, too, see a lot of value in QtSvg. As a renderer it is very fine (quirks can be worked around in the svg). The QSvgRenderer Api allows to render single svg elements and also to query their existence and bounding QRectFs. I am unsure whether raw QtWebKit can provide the same functionality, without injecting a lot of crazy JavaScript.

JRM says:

Is Qt Webkit able to handle the creation of complex SVG files or is it aimed as a viewer ?

Sekar says:

Is there a more fine grained list? For example, what happens to QRegExp or QCompleter? Classes not mentioned in this list are assumed to be maintained/supported?

muenalan says:

QtSvg: vote for stay !

..as long there is no straight way to have a WebKit QGraphicsItem in QGraphicsView. As aportale said, I do render single svg elements and query the qrectf’s.

Will Stokes says:

This all looks really good, except one big issue: deprecating QtSvg. Yikes! I use that to export vector graphics. I also export to rasterized formats, but exporting to a SVG VERY useful and it seems to work VERY well. I do a lot of complex plainting with warped text, painter paths, gradients, etc, and SVG seems to handle this all VERY well. I can’t believe this is being deprecated!

Felix says:

@Thiago: Thanks for making this clear, still hoping for a community solution…

cat says:

I hope QML will be Deprecated in Qt6.

Daniel says:

Another vote for keeping QtSvg, although for a different reason: QtWebKit is LGPL and therefore commercial customers can’t use it.

Thiago Macieira says:

@ABBAPOH: there’s no replacement for them. We think that a virtual filesystem layer underneath QFile was a bad idea. We currently have no VFS solution. We welcome suggestions on the subject.

ary says:

For me, too, the QtSvg deprecation is the item in this list I feel most uneasy about… (Especially regarding QSvgGenerator, for which I don’t see a viable alternative…)

Other than that, the list contains no real surprises on top of what was already announced in the previous blog posts…
All in all, it looks like Qt 5 under Open Governance will be pretty awesome.

Thiago Macieira says:

To everyone asking for QtSvg to remain: we are listening to you. No doubt that the module is important for a lot of people and many usecases.

But fact is that we simply don’t have anyone anymore with the expertise or interest. You may have noticed that it hardly gets any updates. There has been exactly one fix in 2011 and 8 in 2010, not counting compilation fixes. We simply cannot call that “Maintained”. That would be really “Done”, if it weren’t for what I said before about QtSvg having compliancy issues.

We may change your minds, sure, after reading all the pleas for the maintenance to pick up. But it’s far more likely that we won’t. So the best vote you can give is with your code. Start contributing to QtSvg.

ary says:

@Felix: Note that Qt doesn’t force you to use qmake. So another alternative would be to use, for example, cmake (which works very well with Qt applications and is able to generate Xcode project files as well).

Stopping qmake development, and leaving it at essentially XCode 2 compatibility (XCode 3 updates the project automatically) is a REAL issue for all of those using the native development environments. It harkens of the potential that Windows VS Studio might also be dropped in the future, whenever it is not convenient.
We’ve been a long suffering (due to lack of critical bug fixes and long term support of older architectures that our customers expect to be supported) commercial customer shipping product on both Windows and OSX. Due to OS integration issues and the application’s complexity, we cannot live without using the OS native development environments, Visual Studio and XCode. The Qt IDEs are not sufficient.
The fact that qmake is not being further developed is a real show stopper. Looking at other key areas with a label of “New/Active Maintainer Required” is also a concern.

It really shows to us that using this sort of environment might be ok for open source, academic, or hobby projects, but is not a reliable basis for a business with a large and growing customer base. We have invested more than 5 man years into Qt!

Are they going to be a right-off?

Harald Striepe.
CTO – Quantum Intech, Inc.

przemoc says:

I have a suggestion for future blog post (or many posts) in Qt Labs.

Not all developers using Qt are familiar with everything it provides (for obvious reasons). Thus while hearing early that some stuff will be deprecated is nice, e.g. as a hint to better not use it for new applications, it would be even better to read why this or that reached deprecated status by explaining problems within it (using maybe some real-word examples?), what are the unfixable design flaws in each case and why they happened at all (IOW why problems weren’t predicted when the class/interface was being introduced, how things have changed since then, etc.). Such post(s) would be very informative from technical viewpoint and interesting as a Qt4 failures testimony. After all nobody is perfect and there is nothing to be ashamed of here, because Qt is really a great piece of software backed by exceptionally good documentation and neat set of tools. It would be also really helpful in starting discussions about new interfaces superseding deprecated ones and without previously discovered hindrances.

Of course other Qt5-related technical posts (and benchmarks, as “again, Qt5 is three times more efficient in GUI department than Qt4”, and so on…) are highly welcomed to! I know you are already planning them, but just wanted to reassure you that there is a demand for them. Personally I find such posts more interesting than “we have another QtEllipticCurveCryptography for your pleasure” (actually some serious cryptography support would be nice; yes, I know there are lot of other libs for that, but still), YMMV. Obviously don’t stop introducing new features! 🙂

damian says:

I know qt doesn’t have infinite developers, but isn’t rendering a svg something REALLY important, in every sense, shouldn’t you at least force something(there are paid developers there) to mantain it and fix bugs while mentoring new contributors.
And when you say “deprecated” it usually means there’s a replacement which is better, or it’s broken and there’s no way to fix it.
from what I see QtSvg should be more in a state of “needs help” than deprecated, as I suppose a lot of people will find it neccesary.
And about using qtwebkit, is it light enough to replace qtsvg?, I mean what happes If I want to show svsg previews in a file manager, and I have to render a lot of little svg images, does this means I’d have to convert the whole file view to qtwebkit or use a lot of little qtwebkit instances?

Guido Seifert says:

Can’t say I like the idea to replace QtSvg with the webkit. I used QtSvg several times to render buttons and whole 100% scalable user interfaces. Keeping the svg in a QDomDocument and modifying its xml components directly, e.g. to change text or colours and finally rendering the modified image in a paintevent worked surprisingly well. Since QtSvg supports only a subset of svg, I did look into the webkit rendering. Yes, it is not too difficult to use it to render svgs. However, QtSvg can be used synchronously, which results in fairly easy, but not necessarily fast code. The webkit rendering is asynchronously, which requires a totally different much more complicated code structure and certainly isn’t faster. I cannot see the webkit as a replacement for QtSvg. At best it is a valuable complementing alternative, but in the worst case it is just an excuse not to maintain QtSvg anymore.

David B says:

Does the modularization of QT mean that each module will be on its own release schedule, I would hope not, but then QtWebKit seems to have gotten on its own schedule. One of the strengths of QT is that every platform and every technology was always in sync. It would really be a extraordinary burden on developers to have each module be on its own release.

I am sure you touched on it before but what about QtMobility, is this going to stay a step child, or can we expect to see it somehow reworked into the fabric of QT modules. I hope the latter, even if it means cherry picking what you want from QtMobility and throwing the rest away.

I don’t think QMainWindow should be considered done, (QtWidgets marked as done) because QToolbars and QDockWindows, for which I lump under QMainWindow, both need modernization and new features (Dock Windows are really ugly when floating).

Finally, what about Qt’s MVC, you did not mentioned it (or did you). It could use some love as well, especially QHeaderView.

I really appreciate your openness concerning Qt5. Please keep the communication open on this forum, As wonderful as the Open Governance Idea is, your going to get more real word feed back in this forum.

> QtSvg
> Overall module state: Deprecated
It’s one of the best parts of Qt. Don’t do it:
1) Not all of the Qt users use QtWebKit (especially those who uses static builds).
2) What about scalable UI that uses QtSvg (and SVG-to-QIcon plugin)? What about amazing “Embedded widgets demo”?
3) That is one the most powerful parts of Qt (among many others) that makes Qt-based applications standing out at the Windows OS family when user uses “custom DPI” – compare QtSvg-based icons (at buttons, menus, toolbars etc) and MS Office icons with “custom DPI” like “120-200%”.
4) Sometimes QtWebKit is too fat.
I would be very pleased to see QtSvg as “Done” or (better) “Maintained (sharing engines with QtWebKit but doesn’t need it to be included in Qt build)”.

Per says:

Not many surprises. I would also like to ask for QtSvg to remain. Too useful despite its flaws. If the virtual filesystem is removed, then I hope that all classes that now consume file data, like QSettings, find another way to circumvent the file system and read a memory buffer instead. Otherwise some of us will be royally screwed, since our data may not reside in a conventional filesystem and the virtual filesystem has been a way to get Qt to work nonetheless. Even though the virtual filesystem has been a royal PITA to work with.

Where can I find some information about the problems that QFileSystemWatcher has? Might be interesting to look into.

@Guido Seifert: If you are currently using SVG to make scalable UIs then this would be the perfect time to move over to using QUICK I guess.

Guido Seifert says:

Matt, I did. A good part I did with SVG I do now with QML. Though…. I also use SVG in QML as image sources. Scales better.

@Matt Williams: If you are currently using SVG to make scalable UIs then this would be the perfect time to move over to using QUICK I guess.
I don’t need Qt Quick in some projects at all. It’s unnecessary part sometimes – for example, when I need only SVG images (and icons and backgrounds) in simple app using only widgets shipped with QtGui.
It’s not always good idea to replace C++-based UI code with JavaScript.

@Guido Seifert: I also use SVG in QML as image sources. Scales better.

Digia is very much interested in supporting the modules and platforms that are used by Qt Commercial customers. We have already discussed with Nokia and stated that Digia will take care of Solaris and AIX also in the future to have all the most important platforms supported.

In addition Digia will continue to support the existing platforms longer than before to ensure that the investments done to Qt Commercial are secured, even if you can not yet move to a new version.

If you want to have some of those ‘to be deprecated’ features to be carried onwards to version 4.8 by Digia, please make a Feature Request via the Qt Commercial Customer Portal at http://qt.digia.com/customerportal. We can not take them all, but are ready to invest into those areas that are most needed.

Tuukka Turunen
Director, Qt Commercial R&D
Digia Plc

Guido Seifert says:

Tuukka Turunen, not all of us are commercial customers. For hobby developers or small startups the prices are a little……steep. 😉

Johan Thelin says:

Two comments:

#1 QtSvg seems silly to depricate. Rendering SVGs without carrying the huge overhead of webkit still is important
#2 Widgets are far from done. They need to be upgraded as new OS:es and element appears.

muenalan says:

@Thiago, QtSvg

Show us the code ! You must have gotten something wrong: WebKit and QtSvg are very different. QtSvg has a Qt-style API, clean Qt documentation, works for small things fast/perfectly. WebKit is overkill. Where is the low-level API that does things like QtSvg ? SVG standard mightiness does not count for our scope.

Where is the community process, eh ? So many votes here for stay. How many tickets/headache do you have with it ? Its stable.

Ok, “deprecated” is just wastebasket. Call it “community-supported” or whatever and leave it as a module.

Thiago Macieira says:

@muenalan: the community process is here. Vote with your code. Otherwise, we’re not removing it. But we’re not going to fix SVG-compliancy issues either.

Alexis Menard says:

You have interests in QtSvg? Help to maintain or join the effort for the module to use WebKit SVG renderer at some point.

Anton says:

QNetwork maintained… [edited by moderator]
an interface for SSL_CTX_add_extra_chain_cert (load chain/intermediate certificates) is waiting in jira for years.

Markus Goetz says:

@Anton: Do you mean http://bugreports.qt.nokia.com/browse/QTBUG-13281 ? This is only a P3 bug. Vote for it or supply a merge request 🙂

muenalan says:

@thiago, @alexis, QtSvg

Will stop lamenting here. But understand the delicate importance of the label. A “deprecated” label is a “dead end” sign for all. QtSvg is the basis of many developers (see commments) to keep their code/business going. They’ll contribute + argue, dont worry, because its important. You want WebKit to thrive, say it; then real arguments dont count.

To play the card of “shut up and code” mentality leads always nowhere. Show us that you care for us, we’ll code.

sam says:

Qt Rocks,Android rolls.

damian says:

@muenalan +1
Please don’t say deprecated, because it means: “To mark (a component of a software standard) as obsolete to warn against its use in the future so that it may be phased out.” so you are actually saying “it will die”.
Usually when developers say “deprecated” it means there is a better alternative in every usecase, and with webkit this is not true.
If instead you just say,” we don’t have the power or willingness to improve it and fix it, so we need help from the community or we’ll have to degrade and lost real useful functionality in our code, help is needed.”, maybe summarizing it as “Community mantained” or “In need of help” would be better.
Anyway Thanks for making this proccess open so we can help you mantaining stuff, sorry If it seems I’m being rude, I’m only trying to help.

MM says:

Are you kiding me? So many things deprecated… Should we learn the Qt again from very beginning? And I hate something like QtMultimediaKit, don’t put every thing into one package(DLL), this will make your lib fat!

Javi Moya says:

why Android appears in the QT5 whitepaper as a focused platform? (not exactly… but appears in a diagram with Windows, Linux, Mac and Symbian)
is the BogDan Vatra’s port officially supported? or what?

Sadly… official support from Nokia to Android it would be my only motivation to learn QML…


The maturity level list just confirms what everyone knows since 4.6…. that Nokia is not going to support desktop anymore.
“Disruptive technology”

sorry for my poor english

André says:

@Harald Striepe: I have to admit I don’t follow your reasoning. You insist on using two different IDEs (which is fine), both completely out of qmake’s control and used qmake to bridge the gap between the two IDE’s native, incompatible build systems (which is already a bit of a stretch). Anyway. Assuming you would not use qmake for your project you would use Visual Studio on Windows and XCode on Mac and maintain both Visual Studio project files and XCode project files in parallel. Now with qmake coming into the picture, there is nothing that stops you from using exactly the same approach. So how does whatever qmake does or does not puts you in a worse position that you would have without using it? Is the problem that at some point of time it happened to work for you, but now that you updated one of your chosen IDEs (XCode) it does not work anymore with the same, unchanged setup on the qmake side? And therefore qmake (or the even less related Qt) is to be blamed?

Stefan says:

How about Qt5 on Android?

Stefan: Qt 5 is open. This means that, in theory, there is nothing stopping the Qt on Android folks from working in mainstream Qt, putting their efforts into the same tree everyone else is using.

This doesn’t necessarily mean that Nokia engineers (which is what this blog is populated by) will be working on that port, at least, on their paid time 🙂

Jason says:

@Thiago: Does it mean that we don’t have a class named ‘QSvg’ any more in QT5?
And people who need to paint a SVG image have to load the whole Qtwebkit lib?

vladest says:

Very sad, that such perfect C++ framework becomes another platform running on top of Java-whatever engine. QML is not such rich lang as C++ and its become very messy quite quickly in case of big project.
Please, dont deprecate C++ developers who dont likes script languages

Thiago Macieira says:

@vladest: please don’t blow this out of proportions. No one said C++ is deprecated, so don’t make baseless accusations. We clarified that bringing QML to first-class citizen does not mean C++ is second-class. (see Lars’s second blog)

Thiago Macieira says:

@Jason: to be honest, we’d like to remove it. But given the reaction, we probably won’t. But we won’t do much more than ensure it compiles.

Is there anyone in this 67-comment thread that wants to do some SVG work? I can’t believe that with so many people who want it to happen, no one wants to make it happen.

tbscope says:


These people are users, not maintainers.
They want to use the api, not maintain it.

It is one thing opening up your repository and ask for contributions. But it’s an entire other thing to demand from users to start maintaining Qt.

I can understand that for Qt there’s currently a shortage of manpower. But the solutions mentioned are not what most people would expect. I would have loved to see Qt going back to the basics. Just a simple set of multiplatform classes like it started with. The complexity can than grow little by little. Now only the most complex classes will be maintained by Qt developers (which in retrospect might actually be a good thing too). But, even the more easy classes to get into are still a huge problem for most of the Qt users to get a grip with, let alone know the design and history behind them. What if I change a line of code in some smaller class, how does this play well with the rest of the code? Will the modularisation solve most of these problems? Will there be a significant code review being done by the official Qt developers? etc…

anon says:


Quite honestly, that’s their problem if they are not maintainers.

The way I see it, there are 2 options…Qt could leave everyone in the dark and “pretend” they are working on these sections, and act like they are being maintained, leaving everyone that Warm Fuzzy Feeling that Corporation Secrecy gives, for some strange reason. Or they could be honest about it and be straightforward in requesting for help in certain areas.

Also, new projects like QML are very important in securing the future of Qt, and ensuring that it is being innovative. If they had stuck to the Regular, “Simple Classes”, then you can expect 0 innovation.

Honestly, everybody is whining and I find this incredibly unnerving. Be patient, and most importantly “DON’T PANIC!”. Contributors and maintainers will step up. It’s especially important for everyone to be patient and understanding in this transitional period, as it is quite a leap for Qt.

tbscope says:


I think that’s a little bit disrespectful to the current users. It’s like saying “Well, here it is. You want to have improvements, do it yourself and get bend, we only want to play with the cool stuff and let the rest for someone else”.

You must understand that there is a world of difference between a simple Qt user (like me) who only uses Qt for some hobby projects, a professional Qt user and a Nokia developer working on the Qt api and tools.

The first one, the hobby programmer, mostly doesn’t have the knowledge to even understand half of the Qt designs.
The second one, the paid programmer, will only have the time to work on their projects. This will make Qt less attractive.
And the third category, the Nokia programmer, will only have time to work on what they think is a viable future.

I would love to improve Qt, I always wanted to too from the start.
But I don’t live in a fantasy world. I do not get paid to write code for Qt, nor do I have the time, nor do I have the technical knowledge. And I think most people can find themselves in one or two of these conditions.

The strength from open source is not the hobby programmer who puts a little bit of time into a project. It helps, but that’s not where the bulk of the progress comes from. The most successful open source projects have corporate backing, which means that there is money and management involved. This is even more important the bigger a project is. And Qt is a big project with a huge code base.

Huge projects stand or fall with management and money. You need regular meetings, technical education, planning, etc… to maintain a certain quality in project management.

Qt will eventually attract willful hobby developers, no doubt. But their isolation and lack in abilities will not make up the loss of dedicated engineers.

Ibakken says:

@tbscope: You have never worked in a big company, nor actively contributed to an Open Source project, right?

If you had been with a big company you would have noticed that the successful projects are typically not the ones with regular meetings with powerpoint presentations, detailed process planning and an abundance of resources.

If you had contributed to an Open Source project you would have noticed that there are highly skilled people around, and willing to “just do it.”

If you personally don’t have the time or the technical knowledge to contribute, and would not do it anyway unless you get paid, that’s absolutely not a problem. If you believe no-one else will either, you are just wrong.

Mark says:

For all QtSVG pleas.. here is an article (from a few years back) that explinas the SVG through Webkit stuff : http://labs.qt.nokia.com/2008/08/06/webkit-based-svg-rasterizer/

As for having Webkit as a requirement for SVG is way to much overhead! My vote would be to make a “QSvgCore” that has the full SVG implementation and use that for webkit and “other” qt development without the requirement for webkit. As for the source of the Webkit SVG parts.. that is here: http://trac.webkit.org/browser/trunk/Source/WebCore/svg

So, please do keep SVG separate from Webkit! I’m surprised noone from KDE (like Aaron Seigo) hasn’t replied on this yet since this seems like something KDE will certainly notice.

Javi Moya says:

name high quality extension libraries for QT developed in all those years outside Trolltech/Nokia…
[qwt? libqxt? I don’t think they are “high quality”…. There are not even any good chart classes for Qt…]
name active blogs/forums about Qt…
[qt-centre…. many questions… very few answers…]
[Qt-interest Mailing List…. the same… many questions… and.. just Thiago….]

just open your eyes…
Qt has many hobby programmers… but not very high skilled people to think that they are going to get maintainers…

Nokia is being honest now (with this maturity level list)… because is too obvious that they are abandoning desktop development since 4.6… and they are trying to create a “disruptive” technology for a future platform…

do you think that Nokia guys behind Qt has freely decide to bet all to QML???
Nokia bosses want that they must put all their efforts in that area… and left behind everything else.

Qt 5 real desktop apps are going to performs worst than Qt 4 ones… because of all the QML overhead….

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.

I learned Qt Designer in a few hours… It’s powerful, fast and easy to use… and looks great and consistent. I love it.
Qt Quick Designer is much more complicated, slower, confusing, much less polished, and looks horrible… I hate it…. Today has no real usage… I don’t know how to create a complex desktop UI in Qt Quick Designer…. and not seems that they are going to make it easier soon.
Qt guys… that are extreme high skilled people… and the creators of this thechnology… has not been capable of doing a nice desktop app in qml !! how are they promising us that this is the future????

name a nice complex desktop app created with QML.

Thiago Macieira says:

> do you think that Nokia guys behind Qt has freely decide to bet all to QML???
> no.
> Nokia bosses want that they must put all their efforts in that area… and left behind everything else.

Just. Plain. Wrong. It was Qt developers who believed in the technology and pushed it to be adopted company-wide before Nokia had bet on it. It was Qt developers who decided that this is the way to go because we believe in the potential.

As for desktop, we’ve said time and again we know it’s not ready. Let me repeat once again: Qt Quick is not ready for the desktop. But we want to make it ready. And more performant than Qt 4.

So stop the accusations. You’re not contributing.

cat says:

> So stop the accusations. You’re not contributing.
Is it worth contributing?

Thiago Macieira says:

@cat: instead of answering that (you know what my answer will be), I have a question for you: why do you think it wouldn’t be worth it? What can we do to make it worth it?

muenalan says:


Lets conclude with a Slashdot’tian lession/post: There is always a general feedback loop from users (app writers) and creators of a supporting framework proper. Dont tunnel vision on Qt GIT itself. Deprecate a wide-used part of Qt and see what eg at http://www.qt-(apps|prop).org dies with Qt5 (and imagine “to-be-release code” on people harddrives) . They’ll probably not compile and hybernate forever; until you provide a easy update/replacement path. Thats why legacy code is kept. That where damian’s post pitches in. We dont say, never deprecate, BUT say: do it wisely.

Users, and real-world uses, are the benchmark for Qt’s relevance, and thats the ultimate basis of your work/job. You shoot in you own foot when you “kill” widely used/liked code *based* on your framework. Long list of comments means *buzz* danger people care, so act wisely. These are the sensitive pool of users yet to become maintainers, supporters, talk positive at work, drive companies to pay for products etc.

When your boss taps your shoulder and benchmarks Qt’s importance to the world, you’ll surely google for Qt users and proudly show off the active (compiling) user apps of you framework; say at qt-apps etc. Keep them compiling..


Guido Seifert says:

I also think you should not expect too many contributions. There most likely will be valuable input from companies like basysKom, KDAB, and of course from Digia. Companies like these are the only ones I believe are capable to be the maintainer of a whole module. There certainly will be contributors, who provide patches to improve performance or remove bugs, but hardly implement new features, which really bring Qt forward. There simply is only so much a person can do after work.

But then, I might be wrong. I would not complain if I were. 🙂

tbscope says:


“@tbscope: You have never worked in a big company, nor actively contributed to an Open Source project, right?”

I’m a project manager in a very large company (+30000) and manage multi million dollar projects. I can tell you if you don’t regularly meet (with or without “powerpoint”), you end in chaos.
Also, I’m a programmer since I was 5 years old and have actively developed open source applications.

I know everything about project management and a great deal of open source development.
Projects like Qt, KDE, Open Office, Linux, … could never have happened without corporate backing. There are a few very nice exceptions though.

Thiago Macieira says:

@muenalan: No one said we’re not listening. We’re listening to all suggestions and requests.

But this post here was where help is required, in addition to what we think we should dedicate our resources to. Telling us how much you need something doesn’t change the fact that help is required.

@tbscope: KDE is mostly done without corporate backing. Having people dedicated 100% is certainly helpful, but it neither guarantee of success nor implicitly necessary for it.

@Guido: don’t get me wrong, but I seriously hope you’re mistaken.

Guido Seifert says:

Thiago, I don’t get you wrong. I hope the same. 🙁

Peter Kümmel says:

There is always the promise to open Qt but the traffic on opengov@qt-labs.org is low and also on qt5-feedback@qt.nokia.com not much happens. But even a small active open source project has more traffic. All desicions and work still seems to be done in the background.
Is this really that different to Trolltech times, where you are only asking a bit, then close the door, and come back with a finished product.

Why could you not simply discuss some things on a open mailing list, real technica problems, daily work questions, desicsions. For instance, what are the options for the qmake replacement, where’s the list of ideas, what is a definite no-go, who is working on it, what is the shedule, where is the repository? If you can’t provide these things then please don’t call it open.

Thiago Macieira says:

Hi Peter

We’re not there. We can’t have our code discussions on a mailing list yet. But I’m working hard so it changes. So meanwhile, we are operating as we always have — except the code is open, real-time updated (unlike Trolltech times).

As for the mailing lists, the opengov one was to discuss the open governance itself, so its goal is accomplished. The qt5-feedback mailing list had 155 emails in less than a week, its first week. In the same period, kde-core-devel had 92 emails. So I call that pretty good.

Peter Kümmel says:

Yes, it’s slower than expected. Some small Trolls have to shove the dinosaur Nokia. 😉
But what can we do then as non-Trolls other than writing wish-lists?

Rick Stockton (AKA "rickst29") says:

WRT posts #82 thru 85:

I am already present on mailto:qt5-feedback@qt.nokia.com (where Thiago has given me some GREAT coaching about Qt5 input). But this blog post, and many good comments which have been attached, provoke me to suggest an idea:

Start creating more “focused” Mailing Lists. You compared qt5-feedback with kde-core-devel, but several other KDE lists have high traffic as well(e.g., kde-plasma-devel). Why not do as KDE does? A project as large as Qt5 could perhaps benefit from a larger number of more “focused” mailing lists. Plasma’s separate Dev-ML keeps a lot of things in that area (Plasmoids, Tools, Planning, AND code) separate from “Core”, and separate from KWin as well. Many specific issues touch multiple lists, and we just CC as appropriate. But focused lists are nice. (Perhaps I’m not using the Blogs as well as I could. But, if such lists existed, I’d prefer to listen in on a couple of more “specific” qt5 lists instead. They don’t have to be named “-devel”, and a lot of lists with very similar titles have different usage. (I don’t ENTIRELY like that.) kde-plasma-devel, for example, is very “chatty”, while xorg.devel is almost entirely code-driven.

The comments already posted here imply that a “qt5-svg-devel”, or perhaps a “qt5-svg-discuss” list, could see a lot of forward-moving, non-whiner action. I’m guessing that you would need only a volunteer to moderate and manage the list members. Such lists allow persons with interest in a specific area to listen quietly, or listen and float ideas with just a toe in the Lake — without, or before, jumping all the way in.

It’s a lot less scary to be a “mailing list maintainer” than it is to be the maintainer of the project. “Give us your code, volunteer to maintain the project” frightens away people who might become excellent contributors in the future, and perhaps even participants in a project management team, if you didn’t require an “ALL-IN” commitment up front.

But unlike some others, I am not, and have never been, a Project Manager 😉 Do feel free to respond with “Rick, you haven’t got a clue about this, please be quiet”. I’m good at following such directions without resentment. BTW, I’ve got my Wayland and Lighthouse clones, I’m starting to poke at working copies. Thanks Again!

Peter, are you willing to moderate a “qt5-make-discuss” list? (I’m definitely NOT competent in that area.) And SVG people- moderating the list is just a small commitment, and Thiago definitely doesn’t ANY room on his plate for such a thing. How about it?

If we want “more open communication”, let’s assist in establishing it.

“Reasoning: QtMultimediaKit recommended instead; development of Phonon continues and is maintained outside of Qt, by the KDE community.”

What advantages does qtmm have over Phonon?

Minjung Shin says:

@David B
Mobility APIs are likely to become smaller modules and added to Qt as any other modules from Qt 5. I cannot say exactly whether how many Mobility APIs, if not all, will be included in Qt 5.
In terms of module state, I would say, the current APIs (1.2) are in Done state in the current product structure. I.e. Add-on. Once they migrate to Qt 5 with further modularization, each module is in active state.

Thiago Macieira says:

@Rick: unfortunately, those are the kinds of mailing lists that we can’t have yet. We can talk about our ideas, what we’d like to do, but we can’t have the actual code being discussed in the mailing lists just yet. That’s part of Open Governance and will come.

Another thing that has been bothering me in these comments is that some people don’t trust in the Open Source process. It has been proven time and again that it works, whether it is a loose community with mostly hobbyists working part-time or whether it has a strong funding by companies. For Qt, I expect to be both: we have a very, very large community of talented developers using Qt that could easily contribute. It’s not that hard. Just now on qt-interest, someone wanted to add support for leap seconds and I told them that Windows support would be necessary; the result was that another person volunteered to help and a third volunteered more information.

And we’ll have a couple of big names pushing development. Did no one read the blog until the end, where it said Digia and KDAB were volunteering to find someone to maintain some ports of Qt? Do you think they’ll stop at those? I also know from talking to other companies such as Intel and ICS that they are going to participate in some form or another too.

So it’s a little bit of both and I’ve been pushing people to step up and contribute, even though companies will likely take most of the burden.

qtnext says:

What’s about a forum where we can talk of starting Qt contributing … I explain … I think we are a lot ready to contribute, and what you announce smell good (I was one of the people very worry about the Qt future …) … it seems there is a Qt future 🙂
Is there a way to have a forum where everyone can propose to start contribute in a Qt Labs spirit way : I have not a lot of time, but if we can regroup work with people that add interest to add a new features to qt lib and have not ,like me, a lot of time … we can perhaps do something … for example I dream to have the availabity to render Qt gui directly in my ogre3D application (perhaps it’s possible to imagine a LightHouse ogre Backend ? ) I have no time to do that alone, but if other people have interested in it … and for that we can imagine to have a Qt mentor that can help … not to code … but help to do that …. you add shader to scenegraph, an easy contributing project can be to add a lot of ready to use effects to qml ….

@Thiago I am not sure that “send patches” is the correct answer for a feature that it looks so important for users (like this thread shows), like QtSvg. I thought that the idea was that Nokia would keep on developing Qt based on the community feedback (in addition to having its own agenda), while if I had to judge your answers it would seem that you are simply stating what Nokia has decided to do, independently from users feedbacks. Is that a goal of Open Governance, that Nokia will totally focus on its own agenda, giving the community the task to develop and maintain features that Nokia doesn’t need for its business?

Moreover, it’s not like contributing to unmaintained parts of Qt is easy right now; we have experience of patches are left floating for months/years in Gitorious or task tracker specifically *because* there is no maintainer.

Thiago Macieira says:

Nokia will continue to pay attention to what the community requests. The feedback in this thread has been great.

But “pay attention” doesn’t mean we’ll do every little thing that the community requests. It’s a matter of priorities: some things are more important than others. Some others we have no interest or skills left. That’s the case with QtSvg. No matter how often people ask, it doesn’t change the fact that we have no interest or skill (or both) in continuing to develop this module any longer and it’s not a priority for us.

What’s more, when we think we are right about something, we will push ahead and damn the torpedoes. That’s the case with QML and Qt Quick.

DavidB says:

While companies like Digia and KDAB have been and no-doubt continue to be great supporters and contributors to Qt, are they enough for Qt’s new direction with an Open Source Governance ?. Can other supporters be found in the likes of RedHat or OpenSuse, Canonical, Google, or even IBM to name a few. What are their reluctance to join, perhaps the Qt Governance can address their concerns with minimal effort. With the state of Oracle’s stewardship of Java now under scrutiny, it just might be a win-win situation for the Qt community and those companies mentioned above to champion around a first class App Framework. Hell come to think of it, why not invite Libre Office, Mozilla, and Apache to our open party. I just think you need a few more long poles in the tent.

Thiago Macieira says:

@David: this is a question best asked to those companies. They’ll alone tell what they’d like to see and how much they’d like to participate.

OpenSUSE people (through Novell) and Canonical have been warming up to using Qt and we have had many interesting discussions with them in the past months. We have received contributions from them.

Adrian Carpenter says:

“What’s more, when we think we are right about something, we will push ahead and damn the torpedoes. That’s the case with QML and Qt Quick.”

Look where that attitude with Symbian got you (Nokia).

Unless you can prove that QML/Qt Quick can be used for more than “toy demos” then the same questions will keep being asked.

Show me a CAD application or something similarly real world and maybe you’ll change my mind.

Peter Kümmel says:

DavidB: “Can other supporters be found in the likes of RedHat or OpenSuse, Canonical, Google, or even IBM to name a few.”

I have the impression “big business” avoids Qt, they prefer gtk and C, and for object-orientation Java or C# is used, especially in US. Even Nokia doesn’t trust Qt, so why should others?

Is there on big commercial project where Qt is essential in the software stack, like gtk in Redhats desktop, or Java in IBM’s business?

Thiago Macieira says:

@Peter: there are a couple of VERY big businesses supporting Qt, including in the US. Even Nokia continues to trust Qt. So your assertion is completely false.

Qt at is the centre of MeeGo, which continues to live on. Intel is pretty happy about Qt. It’s also in the centre of Autodesk Maya and Autodesk is also pretty happy.

DavidB says:

Peter Kümmel :I have the impression “big business” avoids Qt, they prefer gtk and C, and for object-orientation Java or C# is used, especially in US. Even Nokia doesn’t trust Qt, so why should others?

I don’t think this is true. a lot of business do depend on Qt, albeit mostly for internal uses. animated film producers , oil companies, ECAD, and financial companies are heavily invested into Qt. I suppose because thy need cross platform support and Java just fails from a performance reason (all the sectors mentioned above producing code that is CPU and Graphics intensive).

Thiago. I think you miss my point. Somebody high on the Qt org chart should be extending the invite to the RedHats and IBMs. I mean if you want a guest to come to your party you don’t sit around and wait for them to ask you if they can be invited. Whats the worst that could happen they say no, and maybe give some real world criticism as why they are not interested. Who knows by asking they just might prove themselves to be receptive. I just don’t think the Open Governance board is going to be able to get enough traction without a few enterprise companies involved. They need a 900 lb gorilla, or a few 400 lb ones. Five 50 pound gorillas just won’t cut it

Peter Kümmel says:

@Thiago: I know there is big support for Qt also in US. What I wanna say is that there is no big business which heavily relys on Qt. It’s always optional, a nice to have. Assume Google loses against Oracle in the patent stuff then they have a problem because Android relys on Java. Or Microsoft relys on Windows Phone on the phone market. Apple phones or nothing without their iOS. All “enterprise” software is done in Java. So the question was, where is Qt such big in business?

MeeGo is still a experiment, it’s not essential to Intl, or do they “drive” their CPUs with MeeGo? Maybe Autodesk is a example for what I’ve ask for.

Thiago Macieira says:

@David: you do realise we have several people working full-time on making contact with the industry and big players, right? And it’s not just talk: when our key accounts people come, they come with a plan in mind and they’re there to help. We also have people who are dedicated to that: helping companies get started with Qt. And I’m not talking about the commercial business: this is just strategic partnerships.

If those companies aren’t in the roster already, it’s because they don’t want to be. It will take some more time to convince them to join up or solve a problem of theirs that we aren’t yet solving.

przemoc says:

@Peter: Qt 4 is also a framework of choice for developing internal tools in many companies. DreamWorks is nice example. And there are more, so telling that “big business” avoids Qt sounds like FUD, because the opposite is arguable.

Now even Microsoft uses Qt, you know, Skype. [ I wouldn’t be surprised if they would start rewriting it in .Net and making it integral part of Windows 8/9. 🙂 ]

@Thiago: What about my proposal to describe problems and shortcomings of Qt classes marked as deprecated and to-be-removed, thus requiring better superseding implementations to preserve features provided by them? Reading such post-mortem analyses would definitely help developers interested in contributing to Qt to pick up the threads of these apparently not that successful parts as the rest of Qt framework.

@Thiago: QtSvg is really “must have” feature to support scalable graphics (for UI).
All Qt-users (whom I know) use this module and like it very much.
I don’t know another good C++ UI-library that has such support of SVG (for example, SVG-to-icon).
Repeating myself:
> 1) Not all of the Qt users use QtWebKit (especially those who uses static builds).
> 2) What about scalable UI that uses QtSvg (and SVG-to-QIcon plugin)?
> What about amazing “Embedded widgets demo”?
> 3) That is one the most powerful parts of Qt (among many others)
> that makes Qt-based applications standing out at the Windows OS family
> when user uses “custom DPI” – compare QtSvg-based icons
> (at buttons, menus, toolbars etc) and MS Office icons with
> “custom DPI” like “120-200%”.
> 4) Sometimes QtWebKit is too fat.
It’s a pity to hear “deprecated”. Couldn’t Trolls go the way like “QtSvg shares engine with QtWebKit but doesn’t need QtWebKit to be included in Qt build”?

Peter Kümmel says:

@przemoc: actually I don’t wanna reply on this subject any more, but FUD is not what I have done. Sure, Qt is used by many companies but it is used like STL, boost, GCC or Visual Studio, so somehow it is really needed. But no big business heavily relies on Qt, also Nokia prefers a other product (maybe not because of Qt only).

Thiago Macieira says:

@Marat: All Qt users I know who use QtSvg complain about it and have considered other engines.

1) fewer and far between don’t use QtWebKit

2 and 3) scalable UI doesn’t require SVG. It just needs to scale. Demos just need to be rewritten with newer technology. For icons, you don’t need to rasterise SVG all the time — you can just supply different resolutions, like KDE does. And you should cache the result of the rasterisation anyway, so using a slow/far engine is not a problem.

4) you do realise that the SVG support is half of WebKit, right? Not to mention scripting support. Sharing the engine means linking to QtWebKit anyway, so you may as well do it yourself.

The SVG specification is large, done by committee and no single implementation implements all of it — or even equally. QtSvg tried to restrict itself to SVG Tiny 1.2, so we had an achievable goal with a small codebase. Now, the problem is finding a designing program that allows you to select which SVG version and spec to target. When they save SVG, they save using whatever they want and QtSvg won’t load it properly.

Anyway, summary is:
a) QtSvg is not getting removed; so stop tearing your hair out.
b) we’re not going to work on it anymore, it will just stay as-is;
c) if you have problems with its SVG support, first check if your source is compliant to SVG Tiny 1.2; if it’s not, use QtWebKit.

muenalan says:

@marat: +1
@thiago: +3 for your sensible summary (post 104)

Qt Inkscape just works so nice, whatever SVG level. Hail Qt(Svg) !

@Thiago Macieira:
This is your best answer (post 104). It clears more then all others.
May be it will be better to mark QtSvg as “Done”. I know – you don’t want to make bugfixes for QtSvg, but it is so handy tool that may be it deserves an exception?

Inkscape is the main tool for the creation of SVG that will be used in Qt-based program (I fought everybody knows that).

JubiluM says:

Hello Thiago and others.

I didn’t notice that there was an entry for Qt Assistant and/or the relating Qt-Help – system maturity. Now there was obviously a silent attempt to remove Assistant, but due to developer request(s) it was plugged back on. Thanks for that, it is superior viewing documentation compared to any ms-help or similar….or the integrated viewer in the QtCreator.

But, a question that I am more concerned about is that now that we’ve switched in our online documentation to use qt-help systems, can we rely that it works in the future (we’ve used hours to learn it and to make scripts that build the documentation to qtdoc-format)? Can we be sure that we can provide the Assistant as a viewer?

Thanks in advance!

Commenting closed.

Get started today with Qt Download now