There are several ways to fix the recent chooser showing no recent files in Glomon Windows, but they are all sort of hacks except one, namely make the recent chooser guess the mime type of an URI on Windows as it already does on Unix. Currently, it always falls back to application/octet-stream and this is why the filter on application/x-glom that glom uses does not show up any files. I looked around a bit in the registry, and it seems that all known file extensions are in HKEY_CLASSES_ROOT/.$ext, and some of them have a "Content Type" key that looks like the mime type we are after. So all we need to do is to register the .glom type there (this can also be used to associate a nice icon with it) and to make the GTK+ recent chooser use that "Content Type" key for the extension of the URI it gets as default mime type.
To implement this, I need to be able to build GTK+ (and glib which GTK+ from SVN trunk depends on) on Windows. The easy method I already used for glom itself was to copy tarballs created by "make dist" to the windows machine so I don't have to create the configure script there, not requiring the autotools stuff. However, this gets horribly annoying when the repositories are updated frequently. It would be much nicer to have a working copy directly on Windows, and to (re)create the configure script there when necessary. In theory, this should work since mingw provides all necessary tools. In practise, I already stumbled upon several ugly problems in the past. I gave it another try, though, and I ended up with a freshly built glib from SVN at the end of the day. Below are the exact steps that got me this far.
I used the environment I set up as described here as a starting point. It is probably equally well possible to start with a freshly set up MSYS+MingW, though.
First, install termcap, libtool, automake and autoconf from mingw.org into C:\msys (without the usr/ prefix that is in the tarball, such that files end up as /bin/autoconf etc.). Copy /bin/automake to /bin/automake-1.10 and /bin/aclocal to /bin/aclocal-1.10. The -1.10 versions are just 0-byte stubs, but glib's autogen.sh calls them explicitely.
Then, rename the /bin/perl wrapper script and install the mingw-provided perl package. This is still 5.6, but it is enough for what we need, and the problems with paths in arguments seem to go away with this. Perhaps it would be enough to install ActivePerl directly so that /bin/perl.exe is the ActivePerl one.
Add gtk-doc stubs to your system. Most GNOME libraries (including glib and GTK) require gtk-doc, but I could not find any success story of getting it to work on Windows. I used the instructions by Hans Breuer:
You need a gtk-doc tarball from ftp.gnome.org for this.
Next, load svn-win32-1.4.5.zip (or a more recent version) from subversion.tigris.org, unpack the zip to C:\svn and add /c/svn/bin to the PATH in your ~/.profile. After a relogin or exec bash -l you should be able to use the SVN client in msys. Try getting glib via svn co http://svn.gnome.org/svn/glib/trunk glib.
The most hacky thing I had to do was changing the /bin/aclocal file. Add
Note that you need to adjust C:\/msys\/ if you installed msys elsewhere. Also remember to copy it to /bin/aclocal-1.10 (By the way, NTFS is capable of symlinks somehow, isn't it)? This is required so that aclocal converts paths starting with C:/msys/share/[...] to /usr/share/[...]. Both refer to the same file on disk, but since aclocal does a simple string comparison, it does not recognize this and always creates an empty aclocal.m4, causing autoconf to fail due to not finding any macros. Better solutions to this are very much appreciated.
Last, replace AM_CONFIG_HEADER by AC_CONFIG_HEADER in glib's configure.in. autoheader complains about the first. Quick googling seems to suggest that AM_CONFIG_HEADER is deprecated by AC_CONFIG_HEADER, but I am not sure. If that is really the case we should probably change glib.
Run ./autogen.sh and watch the magic.
So far for today, I am going to try GTK+ and glom tomorrow. Perhaps I even get to what I originally wanted to do, making the GTK+ recent chooser guess mime types on Windows. If you try these steps out and run into further problems, I would be glad to hear about it. I am especially looking forward to John Stowers' work on jhbuild on Windows. Building GNOME libraries and applications directly from SVN via jhbuild on Windows sounds really cool.