Rodal Samuel wrote: >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.
This sounds like a contradiction. Are you saying you can use the native type at compilation time, but not a typedef with a platform-neutral name for it? > You would have to find a common denominator for all Unix > platform plugins for instance, covering KMS, Android, XCB, Wayland, > and more. The needed common denominator for is "existence", and on the technical side some "would be nice if the handle (not the object) is copyable so it's possible to store and pass around". >> 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(). Perhaps. Perhaps not. What with cases that really operate on native handles only. And of course a typedef cannot be used if it does not convey the necessary information. All I am saying is that the Qt library side should try hard to make it possible for user code to stay platform-agnostic to the largest extend possible. This might not possible in all cases. Bad luck there, but no need to pro-actively make cases harder where it would be possible. Andre' PS: > [...] A problem with exposing too much of theinternals is that you >remove the flexibility of changing the implementation without breaking > applications (like when we made QPixmap raster-based on X11). This restriction of presumably needing this or that kind of compatibility is completely self-imposed. There is no conceptual difference between saying "set QT_I_DO_NOT_NEED_COMPATIBILTY than you get a few extra features. Use it if you want, but you are on your own" and "There is this module, add it to your build system, etc, Use it if you want, but you are on your own" _except_ that the latter imposes more work for the user. Lots of real-world use cases like our very own Qt installers or the binary Qt Creator builds do e.g. not require binary compatibility on the Qt side at all (even source-incompatibility would be tolerable) but would pretty much prefer to not need a platform-independence layer on top (or alongside) Qt proper. But that's mostly a different story. We can discuss that too, but perhaps in a separate thread. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
