On 02/14/2013 10:39 AM, Poenitz Andre wrote: > Samuel Rødal wrote: >> What use is a QPlatformPixmapHandle having per-platform typedefs >> (xcb_pixmap_t, HDC, etc) without #ifdefs to manipulate it using native >> code in the first place? >> >> Can you give a platform-independent example use case? :) > > It helps reducing the amount of user code within #ifdef therefore > the risk of breaking branches that are not "active" on a developers > machine.
There's still the problem that it's not possible to do such typedefs as easily as in Qt 4.x since back then the windowing system was known at compile time. You would have to find a common denominator for all Unix platform plugins for instance, covering KMS, Android, XCB, Wayland, and more. > It can postpone the need to switch to native code, so helper > function merely passing on such handles can be written > completely #ifdef free. > > Structures keeping such handles can be defined more cleanly, > similarly class interfaces. As for passing such handles around you might just as easily be able to pass the QPixmap * or similar around. In some cases there might be multiple handles associated with a resource, such as on X11 in 4.x days, where a QPixmap had both a handle() and a x11PictureHandle(). > Ports to new platforms with new platform specific handles are > easier as they touch less code. Why does a port to a new platform even need to expose platform specific handles before a need arises? A problem with exposing too much of the internals is that you remove the flexibility of changing the implementation without breaking applications (like when we made QPixmap raster-based on X11). It's in any case better to try to solve in platform-independent ways problems that applications currently have to solve with platform specific code paths. -- Samuel _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
