QFileDialog::setFilter() does not show hidden files

[Mark81]

@jeremy_k sorry, I forgot the first char during copy and paste

[Mark81]

@JonB ok, I see a couple of error here. First I didn't understand the static use of the funtion.
Then how to apply filters. The rules I want are the following:

• show all directories (hidden or not)
• show all *.bin files (hidden or not)

For example, my current test setup is:

/blabla/myproject/
    dist/
        firmware1.bin
    .output/
        firmware2.bin    

I should be able to reach both of them.

[JonB]

@Mark81
Proceed as you were, but do not use static QString QFileDialog::getOpenFileName(). Instead follow the pattern in https://doc.qt.io/qt-5/qfiledialog.html#details from "You can create your own QFileDialog without using the static functions. " onward.

QFileDialog fileDialog(this, tr("Select bin file"), "", tr("Binary files (*.bin)"));
fileDialog.setFileMode(QFileDialog::ExistingFile);
fileDialog.setFilter(QDir::AllEntries | QDir::Hidden);
if (fileDialog.exec())
{
    QStringList fileNames = fileDialog.selectedFiles();
    if (!fileNames.isEmpty())    // should be the case, because of the `exec()` return result
        qDebug() << fileNames[0];
}

As an aside: While you are here you might as well try adding fileDialog.setOption(QFileDialog::DontUseNativeDialog);. Compare this Qt-file-dialog to the original native-file-dialog and see which you prefer (probably the original, native dialog!).

[jeremy_k]

There's a bug report that says showing hidden files with native file dialogs might not work.

https://bugreports.qt.io/browse/QTBUG-161

[jeremy_k]

@JonB said in QFileDialog::setFilter() does not show hidden files:

if (fileDialog.exec())

I wouldn't use this particular function.
QDialog::exec():

Note: Avoid using this function; instead, use open(). Unlike exec(), open() is asynchronous, and does not spin an additional event loop. This prevents a series of dangerous bugs from happening (e.g. deleting the dialog's parent while the dialog is open via exec()). When using open() you can connect to the finished() signal of QDialog to be notified when the dialog is closed.

QFileDialog's static function documentation hints at this, in milder terms.

[JonB]

@jeremy_k said in QFileDialog::setFilter() does not show hidden files:

I wouldn't use this particular function.

Then you would be at odds with Qt's own implementation of static QFileDialog::getOpenFileName() convenience function, which ends up going

if (dialog.exec() == QDialog::Accepted)

at https://code.woboq.org/qt5/qtbase/src/widgets/dialogs/qfiledialog.cpp.html#2248. Same for all the other utility static methods. :)

For this user, and to replace QFileDialog::getOpenFileName(), it is OK to use the exec(), for simplicity. He is welcome to change over to the non-blocking call, but it's more code to write and understand.

Qt does not always practice what it preaches ;-) Many (most?) code examples are happy using QDialog::exec() in practice, despite the documentation's admonition :)

[jeremy_k]

@JonB said in QFileDialog::setFilter() does not show hidden files:

@jeremy_k said in QFileDialog::setFilter() does not show hidden files:

I wouldn't use this particular function.

Then you would be at odds with Qt's own implementation of static QFileDialog::getOpenFileName() convenience function, which ends up going

if (dialog.exec() == QDialog::Accepted)

at https://code.woboq.org/qt5/qtbase/src/widgets/dialogs/qfiledialog.cpp.html#2248. Same for all the other utility static methods. :)

And much of the documentation. It takes time for updates to percolate through.

A simplified example of the risk:

QWindow *parent = new QWindow();
QWindow *child = new QWindow(parent);
QObject::connect(child, &QWindow::windowTitleChanged,
    [&]() {
        delete parent; // child deleted by parent destructor
        qDebug() << child->parentWidget(); // child, aka this, doesn't exist any more
});
child->setWindowTitle("crash");

By spinning an event loop within a function (slot, event handler, or otherwise), anything that that the event loop can touch may be altered. The trigger might be a timer, network traffic, or other phenomenon that a modal dialog won't prevent.

For this user, and to replace QFileDialog::getOpenFileName(), it is OK to use the exec(), for simplicity. He is welcome to change over to the non-blocking call, but it's more code to write and understand.

Qt does not always practice what it preaches ;-) Many (most?) code examples are happy using QDialog::exec() in practice, despite the documentation's admonition :)

I think you're making my point here. The documented danger of exec() is real, despite existing code that uses it.

[JonB]

@jeremy_k said in QFileDialog::setFilter() does not show hidden files:

And much of the documentation. It takes time for updates to percolate through.

I don't know what you mean. The admonition about/advice not to use QDialog::exec() has been there for years, it's not recent, and the code we are talking about remains using it, and shows no signs of changing.

delete parent; // child deleted by parent destructor

Yep, and there are thousands of other cases where deleting a parent during a child operation will bomb, so don't do it!

You think it's important for this user not to use QFileDialog::exec(). I respect your point, but don't think it matters in this situation. We can agree to differ about what is most important :) Anyway, the OP has your recommendation to follow if he chooses to do so.

[Mark81]

Well, the code you suggested does not work either.
Instead, it works using the Qt-file-dialog. It seems a bug to me, because using the native-file-dialog the behavior is quite different! Also the . and .. are not shown in the Qt-file-dialog version. And I don't like this one :-)

[JonB]

@Mark81 said in QFileDialog::setFilter() does not show hidden files:

Well, the code you suggested does not work either.

Which/whose suggested code, and what does not work?

If you are referring to my suggestion that you might like to look at using the internal Qt dialog instead of the native one, it was just that, a suggestion. I did also say you would probably prefer the native one.

[Mark81]

@JonB Yes, I was talking about the code reported in the post I replied to :-)
This one:

QFileDialog fileDialog(this, tr("Select bin file"), "", tr("Binary files (*.bin)"));
fileDialog.setFileMode(QFileDialog::ExistingFile);
fileDialog.setFilter(QDir::AllEntries | QDir::Hidden);
if (fileDialog.exec())
{
    QStringList fileNames = fileDialog.selectedFiles();
    if (!fileNames.isEmpty())    // should be the case, because of the `exec()` return result
        qDebug() << fileNames[0];
}

This code does not shown hidden files or directories.
It does show them adding fileDialog.setOption(QFileDialog::DontUseNativeDialog); but I want to use the native file dialog.

It's still no clear to me how to show hidden files and directories....

[JonB]

@Mark81 said in QFileDialog::setFilter() does not show hidden files:

It's still no clear to me how to show hidden files and directories....

In the way shown above.

This code does not shown hidden files or directories.

It does show them adding fileDialog.setOption(QFileDialog::DontUseNativeDialog); but I want to use the native file dialog.

So that suggests the native dialog does not respond to your desired options from Qt. That's (partly) why I suggested trying the Qt dialog. As far as I know, the Qt dialog is capable of acting on every option/mode/preference you can pass to it from Qt, but is "not as pleasant" as the native dialog. But the native dialog behaves differently on each platform, and may not respond to all options as you would wish.

Meanwhile, Googling for you for QDir::Hidden QFileDialog::DontUseNativeDialog I come across https://www.qtcentre.org/threads/67923-Get-QFileDialog-to-display-dot-folder-files. That is under some Linux and states

fdlg = QtWidgets.QFileDialog()
        fdlg.setFilter(QDir.AllEntries | QDir.Hidden)
        if (fdlg.exec()):
            fileNames = fdlg.selectedFiles()
        fdlg.close()

does work.

That is all I know. Remember that Ubuntu nowadays by default is running GNOME rather than the traditional Unity desktop. The native file chooser dialog is supplied by the windowing system. Maybe the GNOME one ("Nautilus"?) does not supply the options you want, or they are not interfaced to from Qt.