I think this is an interesting idea, but fundamentally there are enough differences between the two that the costs would outweigh the benefits in the current situation.

An Open File Dialog returns a value - the URI of the file selected - and blocks input to the program creating it until the user clicks OK. A nautilus window could not be opened trivially in this way since it would be an entirely new process rather than part of GTK+. Furthermore, it would make nautilus necessary for the use of GTK+ even on platforms such as OS X, Windows, KDE and XFCE which would constitute bloat.

A nautilus window is typically for file management (moving, deleting, cutting, editing) than opening with a given program, and takes up more memory, screen space, and is more complex as a result. This complexity is unwanted if a user is just modifying files. Indeed, an open file dialog is tied far more closely in its purpose to a save file dialog than a file management window - and the former requires the ability to specify a new name for a file.

I appreciate the benefits of interchangeable skills between file manager and file dialogs, but in the current state of both of them I don't think this would make sense.

Mejogid,

Thanks for the discussion and helping me brainstorm. I enjoyed your opinion. You seem quite knowledgeable. Do you program for a living? I certainly don't.

You said "An Open File Dialog returns a value - the URI of the file selected - and blocks input to the program creating it until the user clicks OK."
I don't think that either of these are more than customary. Why can't "Open" leave the main window unblocked? Why must the open dialog return anything to the application (it could just open a file with the corresponding application). There's not even any real reason why "Open" within one application can't be used to open files for other applications, is there?

Later, you insightfully said "Furthermore, it would make nautilus necessary for the use of GTK+ even on platforms such as OS X, Windows, KDE and XFCE which would constitute bloat."
This problem is what I meant to address by "the file manager respect[ing] some basic switches to limit the types of files that are displayed to those that are supported by the calling appliction [sic]." If there were a specification for the behavior, any file browser which supported that spec would work as an Open dialog. (I am, however, a big fan of having some real dependencies for applications, meaning that I don't think that heavily cross-platform apps can be nearly as integrated as single-platform apps.)

I agree that the Save dialog can't be easily implemented the way I've outlined (though I'd be interested in ideas of how to do it at all), but I don't see any need for the Open and Save dialogs to be related in form since their functions aren't that similar. File managers and Open dialogs share finding (and manipulating) files. Save dialogs are for placing and initial naming of files.

Ultimately, this post was part of my planning process for the tag-based file browser I'm going to try to initially push out in a couple of months. For that project, I'm trying to question some very basic assumptions about how files are managed, both in applications and out of them.

Any further ideas or disagreements are welcome.

Dan

I have posted a response on my blog since it turned in too long rant (more than 4096 characters). Hope that isn't a problem. Feel free to respond either here or there.