[Development] Qt 5.1 feature set and freeze date

[Samuel Rødal]

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