15.08.2012, 20:47, "Thiago Macieira" <[email protected]>: > On quarta-feira, 15 de agosto de 2012 19.36.16, Konstantin Tokarev wrote: > >> 2. No QWS in Qt 5. >> >> Porting of QWS-based embedded application requires more effort for porting. >> For example, in Smartlabs we are using custom graphics plugins for hardware >> we are targeting, and our code depends heavily on QWS API. >> >> Also, AFAIU from [2] there's no point in using QPA on OpenGL-incapable >> hardware. Our target hardware is doesn't support OpenGL at all, or supports >> OpenGL 1.x only. > > That's completely bogus. QPA runs fine on OpenGL-incapable hardware. You seem > to be mixing messages here: > > - there's no point in running QWS in OpenGL-capable hardware, since QWS is > too tied to the raster engine. QPA was born out of a project to bring OpenGL > to QWS. > > - Qt Quick 2 requires OpenGL support.
From wiki: "QPA on Qt4.8 only makes sense on OpenGL Hardware! If you don’t have OpenGL HW there is absolutely no point in choosing Qt4.8-QPA over Qt4.8-QWS" Does Qt5-QPA on non-OpenGL hardware perform not worse than Qt4.8-QWS? > >> 3. Deprecated in Qt 5 / community supported / XCB-less platforms. >> >> On these platforms Qt 5 may be unavailable for certain period of time, or >> have lesser port quality, so it would be benefitial to have updated Qt 4 >> there. >> >> For example, it would allow to run latest and greatest Qt Creator for some >> time on Solaris, while not preventing Qt Creator from using Qt 5 features >> like QRegularExpression. > > I dispute that argument too. First, XCB: it's a very small library and, from > what I understand, it's got almost no external dependencies. It's a straight > protocol binding, independent of the X server or the X libs on that platform. > Therefore, no X11 system was abandoned or deprecated because of the XCB > change. > > Some other changes to X support happened along the way, like the dropping of > server-side font support. If anyone still depended on that, they should really > consider upgrading the system instead. > > As for support for the OS itself, I'm not sure we're doing ourselves a favour > by extending Qt 4 support. It might instead backfire: whatever little manpower > there is on those platforms will remain on Qt 4, instead of fixing issues on > Qt > 5. > > For example, for Solaris support, since I have yet to see any patches fixing > anything or even any reports of issues, I have to assume that either it's > working flawlessly or that there's no one left interested in it. > >> 4. QtWebKit 2.3 >> >> New release of QtWebKit (2.3), compatible with Qt 4 is planned, and it would >> be more logical to include it into Qt 4.9 then into new patch release of Qt >> 4.8. > > You need to build QtWebKit separately from Qt anyway if you want to enable > QtSensors and QtLocation support, which are out-of-tree. > >> Personally I'd like to port next features into Qt 4: > > I'll note you said "I'd like to port" :-) > >> * QJson* stuff > > Yes > >> * QMessageLogger and friends > > Unnecessary. These are just the groundwork for the full logging feature that > is yet to come. > >> * QRegularExpression and friends > > Yes. > >> * QStandardPaths > > It's nice that it's in QtCore, but side from a few new locations, > QDesktopServices should be plenty. > >> * New methods QtNetwork module and QSslCertificateExtension > > Yes. > >> * QLocalServer::listen(qintptr) > > Binary incompatible. The qintptr change requires > QAbstractSocket::socketDescriptor to return qintptr. > >> * New QtTest macros >> * Maybe something else > > * The compiler macros in qcompilerdetection.h. > * adding loadAcquire and storeRelease to QBasicAtomic (forward source > compatibility) > > I was looking at backporting some improvements today and stopped when both of > those were absent. Thank you for this information. -- Regards, Konstantin _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
