QDesktopServices::openUrl() not working if app closes
-
Hello! I am making an app similar to the Window 7 Run Dialog. For that, the file/folder/website/other is opened and the window closes.
I have noticed that opening the file/folder/website via QDesktopServices::openUrl() works fine until I want to close the application immediately after. If I do that, the item to open is never opened. I thought this was an issue with the application portal (which may open for some file types), as I have found that is attached to my app's process for whatever reason. However, even with file types with default applications, they don't open if the app is closed after calling openUrl().
Is there anything I can do about this, such as waiting for the portal/process to properly start before closing the app? Thanks
-
Hi,
Which OS are you on ?
Which Qt version are you using ?Note, as the QDesktopServices details show, there's no guarantee that the application starts.
-
Qt v6.12.0-4, Linux (EndeavourOS, KDE Plasma)
I've looked at possibly using QProcess::startDetached() instead, but I don't know if that would open a file/folder/website with its default app in an easy cross-platform way -
Qt v6.12.0-4, Linux (EndeavourOS, KDE Plasma)
I've looked at possibly using QProcess::startDetached() instead, but I don't know if that would open a file/folder/website with its default app in an easy cross-platform wayA possible theory is that when
QDesktopServicesinvokes the XDG Desktop Portal service, it passes a reference to your application's active window. It is needed because the portal might decide to present a confirmation dialog or an application chooser dialog, which it needs to parent to your application's window. It is possible that KDE's implementation still fails if this reference is invalid, even if it doesn't actually need to display a dialog. I didn't test this theory, but if true - do note that it is within it's rights to do so.A quick thing you can do as a workaround is to start
xdg-openas an attached sub-process. It works in Flatpak too. -
I don't know what the code of
QDesktopServices::openUrl()does. But another possibility is that if you exit the program immediately after invoking it then it simply does not get enough time to do whatever to spawn the process, depending on its implementation. The first thing I would do is put in a sleep/delay before closing your application and see whether (a) that allows the sub-process to run and continue running or (b) allows the sub-process to run but then it "terminates" when you do exit your parent application. Then you will know where the issue lies. -
A possible theory is that when
QDesktopServicesinvokes the XDG Desktop Portal service, it passes a reference to your application's active window. It is needed because the portal might decide to present a confirmation dialog or an application chooser dialog, which it needs to parent to your application's window. It is possible that KDE's implementation still fails if this reference is invalid, even if it doesn't actually need to display a dialog. I didn't test this theory, but if true - do note that it is within it's rights to do so.A quick thing you can do as a workaround is to start
xdg-openas an attached sub-process. It works in Flatpak too.@IgKh said in QDesktopServices::openUrl() not working if app closes:
A possible theory is that when QDesktopServices invokes the XDG Desktop Portal service, it passes a reference to your application's active window. It is needed because the portal might decide to present a confirmation dialog or an application chooser dialog, which it needs to parent to your application's window. It is possible that KDE's implementation still fails if this reference is invalid, even if it doesn't actually need to display a dialog. I didn't test this theory, but if true - do note that it is within it's rights to do so.
Now I did test it, and that theory was not quite right. On Wayland, the calling application needs to request an activation token from the compositor to properly pass focus from itself to the spawned application. The communication with the compositor is asynchronous, and requires the event loop to keep running for a while to receive the token and actually invoke the portal or spawn the target binary. So it is not something specific to KDE.
I doesn't matter much for @jayrickaby though, and the suggestion to do it out of process with
xdg-openstands (just that doing it that way may not allow the opened application to automatically get focus on some compositors, if that matters) -
okay, i guess that i'll target
xdg-openwhen the user is on linux. thanks for the help. i was hoping for something easily cross-distro (or even not bound to xdg-open) like QDesktopServices::openUrl(). I'll have a look at the whole authorisation stuff and apply that to wayland and other sessions. thanks all
if there's an easier way for this that anyone knows of i will be happy to hear
