On Fri, May 15, 2020 at 12:49:28PM +, Laszlo Agocs wrote:
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.
yes
[...] Building on the Qt plugin system is therefore still very valuable
here,
i don't s
] Untangling our platform plugins
> On 15 May 2020, at 14:28, Maurice Kalinowski 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.
&
> On 15 May 2020, at 14:28, Maurice Kalinowski 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
>>>
> >
> 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 p
On Fri, May 15, 2020 at 09:20:26AM +, Tor Arne Vestbø wrote:
But for the ones that live in qtbase, the majority of their code would
be moved to the relevant modules, leaving only the plugin’s entry point
as a shared library.
having a significant part of the plugin's implementation (if not
On Fri, 15 May 2020 at 13:45, Lars Knoll wrote:
>
> Thanks for writing this up Tor Arne. +1 for the general plan from my side.
+1 good plan. I have recently been scratching my head about where
platform-specific qtbase utilities should
go, like facilities to convert Qt containers into Java Arrays
Thanks for writing this up Tor Arne. +1 for the general plan from my side.
The QPA abstractions are great, but the way we’ve been currently structuring
out code has made some things needlessly complex. And in most cases (with maybe
the exception of Linux xcv vs Wayland), we really don’t need the
