QFileDialog signal fileSelected is triggered twice for one user choice. Changed in recent Qt?
It seems to me that this is a change in behaviour, that formerly it was only triggered once. I am testing on Ubuntu 14.04 Gnome, Qt5.2.1, and PyQt5. Formerly I was testing Qt4.8 and Ubuntu 13.04 among others.
The docs say that the signal is only triggered when "... and the dialog is accepted." And the name of the signal suggests that only one file can be selected. There is another signal 'filesSelected' for the case of multiple files selected. So it surprises me that the signal is emitted twice. (Also, as best I recall, it behaved differently before.)
The test case is: the user types 'foo' into the dialog and clicks the OK button. dialog.setDefaultSuffix("txt") was called on the dialog. The signal is triggered twice, once with the arg "foo" and a second time with the arg "foo.txt". I can provide a small test case.
If in the slot for signal fileSelected you call dialog.filesSelected(), it returns 'foo.txt', whether the first or the second fileSelected signal received. It really seems like a recently introduced bug.
[quote author="bootchk" date="1400018706"]The test case is: the user types 'foo' into the dialog and clicks the OK button. dialog.setDefaultSuffix("txt") was called on the dialog. The signal is triggered twice, once with the arg "foo" and a second time with the arg "foo.txt". I can provide a small test case.[/quote]That sounds like a bug indeed. Could you please submit a report to https://bugreports.qt-project.org/ , if someone else hasn't already reported it?
In the meantime, you can use the static functions, like QFileDialog::getOpenFileName() and QFileDialog::getSaveFileName()
No, I would not recommend using the static versions. Using the way bootchk uses QFileDialog is the way to go. It avoids spinning an event loop in a modal dialog, with all risks involved with that. The asyncronic way with connecting with the fileSelected signal is much more elegant and allows the application to continue working while the user is selecting a file.
I'd work around the issue by creating a small check in the slot on if you're getting the same file selected multiple times in rapid succession.
I submitted QTBUG 38985.
I agree with Andre about modality of dialog.
Easier workaround is to use the accepted signal (instead of fileSelected) and query dialog.filesSelected(), which only seems to return one filename (e.g. foo.txt)
I'm wondering now why the fileSelected and filesSelected signals even exist, since they offer no more functionality. In other words, one way to do it is enough.
I disagree there. The benefit is that you can directly connect the fileSelected method with a loadDocument(QString filename) slot, even if that slot is on an object that has no knowledge of where this file name comes from. There is then no need to keep a pointer to the file dialog either, you simply let it destroy itself when it is closed.
So the Qt response to the bug report was, paraphrasing: Not Qt's fault, but native file dialog is probably broken. I was not aware that previously Qt used native dialogs on Linux. Now there is a worse problem: the dialog is supposed to 'confirm overwrite' but it doesn't always. If the user enters a filename, in some of my tests, it finds an existing file of the same name (with proper suffix) and does show a warning dialog about overwrite. Other times, it does not (even though the file exists.) I haven't pinned down exactly what conditions it occurs in.
Is this really a native widget, i.e. I need to file a bug report with Ubuntu? (Or find their explanation why they changed the behaviour, say as a HIG improvement?)
Was it always a native widget? (Because it didn't behave this way for Qt4.8)
(The inconsistent behaviour might be a difference between Ubuntu 14.04 LTS and Ubuntu 14.04 Gnome? Could Ubuntu Unity implement a different native file dialog than Gnome?
It might have something to do with auto-completion and tabbing in the dialog to the next button, etc. since I suppose the filename textbox is partly a search parameter, to highlight a file in the list widget.)
AFAIK, by default it's a native file dialog. Just to be sure I understood correctly: if you compile and run your test with 4.8 in the same conditions, the misbehavior doesn't occur ?
My 'fix' is to setOption(QFileDialog.DontUseNativeDialog, True) for platformName() == 'xcb'
Sad, the sturm and drang, different desktops, inadequately tested.
SGaist: I haven't tested 4.8 recently, and found that my test plan records don't include the test. I just switched from U13.04 and Qt4.8 to U14.04 and Qt5.2.1, but as I recall, it worked before. It seems so fundamental, its shocking to me. I really hope the mistake is all mine.
Ubuntu is known to do some customizations and modifications in their Qt packages so it might also be on their end.