[Development] Qt Platform Extras

Friedemann Kleint Friedemann.Kleint at digia.com
Fri Mar 1 11:22:22 CET 2013


 >I suppose it would not be a detriment. Where do you draw the line? 
Which platforms, what functions and types? Here are some candidate types 
for constructors and conversion operators...

The thing to keep in mind is basically that the decision to remove the 
pixmap conversion functions was mainly motivated by the situation on 
Linux. With Qt 5, it is possible to run executables by the same build of 
Qt with different platform plugins (XCB/X11 or Wayland, for example). 
QtGui no longer links against libX11/libXCB and thus for example 
QPixmap::x11PictureHandle() can no longer be provided within #ifdefs in 
Qt 5.

The situation on Mac and Windows is different, though, in that there is 
basically only one platform plugin (running Windows/Mac with Wayland is 
a slightly theoretical possibility). QtGui already links against the 
libraries that provide the image conversion functions and it is easily 
possible to provide the image conversion functions within #ifdef Q_OS_XX.

The image conversion functions are now in the platform extras, and the 
question is whether to bring them back and in which way. Pros are 
customer convenience; cons are basically #ifdef clutter and hacks.

I personally think operators are too magic (except for the QRect stuff), 
given that the conversions can potentially fail. From the QPA 
perspective, we could introduce something like

void *QPixmap::toNativeFormat(enum Format {} ) const

which would then call #ifdefed code or into the platform backend.


Friedemann Kleint
Digia, Qt

More information about the Development mailing list