HOME | RED GREEN BLUE YELLOW

What I think is wrong with the Gnome filechooser

Written on 26.09.2004

This page describes my ideas about the gnome filechooser as it appeared (I believe) in Gnome 2.4. To be more specific - what is wrong with it. Maybe someone will find my ideas useful.

The Filechooser

I believe in the usefulness of the filechooser. It may be that it is a relic from times when computers did not do multitasking and every program had to be a filemanager as well (You remember the days when every application had its own PPP stack. Well - sort of like this), but people have come to expect it and it does on specific job: helps you open or save a file. A filemanager is a larger beast that does a thousand other things as well, but mostly the difference is that:

To act on a file, you have to choose it as well, but that is not what the filemanager is ultimately for.

So while I like some concepts of the ROX Desktop, I do not believe that the filechooser should be dumped. In fact, I believe there are several accessbility issues speaking for the filechooser as well.

Ok, this much about theory.

The Gnome implementation

The following images (click to enlarge, same window) show the Gnome filechooser as seen in Gnome 2.8 on Debian unstable:

Gnome Filechooser (File Opening mode)
 The Gnome filechooser as used in gedit used to open a new file.

Gnome Filechooser (File Saving mode)
 After typing a few characters and clicking the "Save" button, the filechooser appears again, this time in "Save" mode.

So what's wrong?

First of all - notice that by default the location is "Home". the problem is not about the specific location - "Home" is fine, it is rather about ease of navigation. While there are people who keep all their files in one directory, this is hardly the general scenario. In most cases, users have their own directory hierarchy and need to browse to another place.

Part of the current solution is to allow the user to define bookmarks and remember the last few directories used. If you look at the following screenshot, you will see a list of volumes and two directories. The latter are bookmarks I defined myself:

Gnome Filechooser (Volumes and Bookmarks)
 Bookmarks allow you to jump to directories quickly.

While bookmakrs are undoubtedly a powerful feature that adds a lot to the current implementation, they are not the solution to easy navigation. The main reason is that it is an extra layer and needs user input. Because of the former, bookmarks will:

  1. Never cover all possible situations. sooner or later you will need to save a file into a directory that you have not bookmarked. Bookmarking all directories would, on the other hand, destroy the whole purpose of bookmarks.
  2. Get out of sync. People rearrange their directories, delete them and add new ones.
The latter (requiring user input) is probably bad because it creates complexity where it is not needed and most users stick with the defaults anyways.

So again - bookmarks are a good idea, the current implementation works very well, but they are not a replacement for an intuitive filebrowser, which the chooser is all about. Of course everyone understands this and I mentioned bookmarks just so that no-one could say - "that is what bookmarks are for". I know them, but for what I want to do, you need something more. Like the built-in filebrowser that opens when you click on the little triangle to the left of "Browse for other folders:


 Clicking the trianle will enlarge the filechooser and reveal a filebrowser.

The first thing wrong with this picture is that the bottom of the filechooser window is level with the bottom of the screen (My iBook uses 1024x768 and the application is maximized). While this does not hide anything from view (KDE is notorius in my book for creating windows unusable at 1024x768), it does look very unprofessional.

The other problem is that when you click a triangle, you expect the window to expand vertically. If you look at the screenshot again and compare it with the previous one, you will see that the window expands horizontally as well.

The Red, the Blue and the Yellow

But OK - these are minor details, that nevertheless look unpolished. My main concern is with the layout of the filechooser. I have highlighted all problematic areas in the following screenshot:


 I obviously have some problems with the current desgin.

Lets start with the red (designated as 1.) area. This is the filebrowser itself. Remember - unless I am totally mistaken, choosing a location or a file is the main job of the filechooser. Lets do some math here:

  1. The width of the whole window is 573px and the height is 470px
  2. The area of the whole window is therefore 573px x 470px = 269 310px2
  3. The width of the area with actual files on it (Red outline, 1.) 340px and height is 150px
  4. The area of "1" is 340px x 150px = 51 000px2
  5. 51 000 is 19% of 269 310
Why does the primary function of the expanded filechooser get only 19% of screen real estate?

Who does not like counting percentages, look at it this way: There are only five items visible.

I am aware that some space is taken by application-specific extensions. In this case, gedit adds the "Character Coding" menu. Nevertheless - extra options is the norm, not the exception, and the filechooser must accommodate them while still leaving room for actual files.

Next the blue (Designation 2.). The blue areas point out the space that has simply been unused. The higher one has an area of approx. 345px x 35px = 12 075px2. The lower one measures 225px x 35px = 7 875px2 and they total to 19 950px2. That is 7% of the whole window. Doing nothing.

I understand that spacing and padding are essential for an aesthetic interface. The two areas I have highlighted are not that, they are - as far as I understand - unused space.

The yellow (Designation 3.) part is the most internesting and to me outright nonsense:

  1. These areas duplicate each other. Duplication is needed when accessability requires it, but in this case - I do not see how choosing from a popup menu is much different from choosing from a list. Depending on how you use your mouse (provided you use one), you needen't even click more for the menu.
  2. In this case however, the duplication is most definitely not for accessibility concerns, because the menu is grayed out. It cannot be activated - it is not meant to be used. And it wastes 550px x 45px = 24 750px2 room in the window.

Because the menu and the left-side list duplicate each other, while one of them is unusable, it would be just as well we get rid of one. Because the menu is used in the non-expanded version, we have to keep it and get rid of the list. 202px x 185px = 37 370px2. That is another 14% that can be used elsewhere.

Adding the 7% from free space, 14% from getting rid of duplicate entry and 19% that we had before, we now get 40% for the browser. While calculating square pixels should be taken with a grain of doubt, I hope I have demonstrated that:

  1. The current implementation wastes space at the expense of the most important function
  2. It would be quite easy to overcome these shortcomings

My dream fileselector

I don't actually dream of fileselectors.

If I did, I wouldn't tell you about it, because I am guaranted to get a lot of hate mail and accusations of being a KDE-lover. I don't love KDE, reserving such feeling for entities capable of more empathy. And horizontal scrolling is not for me.

But if I did dream about, and told you about it, I would:

  1. Make the pop-up menus shorter. While Linux supports rather long filenames, they rarely get used
  2. Get rid of the duplicate "Volumes and Bookmakrs" list as described above and use that for the familiar two-pane filebrowser. Directories on the left, files on the right.
  3. Stick a nice document icon somewhere. It would fill two purposes: give instant feedback when selecting a file type and serve as a drag handle for those ROX fans ;)
  4. Get rid of the "bradcrumb" buttons that allow you to move backwards in a directory tree. That space could be used for buttons: Up, Down, Add Bookmark (yet more space for the browser), Create directory, Rename. Maybe something else I havenät thought of
If anyone is really interested, I can draw a rough mockup.

I can be contacted at lemmit@kaplinski.com

Relevant bugs in Gnome bugzilla

143211 the filechooser widget size of gtkFileChooser is too small

145121 GtkFileChooser should accept file DND

135901 Save dialog should have a drop-down for file types (Interesting to note that the spec linked from that page actually has the document type icon in it)

136307 expanding save mode results in part of the dialog offscreen

151169 Filechooser comes up too big (Just as I thought - the current implementation is unusable on 800x600 resolution)

153785 Filechooser expands horizontally

153828 Filechooser does not remember state

If you know others, let me know