[RFC] Fixing the QT_QPA_PLATFORM dilemma
Martin Flöser
mgraesslin at kde.org
Tue Oct 10 19:11:23 UTC 2017
Am 2017-10-10 20:07, schrieb David Edmundson:
> On the "fix Qt" side.
>
> Discussed in QtCS yesterday (I have more notes to type up):
>
> QtWayland client will be moving into QtBase.
> When this happens, neat and tidy autodection is do-able. Also those
> bundled apps would have wayland.
>
> Realistically we're talking Qt5.11.
>
> Maybe we could do a hack in Qt5.10 in the meantime.
>
> Once we depend on that in Plasma we can safely remove the variable,
> apps statically linked to older Qt will default to XCB regardless of
> whether they're built with wayland.
>
> ---
>
> As for hacks.
>
> - QPT won't work, and if we have to patch Qt you may as well patch Qt.
>
> - kdeinit would work, but means porting any DBus activated stuff to go
> via kdeinit (which wouldn't be a bad thing to do regardless).
> KToolInvocation sometimes skips kdeinit, so we'd need to patch that
> too.
>
> - * add API to KGuiAddons and patch all apps
> If we did that we may as well do it with a Q_COREAPP_STARTUP_FUNCTION
> and not patch all apps.
>
> ---
>
> IMHO, it's not something worth bodging. It risks breaking just as much
> as it fixes.
> It's an obscure case and quite easy to work around. By the time we
> have the regular users, the problem will be gone.
I disagree. We hold back the switch. We devs don't switch and why don't
we switch because we have showstoppers like that. We cannot recommend
users to try it and things don't work.
I want to get us switch in 5.13. 5.12 LTS as last version on X11,
afterwards everything on Wayland. That's before Qt is fixed. So we need
to get our showstoppers removed.
Cheers
Martin
More information about the Plasma-devel
mailing list