Not really. - I would start such program tracing only after a personal delay to notice that data processing for the function “QFileDialog::getOpenFileName” might take longer than what I would usually expect.
(I might be more patient under other circumstances.)
what you would see is the last line of output would "hang"
This did not happen. The dialogue software might be still busy with other stuff.
Additional activities might distract then from temporary technical difficulties.
just as you went into a "delay", and that would be your indication as to why....
I found questionable software behaviour also for other components in the suggested way so that corresponding clarification requests and bug reports were published.
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.
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 );
@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: