See also http://gnomesupport.org/forums/viewtopic.php?t=10833

Something is broken in the code that picks a good size.  It tries to use a window height of around 40 lines in the default font size, but that's obviously not the end result.

I'm having the same problem. Whenever I save a file, for example while downloading some file from Firefox, I get this so small 'file chooser window' size :(, it's really annoying.

I think that appart from being much better calculated the default size based on the screen resolution, it should also let the user define a _custom default_ window size and remember this setting forever; this would be great. Hope to see this bug/feature solved soon. Thanks!

*PING*. Sorry for hurrying, but it's really annoing thing to resize the same window  50x a day?

Yes, really it is; at least some of us agree regarding this problem. This is a major annoyance for me.
Hope someone fixes this very soon!.

There are various sizing bugs that need to be fixed at the same time:

- bug #151169 ("file chooser up too big")
- bug #143213
- bug #167189
- bug #153785
- bug #300334

and probably others.  We are not ignoring you; it's just that I don't have free time right now to fix this.  An analysis of the sizing bugs would be very much appreciated.

Can I help with something?

Created attachment 76151 [details] [review]
patch, fixes several issues

Hi!,

I've done a small patch that fixes several issues in filechooser resizing, here's my report on the mentioned bugs:

* This one: improved, the window height is now slightly bigger, but the size request now takes into account the extra widget. Without this patch, the default size is guessed forgetting the extra widget, and when the dialog takes the default size it's told, the extra widget makes the navigation pane quite short. This is a quite widespread problem, as many apps add an extra widget.

* #151169: The file chooser was already told to shrink to 3/4 of the screen when the filechooser was bigger than the screen size, should be closed.

* #143213: this patch fixes this, there was a gtk_paned_set_position() call that made the shortcuts pane wider than it's minimum size, which is (IMHO) enough for  it.

* #167189: needs further investigation, seems like a size request/allocation events confusion. Maybe adding here a low priority idle handler to show the preview would help, showing hundreds of previews when scrolling fast definitely serves no purpose.

* #153785: Fixed by this patch, sets the window geometry min_width to the contained filechooser default size when it's in "save" or "create folder" modes.

* #300334: needs fixing in GtkPathBar, I'm going to work on that next, will attach the patch there.

I made a patch to write additional informations into the config-file ~/.config/gtk-2.0/gtkfilechooser
  <minimum_width value="1000"/> 
  <minimum_height value="700"/>
  <open_browse_expander value="false"/>
Which defines a minimum-size when the directory-browser is opened. The option 'open_browse_expander' defines whether to open the browser by default. One could add an popup-menu-line to save the values. ("Remember window size" or so)
You can find the two patches together with ubuntu-edgy-packages at http://www.fx5-1.de/~fx5/gtk/

*** Bug 385011 has been marked as a duplicate of this bug. ***

I've committed Carlos patch

Hi,

I just compiled GTK+ from SVN trunk, i still see problems in the sizing, actually it is worse than before for me, the size of the window is the same as before the only thing that changed after the patches is the place where the spliter is presented, this time the directories and devices pane is way too small.

See also bug #418585, which caught a stupid bug in the auto-sizing code.

i tried GTK+ SVN trunk today, the dialog seems bigger, however the splitter is as annoying as the last time, too small to see the description of the devices, i have to move it to be able to see the devices and bookmarks properly.

Here's a small hack to have a bigger (usable) window.
Edit your ~/.gtkrc or one of your used theme, go to section "Default", and add :
GtkScrollbar::min_slider_length = 100

You can adapt default size changing the value, 100 is enougth for me.

*** Bug 420616 has been marked as a duplicate of this bug. ***

I'm running GNOME 2.18 under Ubuntu Feisty Fawn and this bug is still present, here's a screenshot:

http://img120.imageshack.us/my.php?image=screenshotsaveimageea9.png

I'm switching in a couple of weeks from a resolution of 1280*1024 to 1680*1050 (new monitor arriving) so my user experience will be yet worst :(

I hope to see this bug fully fixed soon (comemnt #14), this is taking so long..., first report was posted at the beginning of 2006.

Best regards!

Same here on a fresh install of Ubuntu Feisty, highly annoying, especially the "Save As..." dialog which only shows two files at a time by default.
Guillaume's "hack" gives a little relief though.

I've tried creating a ~/.gtkrc file but didn't work, where should I put Guillaume's hack ?  Thanks.

I had a file called .gtkrc-1.2-gnome2 in my home directory, this contained a link to the file: ~/.gtkrc.mine

If this is the same for you, create the file ~/.gtkrc.mine and put Guillaume's hack in there.

Thanks for your answer, I already had those files but it doesn't make any difference (logged out/in), ie: when I try to save an image from firefox the window is as small as my screenshot from post #17... I keep getting that _unusable_and_highly_annoying_window. 

PS1: IMHO this bug is wrongly classified, 'Severity' should say 'Major' as per the definition: "Major loss of functionality- menu item broken, data output extremely incorrect, or otherwise difficult/useless to use." and the 'Status' probably is also wrong, this bug has been reported a long time ago.

This bug seems to be resolved with gtk+-2.10.13, at least on gentoo

And it seems to be resolved on Fedora 7 with gtk2-2.10.13-1.fc7.

Actually, some of the open file dialogs are now so big that it might need a little tweaking.  For example, the dialog for opening files in the gimp is 1000x525 pixels (on a 1920x1200 display).  How is this going to affect people on smaller display resolutions?

It seems to be depending on screen resolution ratio, actually a good thing AMHA

This has to do with Compiz (seen in Ubuntu). See https://bugs.launchpad.net/compiz/+bug/75324.

This Compiz part of the bug has just been fixed (see http://bugs.opencompositing.org/show_bug.cgi?id=839).

This should deal with the bug described for example from comment #17. Is there any reason to keep this bug open? Making this bug stuff cleaner would be nice, here we have too many issues (a sheer metabug would help).

I think that's been fixed by Federico's patches in 2.16. If you still experience the precise issue of the dialog being too small *on high resolutions*, please feel free to reopen.