dvratil added a comment.
If I may add my two cents here, I agree with David that introducing a plugin for a plugin is a bit over the top. Whats the issue with contributing your backend into libkscreen upstream instead? If there's any code that could be shared between KWayland backend and your new backend, you can create a small static library (basically reusing most of what you've already done). Otherwise you are basically forcing libkscreen to accommodate a single usecase for your fork, and the community has the right to push back on that as it makes things more complicated for them just to make live easier for you. Regarding the asynchronous plugin loading. You still need to block the constructor of the KWayland backend in order to figure out which plugin you want to load, because the KScreen backend loading code synchronously calls `isValid()` just after constructing the backend. So it's nice you try loading your plugins asynchronously, but it doesn't solve much since all you do is blocking-waiting for a bunch o threads to finish, rather than just blocking-waiting for the calls to the registry to finish... The current backend loading code in libkscreen is of course simple and stupid because it was first designed only with XRandR and Fake backends in mind. Later on QScreen was added which also works synchronously. When Wayland support was introduced, Sebas rewrote lot of the code, but some of the assumptions were kept, like plugins initializing synchronously. It's not too hard to fix the backend loading code to not only make assumptions about backends based on Qt platform and to allow for true asynchronous initialization. REPOSITORY R110 KScreen Library REVISION DETAIL https://phabricator.kde.org/D29024 To: romangg, #plasma Cc: dvratil, ngraham, davidedmundson, plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, fbampaloukas, ragreen, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart
