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.
> 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.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
