Conversation
dc42c92 to
830e180
Compare
|
@jonathan-mcewan can you test this when its finished building and report back if it worked. (it did in my local test) Direct link to the win artifacts for the job: https://github.com/deskflow/deskflow/actions/runs/14631534694/artifacts/2998593238 |
Want to wait for this before landing? |
|
Wayland server seems borken in this PR. Edit: Clients connect and I don't see any errors, but weirdly the portal permission dialog doesn't show. I wonder if this happens because we're creating a Qt app instance in server? // HACK to make sure settings gets the correct qApp path
QCoreApplication m(argc, argv);
m.deleteLater();Maybe GNOME specific? I'll also test KDE. Edit: Heh... KDE Wayland client also not working; no portal dialog on KDE Wayland client. Server: |
|
Do you think its safe to just guard this on windows only ? (until we make them QCoreApplication) |
…ind the app path with fixes #8534
Ah yeah maybe; I think it only had an adverse effect on Wayland. Though it doesn't bode well for us wanting to Qt-ize the core :| |
Naw should be fine when we are using them and not the rando app w/ run . |
fixes #8534
deskflow-server,deskflow-coreanddeskflow-clientare not QApplications this causes the qApp used in our settings object to fallback to the default path and make the settings read from different paths (if not using the default one)To Fix this on windows only we make a QCoreApplication in each of them and delete it after , this is enough to initialize the qApp.
We should consider in the future making these apps use a QCoreApplication in place of the
App