QDesktopServices::openUrl() not working if app closes

jayrickaby

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

SGaist

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.

jayrickaby

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

IgKh

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.

A quick thing you can do as a workaround is to start xdg-open as an attached sub-process. It works in Flatpak too.

JonB

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.