On 09/29/2011 05:36 AM, ext Girish Ramakrishnan wrote:
> Hi,
>
> On Wed, Sep 28, 2011 at 6:08 PM, Harri Porten<[email protected]>  wrote:
>> Hi,
>>
>> this topic was already touched in Holger's "directFB and Lighthouse" mail
>> but wasn't really resolved. As my concern also applies to Qt 4.8 I'd like
>> to bring up this topic in a distinct mail.
>>
>> Usage of the QPlatformNativeInterface class typically looks like this case
>> from tst_qlistview.cpp:
>>
>>   return static_cast<HWND>  
>> (QGuiApplication::platformNativeInterface()->nativeResourceForWindow("handle",
>>  window));
>>
>> Above code is #ifdef'ed for Windows which makes it safe as there is only a
>> single platform implementation available (as far as I can tell). But what
>> about Linux? I count three implementations of "display" resources:
>>
>> $ git grep \"display\" src/plugins/platforms/*/*.cpp
>> src/plugins/platforms/wayland/qwaylandnativeinterface.cpp:    if 
>> (lowerCaseResource == "display")
>> src/plugins/platforms/xcb/qxcbnativeinterface.cpp:        
>> insert("display",QXcbNativeInterface::Display);
>> src/plugins/platforms/xlib/qxlibnativeinterface.cpp:        
>> insert("display",QXlibNativeInterface::Display);
>>
>> How will anyone be able to tell them apart without a way to check which
>> plugin is active? Or has this changed?
>
> I understand keeping things as plugins makes it very easy to test with
> a single build of Qt, but has it been considered to compile platform
> support statically into Qt using a configure time option? That way we
> can just use ifdef and detect which platform is active at compile
> time. Is there a use case at all to have a pluggable platform system
> other than for testing? Yes, this does take us back to the _win, _x11
> days except now we have a proper platform interface :-)
>
> Also, if an app wants to support multiple platforms, I guess it has to
> have ifdefs for including the necessary platform header files. How
> does one achieve this right now? App assumes all headers exist, is it?
>
> Girish

There is only the qnativesysteminterface.h header, and the interface 
uses strings as identifiers and returns void *.

In the Wayland case we might have the same Qt version being used both 
for the Wayland server / compositor and for the Wayland plugins, but 
with different platform plugins, so enforcing the platform plugin at 
configure time won't work.

--
Samuel
_______________________________________________
Qt5-feedback mailing list
[email protected]
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback

Reply via email to