[Development] Untangling our platform plugins

[Laszlo Agocs]

Hi,

Agreed. The choice of which backend (be it a dynamically loaded or statically linked in one) to use is going to remain a runtime choice. I do not see -platform xxxx or QT_QPA_PLATFORM going away or changing in any way. Think Linux for example, where xcb, wayland, eglfs, linuxfb, offscreen, vnc, and perhaps others may all be applicable (for the same build). Therefore I would advise against simply linking in a bunch of code, expecting that a build of Qt always uses the same one QPA backend at run time. We still need to be able to choose at runtime. Building on the Qt plugin system is therefore still very valuable here, even when the plugins are static.

Best regards,
Laszlo


________________________________
From: Development <development-bounces at qt-project.org> on behalf of Tor Arne Vestbø <Tor.arne.Vestbo at qt.io>
Sent: Friday, May 15, 2020 2:43 PM
To: Maurice Kalinowski <Maurice.Kalinowski at qt.io>
Cc: development at qt-project.org <development at qt-project.org>
Subject: Re: [Development] Untangling our platform plugins



> On 15 May 2020, at 14:28, Maurice Kalinowski <Maurice.Kalinowski at qt.io> wrote:
>
>>>
>> having a significant part of the plugin's implementation (if not most of
>> it) linked into the parent library leads the concept of "plugin" ad absurdum.
>>
>>> Or, in the case of platforms such as macOS where there’s only one
>>> “platform”, the plugin is built directly into QtGui as a static plugin.
>>>
>> the logical consequence of the above would be statically linking the plugins
>> on all platforms. or, for that matter, throwing out the pretense of plugins and
>> just make it a regular factory, to the degree it even makes sense at all.
>>
> [Maurice Kalinowski]
> What about backends like WebGL, VNC etc.
> It is rather beneficial to decide on runtime which backend to use compared to compile time decision. Especially given that you'd need two different builds then for just a "minimal aspect" of the build.

Agreed, and that part stays as is with the proposal in the OP.

Cheers,
Tor Arne

_______________________________________________
Development mailing list
Development at qt-project.org
https://lists.qt-project.org/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20200515/689a6d16/attachment-0001.html>