KF5/Qt5 and multiple QPAs

[Martin Graesslin]

On Wednesday, September 21, 2016 10:14:33 PM CEST René J.V. Bertin wrote:
> Hi,
> 
> Am I correct that Qt now provides a Wayland QPA and that users on Linux can
> now decide, in principle "on the fly" which displaying protocol a newly
> started application is going to use, presumably with a platform-wide
> default either hardwired into Qt or defined in some settings file?

That's correct. This mail is written in a kmail on --platform xcb in a Wayland 
session.

> 
> If so, how does that work out with KF5 applications that get started by
> others? Say, a user with a Wayland-based desktop logs in over ssh+X11 and
> wants to run kate remotely with `kate -platform xcb`. A new session dbus
> will be started, and during Kate's start-up sequence kdeinit5 will start
> which will then start klauncher.
> 
> I just tried this on OS X (I have a working XCB QPA on my system, plus a
> patched dbus that works without launchd). kdeinit5 starts up fine because
> it's not a GUI app (I think), but klauncher is. It doesn't inherit the
> `-platform xcb` arguments, and thus fails because the Cocoa QPA only works
> locally.
> 
> Mostly asking out of curiosity, though I would of course appreciate it if on
> occasion I could use applications like Kate remotely.

That's something I have never tried and I think is a corner case. In case of 
starting a new dbus session it would be enough to just do an
export QT_QPA_PLATFORM=xcb

prior to starting any remote application. That will force all to use the xcb 
platform. Which is what you want in a remote situation.

But I need to remind that the x11 over the network is broken. It just doesn't 
work and I highly suggest to look into different solutions for this. If it 
breaks, it breaks and that's a good thing!

Cheers
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20161004/4d3b3a50/attachment.sig>