[RFC] Fixing the QT_QPA_PLATFORM dilemma

David Edmundson david at davidedmundson.co.uk
Tue Oct 10 18:07:23 UTC 2017


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.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20171010/4bbdb047/attachment-0001.html>


More information about the Plasma-devel mailing list