[Development] Qt Platform Extras
Friedemann Kleint
Friedemann.Kleint at digia.com
Fri Mar 1 11:22:22 CET 2013
Hi,
>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.
Regards,
Friedemann
--
Friedemann Kleint
Digia, Qt
More information about the Development
mailing list