Odd QFileDialog behavior

[Dmitry A. Kuminov]

QFileDialog behaves wrongly on OS/2. Things that I noticed:

1. The root directory of the current drive cannot be read. Specifying top-level folders manually in the file name entry field works.
2. Typing a name of the existing folder in the file name entry field creates a duplicate name in the list view if the case of the typed folder differs from the original.
3. Popup windows (e.g. in the filter combobox) sometimes appear too large.

[Dmitry A. Kuminov]

I want to fix this before Beta2.

Problem 3 seems to be a generic one (appears not only in QFileDialog)

There are a lot of wrongly chosen #ifdef Q_OS_WIN cases in filesystem-related classes (QDir, QFileInfo, QFileDialog and friends) that surround blocks of code to deal with FAT-like filesystems (such as the presence of drive letters, back slashes as separators and so on). If these #ifdefs were Q_FS_FAT we wouldn't have to deal with that but now we have to add Q_OS_OS2 to them.

However, the above is not the real reason of problem 2. The real one is that they internally keep track of file system objects using a QHash<QString> array and don't handle the case-insensitive case (e.g. use the file name as a hash key as it is, no matter what case it has). As a result, say, Folder and fOlder will occupy two different slots in the hash and are therefore treated as different objects.

The reason why it works on Win32 is that they use a system function to get the long name out of a given file path before putting it to the hash and this function returns the full path where the case of the components is persistent (and matches their real case in the filesystem).

I'm going to change it so that when putting/retrieving a filename from the hash on case-insensitive systems, its name will be lowercased.

[Dmitry A. Kuminov]

An accurate workaround for problem 2 was added in r173.

[Dmitry A. Kuminov]

While working here I found another problem. The test application (for example, examples/tutorual/addressbook/part7) would sometimes hang after dismissing the Open File dialog. Thorough debugging showed that the hang happens when the main thread is waiting for the auxiliary thread to terminate: there is a zero-timer that gets constantly posted over and over again from the timer thread and so rapidly that the thread which is waited for doesn't get CPU slices and has no chance to terminate (!) while the main thread cannot process this timer message since it is blocked in waiting.

It was really fun to debug. Anyway, the solution is in r175. I changed the timer code (which is as you remember custom now, i.e. it doesn't use PM timers at all due to its seriously limited implementation) so that timer messages for a given timer are not posted again until the first one gets picked up by the target thread. The hang has gone.

[Dmitry A. Kuminov]

Problem 1 has been fixed in r178. The file dialog looks quite operational right now.

For problem 3 I created #67, so closing this one.