[Development] Proposal: Qt 4.9 release

[Konstantin Tokarev]

15.08.2012, 20:47, "Thiago Macieira" <thiago.macieira at intel.com>:
> 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