[Development] Qt 5.1 feature set and freeze date

Samuel Rødal samuel.rodal at digia.com
Thu Feb 14 12:43:33 CET 2013


On 02/14/2013 12:11 PM, Poenitz Andre wrote:
> 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?

The application can of course use the native type (xcb_pixmap_t or 
similar) if it links to xcb manually because it wants to do some 
platform specific stuff when the application is running on X11.

QtGui however can't really do that since all the windowing system 
integration goes via the platform plugins. So the same libQt5Gui.so can 
be used with a variety of windowing systems each having their own native 
handle types.

In the above scenario when the application wants to do something custom 
on X11 it should first query QGuiApplication::platformName() and check 
if it equals "xcb", so that it doesn't try to treat QWindow::winId() as 
an xcb_window_t when the offscreen or wayland platform plugins are used.

--
Samuel




More information about the Development mailing list