@Armin

You can use the static member function getOpenFileName

@Rondog @alex_malyu

I see that this is not as simple as I had hoped and I guess I will just deal with using a directory browse or letting the user set the name. The reason i have the user interacting with an .ini is because it is not just global program settings that are loaded. I want the user to have multiple configurations that they can easily switch between that have file paths and numeric settings saved so that the program can be used easily in rapid succession. The GUI is a port of a console application that is not yet finished so I want debugging with it to be quick. This is why I have the ability to save and load a .ini file so that if a user keeps testing with the same paths over and over they don't need to keep browsing for the same files over and over again. However, I wanted there to be the ability to have multiple setups saved which is why I don't just want there to be one .ini that is used automatically.

I know I could use some kind of slot system with the same .ini (like saves lots on a video game) to accomplish the same thing and the user just picks one of those slots. But like I said the application is not finished yet (the code behind the GUI) so it being perfectly clean is not an issue at the moment.

Thank you for the information.

I figured it out. You can't call the connect statement for the doubleClick signal until the QListView is in scope.

@Devopia53

This did it with Windows. Thanks

I've tested on windows. It seems the only possible solution is to ignore native dialog.

QFileDialog dialog; dialog.setFileMode(QFileDialog::DirectoryOnly); dialog.setOption(QFileDialog::DontUseNativeDialog, true); dialog.setOption(QFileDialog::ShowDirsOnly, false); dialog.exec(); qDebug() << dialog.directory();

Thanks! That did the trick. However, I had to delete each instance by hand, instead if using Qt::WA_DeleteOnClose, because I was referencing data from the dialog after it was closed.

Instead of editing the moc file you can just rebuild you project completely (you can delete the build folder before you rebuild).

I got it all working. I modified ololoepepe's class (http://stackoverflow.com/questions/12169878/limit-directory-traversal-in-qfiledialog) a bit for my pourposes and set the double click interval to 0 (essentially disabling double clicks). Thanks again.

One approach we used was to use the directoryEntered signal from the QFileDialog along with a custom proxy filter to handle it. The proxy contained a member variable for the last known good folder. Example code:

void MyProxyModel::DirectoryEntered( const QString& Dir )
{
QDir CurrentDir( Dir );

// If directory has no contents, reject the change. The isReadable() property is not reliable for some reason, as
// it permits "opening" directories that the user has no permissions for (the result is no entries in the dialog).
if( CurrentDir.entryList().size() == 0 )
{
CurrentDir = m_LastGoodDir;
m_pFileDialog->setDirectory( CurrentDir );
}

m_LastGoodDir = CurrentDir;
}

@Eyeless really sorry for the late reply! Just realised you have replied to me. After some testing I have solidified the conclusion that it is not a Qt problem, as was expected. As such, there is no reason to post my trivial dialog code.

I am writing this for posterity's sake.

This issue is caused due to the focus stealing prevention mechanism by Unity. The user could change Unity's default behaviour by issuing in a terminal the command:

dconf write /org/compiz/profiles/unity/plugins/core/focus-prevention-level 0

This will allow for the consequent dialogs to appear in front of their parents, as expected.

Solved!!
The problem was the paintEvent on the Qwidget CVWidget always running when I open an image.
I suppose that it contrast the paintEvent of the QFileDialog with an incorrenct visualitazion.

@stefanq
Super.
Thank you for the feedback.
Was not sure the linker flag would work with mingw.

That is one mother of a texture :)

Good luck

I forgot to double check but indeed it looks like that's the case