[Gtkradiant] Planning more Radiant file dialog fixes

[Nerius Landys]

Hi guys.  I'm going to fix at least 3 more bugs related to file
dialogs in Radiant (Rambetter-temp-fixes branch) before I move on to
anything else.

First, the problem that a map isn't saved unless its filename ends in
".map" or ".xmap" (a file of 0 length is created but there is hardly
any warning that your work hasn't been saved).  Reports regarding this
problem have appeared several times, for example:
http://zerowing.idsoftware.com/pipermail/gtkradiant/2010-February/011302.html
.  This happens on Linux and on Windows.  Not sure yet how I'll fix it
but likely something along the lines of a popup window that warn the
user of the mistake, after the save operation fails.

Number two on my list.  When using the GTK file dialog, files are not
filtered in the file display.  So, if you're loading a map, you see,
in the file dialog, all that crap in your maps folder, not only .map
and .xmap files but also .bsp, .prt, .bak, and all the others.  It
makes it really difficult to find what you're looking for.  Markus
already fixed this bug in his GIT, and I will compare his change with
whatever I come up with (and/or use his patch as a guide).

Number three.  And I'm wondering if anyone has any thoughts on this.
It's a Windows problem when using the native Windows file dialog
(non-GTK option).  The problem is best described with a screenshot:
http://daffy.nerius.com/temp/rad-file-dialog-no-refresh.png .  The
thread in GtkRadiant that starts in function file_dialog() (in
gtkmisc.cpp) passes control to the Windows function GetSaveFileName().
 GetSaveFileName() does not return until the user has taken action
(such as cancel or select file).  In the meantime, GtkRadiant cannot
refresh itself because that thread is tied up.  Now is there an
elegant solution to this problem?  I wonder how the GTK file dialog
handles this.

- Rambetter