[Development] Qt 5.1 feature set and freeze date

[Poenitz Andre]

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.