Qt QFileDialog::setDirectory funny behavior in Ubuntu 12.04

Question

I have a class that inherits from QFileDialog . In the constructor, I call setDirectory and pass in the last directory visited (which the class keeps track of; see code below). On Windows, this works fine. And if I show the dialog multiple times, it is internally smart enough to resume at the last location (eg where the user saved a file before). This is the desired behavior.

On Ubuntu 12.04 (GCC 4.8 compiler), on the other hand, the system does not automatically resume where last left off if I call showFileDialog multiple times. So I tried adding the setDirectory call within that function as commented below, but that didn't change anything. Furthermore, if I take out setDirectory from the constructor so it is only called in showFileDialog , the file dialog opens to the folder from which the program was run. (ie setDirectory didn't work.) Subsequent calls to showFileDialog will open a file dialog starting in the directory requested.

So it seems like the call has a delayed effectiveness. Is this a Qt bug, or mine? Either way, how can I get the setDirectory call to be effective?

Example code:

QString FileDialog::defaultDir = QDir::homePath();

FileDialog::FileDialog(QWidget *parentWindow /*, ...*/)
    : QFileDialog(parentWindow)
{
    setDirectory(defaultDir);
    //...
}

QString FileDialog::showFileDialog()
{
    // Adding setDirectory(defaultDir) here doesn't help.

    if(!exec())
    {
        return QString::null;
    }

    defaultDir = directory().path();
    //...
}

Answer 1

It is not clear from the code above how you know that the path was changed. I'm not sure that directory() is responsible for that.

Consider using void QFileDialog::directoryEntered(const QString & directory) signal.

Answer 2

Workaround found:

I happen to set the dialog title ( setWindowTitle() ) every time I open a FileDialog . If I connect to the QFileDialog::windowTitleChanged signal and call setDirectory within the slot, it is effective.

This is an unintuitive workaround though, so I am open to better answers.