I encountered a snap app-specific issue with an application I am packaging.
First: My app wants to open a file and perform some kind of processing on it, When the user clicks the open file button a dialog pops up using Qt’s QFileDialog, the dialog opens in the background and do not get’s user’s focus. This happens only when the application is packaged in snap package format. This behavior is also not consistent, The Save file Dialog with the same QFileDialog class gets the user’s focus perfectly fine. (I noticed two different types of GTK file dialogs with different behavior are actually opening on both cases see attachments below)
Second: When the user selects a file they want to open in my app, my app shows them the location or path of the opened file which in the case when the app is snap packaged is not correct (/run/user/1000/doc/7bfef3cf/2019-03-23_12-06.png) while the real path of the image is (/home/username/Pictures/2019-03-23_12-06.png).
Am using QFileInfo class in both cases.
Output of snap --version
Note that even with the new xdg-desktop-portal version, you will still see $XDG_RUNTIME_DIR/doc paths for cases where we don’t know the snap would be able to read the path. In most cases this should be fairly transparent: reads and writes to the proxied file name will be reflected in the real path the user chose.
As for the dialog focus issue, it sounds like the dialog is not being set as a transient for the main window. There is definitely support for this in the xdg-desktop-portal out-of-process file choosers, so I’d suspect this is either a problem with the QFileDialog code, or in the way you’re using it in your application. Does the dialog have a parent set?
The path looks weird and is confusing users, if this issue can be fixed it should be fixed.
QFileDialog has no issues, as it works fine on non snapped version of app, yes i set correct parent widget for it. The problem seems like with the Gtk file chooser dialog.
Also there are two different GTK dialogs are poping up, for different tasks as I mentioned in main post, both are behaving differently. This file dialog thing looks like a big mess, example on one dialog if user click Home the dialog shows real user home, while on other it shows snap’s home. There are many more inconsistencies in navigation itself and with the appearance of gtk file dialog which only happen when app is run as snap.
Qt will behave differently if it detects that it is running in a sandbox (Snap or Flatpak). So simply saying that your app functions correctly when not sandboxed doesn’t mean the problem couldn’t be in Qt.
I think I’ve seen this particular bug in the past though, as outlined here:
In short, Qt incorrectly passes the parent window X ID as a decimal number when the portal expects it to be hexadecimal:
It’s not something that can be reliably worked around on the xdg-desktop-portal side, as there is no way of knowing whether a string containing only the digits 0-9 is a decimal ID from Qt or a regular hexadecimal that just happens to not use the digits A-F.
I’m not sure what the current status of this is on the Qt side. I haven’t ever seen much action on bug reports I’ve filed with them in the past though.
Interestingly the QFileDialog::getExistingDirectory function of QFileDialog correctly places the GtkFileDialog at user focus and open’s a different GtkFilePicker dialog( the second image mentioned in the main post of this thread).
All I am saying is this is so confusing and should be investigated and prioritized.