I noticed in a Slashdot rant[1] that somebody actually made a good point about
GtkFileChooser.  Specfics include:

   Using the file chooser is PAINFUL. You just have the name,
   and the "modified" field and a list of favourite locations.
   You can't even order things by SIZE.
...
   Using the file chooser is PAINFUL. You just have the name,
   and the "modified" field and a list of favourite locations.
   You can't even order things by SIZE.
...
   Forget about things that have sense, for example video
   thumbnails, something that has a LOT of sense if you're
   going to open a video file in a video editing program.

The most interesting thing was that the poster alluded to a potential solution:

   The funny thing is that nautilus can do all what your need
   and will give you even thumbnails of videos and even of
   some .swfs with totem-gstreamer + libswf but the decided to
   go with this completely useless file selector.
...
   Compare it with the KDE file selector, where I even can
   watch the video.

Perhaps it would be possible to reuse the nautilus codebase by giving a two-view
mode to the GtkFileChooser dialog, with one view behaving strikingly similar to
Nautilus.  This would make the GtkFileChooser widget depend on libnautilus of
course.  The UI changes would mainly be in the file list area of the
GtkFileChooser dialog:

 ===============================================
|% Home       |[ ][home][shared](files)         |
|# Desktop    | --------------------------------|
|$ usbdrive   ||Name               |Modified|[^]|
|-------------||----------------------------|| ||
|@ files      ||text.odt            04/04/02||*||
|@ music      ||our_target.ods      01/02/06|| ||
|_____________||area.odp            03/13/05|| ||
|[Add][Remove]||____________________________|[v]|
|                             [X Cancel][@ Open]|
|_______________________________________________|

  Fig. 0-1:  Our target area is obviously hinted by
             the file names

Conceptually, the icon size in "Nautilus mode" would be large enough for a
preview, perhaps the size of 3 lines.  This would preview images, videos, Web
pages, text files, etc.  A "Zoom" button could enlarge this.

 ===============================================
|% Home       |[ ][home](photos)          [C](N)|
|# Desktop    | --------------------------------|
|$ usbdrive   ||Name               |Modified|[^]|
|-------------||----------------------------|| ||
|@ files      ||%%%                         ||*||
|@ music      ||%%% doggy.png       01/02/06|| ||
|_____________||%%%                         || ||
|[Add][Remove]||____________________________|[v]|
|                             [X Cancel][@ Open]|
|_______________________________________________|

   Fig. 0-2:  Notice the selected "N" for
              "Nautilus mode."  The "C" button
              sets "Chooser mode."

Also conceptually, passing the mouse over the thumbnail itself could enlarge the
thumbnail by 100%-200% (i.e. 2-3 times bigger).  See the Firefox extension
BetterSearch[2] for an example of this.

Hovering the mouse over the thumbnail itself for a set duration, i.e. 3 seconds,
could pop up a transient preview popup with limited UI; this pop-up would be a
non-managed window with no title bar or controls, and would vanish when the
mouse left it, similar in visual aspect to the Firefox extension LinkPreview[3].

As for the Preview pop-up, it could be fairly large; a quarter the screen size
is conceptually feasible.  This is 200 pixels across assuming 800 pixel wide
resolution; in larger resolutions such as the more likely 1024x768 or 1280x1024,
200 is probably still sufficient.

This pop-up would also need its own interface.  For movies it should play the
movie, with a slide bar at the bottom to allow the user to seek; this likely
should be accompanied by a "Play" and "Pause" button.  Audio preview in this way
would be just the media interface.  In all cases, pictures, video, and audio,
the pop-up should vanish when the mouse leaves it; this is easily learned behavior.

As for text such as HTML, this should be rendered into the pop-up, possibly
scaled down much.  It is unclear to me if allowing the selection of text in a
preview is important or good; however, if it IS allowed, then the preview pop-up
should definitely not be designed to dissappear on click in any context.

Potentially, a small "X" in the top-right corner could force the preview pop-up
away; but this would be counter-intuitive to learning that the pop-up vanishes
when it loses the mouse.

 [1] http://linux.slashdot.org/comments.pl?sid=177336&cid=14715201
 [2] http://bettersearch.g-blog.net/
 [3] http://patsis.brownhost.com/extxpi.html#linkpreview

Other information:
Some of these interesting behaviors could possibly be cross-ported into Nautilus
itself.  The preview pop-up with regard to audio would behave like Nautilus
audio preview on mouse hover does, but with a visual component.

In [3], there is the text:

  Install LinkPreview (Version 2.1)
  View ScreenShot

Hover the mouse over "View ScreenShot" to get a feel for the nature of the
"Preview pop-up" described here.