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-boun...@qt-project.org> on behalf of Tor Arne Vestbø <tor.arne.ves...@qt.io> Sent: Friday, May 15, 2020 2:43 PM To: Maurice Kalinowski <maurice.kalinow...@qt.io> Cc: development@qt-project.org <development@qt-project.org> Subject: Re: [Development] Untangling our platform plugins > On 15 May 2020, at 14:28, Maurice Kalinowski <maurice.kalinow...@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@qt-project.org https://lists.qt-project.org/listinfo/development
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
