GNOME Bugzilla – Bug 147988
GtkFileChooser can't be used to open a non existing file
Last modified: 2013-06-17 00:39:43 UTC
When starting a new file in Emacs or Vi, one opens a new file that does not exist yet. The file is not created until it is saved the first time. The GtkFileChooser has no way to handle this common usage. If one specifies the action OPEN, there is no place to enter the new file name. If one specifies the action SAVE the text "Save" appears in the dialog, which is not appropriate. This can be solved by either allowing for OPEN to display a text entry field (bug 136541) and to return a file name that doesn't exist. Another idea is to add a new action (FILE_SELECT) that does the above, but lets OPEN behave as it does now.
IMO, this is simply an app design problem ... making the filechooser more confusing to support this isn't worth doing. If you want to create a new file, choose New, if you want to open an existing file, choose Open.
In Emacs, new and open is the same operation. The same in Vi. The app can not know if the user is going to choose a new file or an existing file, unless we implement some mindreading capability in Emacs. The current model in GtkFileChooser is too limited, it kind of assumes a MS Windows type of editor/application where New is different from Open. This is not so in traditional Unix applications.
The ability to open a nonexisting file seems to be, as owen says, just a quirk in the app design. What you are really doing is creating a new buffer. If you don't want the new buffer to visit an existing file, there is no real need to ask for the name of a (nonexisting) file until it comes to actually saving the buffer. And at that time, the SAVE mode is appropriate.
I don't think Emacs will change in this regard, after all it has behaved like this for a very long time.
It is a rather convenient behaviour for an editor and I am not convinced that adding another GtkFileChooserAction would necessarily add much complexity. Of course it would need a patch to actually show that it is doable with reasonable effort. Would such a patch be considered at least?
Perhaps it doesn't add much complexity to the individual app or to gtk itself, but the proliferation of file chooser modes will make the desktop as a whole more confusing. What would be the menu entry for a file chooser in this mode ? "Open..." indicates a file chooser OPEN mode...
No, "Open..." indicates open as defined by the application. What modes the file chooser has should not constrain what the application can do. In Emacs the menu entry is "Open file...". Have you never said "Open a new file"? Or do you say "Create a new buffer and then save it to a new file"? The phrase "open a new file" is not hard to understand and very common. I don't think there is risk for confusion.
Emacs & Vi were both "designed" before common UI conventions were adopted. That they have crude graphical adaptations does not belie their roots: their modern incarnations are adaptations of pre-Macintosh interfaces. This is not to say that they are inherently "bad", e.g. I agree with Jan D. that its not unreasonable to think of "Opening a new file". However, whether the idioms they have chosen are bad or not, emacs and vi are unusual because they don't use what are now prevalent UI idioms. Its shouldn't be surprising (nor is it bad) that widgets designed for use with modern UIs don't support what are effectively dead (or at least exceptional) UI idioms, esp. when those idioms have functional modern equivalents.
(In other words I agree with Owen that this is an app design problem: they are trying to get a modern widget to support a dead UI idiom)
How do other applications handle the case where a user wants to create a new buffer (document) and give it a meaningful name immediately? The answer appears to be that they don't, because doing so is an "app design problem" and a "dead UI idiom". The user must either perform an unneccesary Save As... operation to name their empty document, or they must remember what the automatically assigned buffer names "New Document", "New Document 2" etc refer to.
I would not like to call anything "dead" just because it is not common in most GUI based programs. By that reasoning, incremental search is "dead" since most GUI editors and word processors don't have it. But it is still superior.
Sorry, didn't mean to change severity, but isn't GtkFileSel the old file selector?
They share a component...
Seriously the style of UI supported by Gnome's dialogue currently seems essentially arbitrary, and just because windows doesn't do something doesn't mean it's "dead". Gnome should be flexible in allowing apps to work they way they want, if doing so doesn't require a lot of extra effort. From Jan's description it sounds like the effort involved here would be fairly minimal -- mostly a slight generalization of the existing infrastructure, so "complexity" doesn't seem like a valid objection. Gnome does have some interest in presenting a consistent interface across apps -- but that is a _goal_, and can never be an absolute, because sometimes There Are Exceptions. Apps like emacs or vi with long, long, interface histories predating anything Gnome is based on are an example; there are simply too many existing users, and too many existing applications/documents/etc (in emacs) using the current conventions to just write off the issue as an "app design problem". Sometimes such a clash of cultures results in irresolvable conflicts, but again that doesn't seem to be the case here; a Gnome file dialogue operating in the "emacs way" would be a perfectly reasonable union of the two styles.
I wrote: > This can be solved by either allowing for OPEN to display a text entry field > (bug 136541) and to return a file name that doesn't exist. > Another idea is to add a new action (FILE_SELECT) that does the above, but lets > OPEN behave as it does now. Actually we need a new action. Emacs allows open of both files and directories in the same operation. Open a directory just displays it in a dired buffer. A new action should allow for that, so it should be named ACTION_SELECT (i.e. select a file, directory or a non-existent file).
See this: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/userinput/commondialogboxlibrary/aboutcommondialogboxes/openandsaveasdialogboxes.asp Grep for "OFN_FILEMUSTEXIST" Also see this: http://doc.trolltech.com/3.3/qfiledialog.html#Mode-enum It doesn't look like the Mac OS X file chooser lets you select nonexistent files: http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/ObjC_classic/Classes/NSOpenPanel.html As much as I love Emacs, I see no reason to support its paradigm when creating new files. On the other hand, if someone cooks a patch to add a "file-must-exist" property to the GtkFileChooser interface and to the GtkFileChooserDefault implementation, I'll consider putting it in. I'm starting to wonder whether GtkFileChooserAction can result in combinatorial explosion: save or open, files or folders or both, existing or not...
I *think* MS Access needs a file name before it lets you create a new database, so that when you do File/New it opens a Save-like dialog. Just something to keep in mind.
If these requests: - opening existant or non-existant files - opening files *or* directories Could be worked into the current user interface in a non-intrusive way that was also visually distinctive from the current modes of operation I wouldn't really object to them that much. But I don't see how either really fits in; we've achieved real simplifications and user improvements by doing a design that doesn't have these options. I don't know about other people, but very frequently when using emacs I end up with a buffer with a new file called, say "gtkwidget." Because I hit return when the completion didn't fully work. And very frequently I end up in dired mode and have to kill the buffer. The "visually distinctive" part above is very important because it would be highly evil to have a file dialog that looked like the current one but when you clicked "Open" on a directory it openend it in dired mode rather than entering it. I'd really encourage thinking of this as "what would a user of GNOME and emacs expect to get when they type C-x C-f"? What would be most useful? - One the filechoose end: what if the dialog you got in emacs had [ New File ] [ Cancel ] [ OK ] as the dialog actions? Would it be useful to be able have the filechooser show a file as being "virtually" there but not actually on disk like the state of an unsaved emacs buffer? - On the emacs end: is it right to overload C-x C-f to enter dir-ed mode rather than open a new buffer? Is this just an artificact of not having a good file selector? Should there be a different command to open a directory?
> The "visually distinctive" part above is very important because it > would be highly evil to have a file dialog that looked like the current > one but when you clicked "Open" on a directory it openend it in > dired mode rather than entering it. Can you elaborate on why this would be "evil"? It is after all the current behaviour of other file dialogs used in Emacs, and there has been no bug reports on that. > I'd really encourage thinking of this as "what would a user of GNOME > and emacs expect to get when they type C-x C-f"? What would be most > useful? I would imagine that a lot of people that run Emacs don't run Gnome. But compiling Emacs with GTK is still attractive, as GTK can make Emacs look better (i.e. you can choose themes and get antialiased text in the menus and dialogs). > - One the filechoose end: what if the dialog you got in emacs had > [ New File ] [ Cancel ] [ OK ] as the dialog > actions? Would it be useful to be able have the filechooser > show a file as being "virtually" there but not actually on > disk like the state of an unsaved emacs buffer? I'm not sure I understand how this would work. Would pressing "New File" make the file dialog look like it does expanded in save mode (i.e. the input field and the file lists visible)? Or does it pop up a Ctrl-L like dialog? > - On the emacs end: is it right to overload C-x C-f to enter > dir-ed mode rather than open a new buffer? Is this just an > artificact of not having a good file selector? Should there > be a different command to open a directory? It is not an artifact of not having a good file selector. I presonally think the "file selector" Emacs has in text mode is very good. But the overloading is just standard Emacs behaviour that has been there for ages. There is a different command to open a directory (C-x d), or rather it opens what you give it (file or directory) in dired mode. That command is already available in Emacs menus and toolbar. We could probably make Emacs behave like GTK expects in the GUI parts (i.e. menus and toolbars) for opening files and directories. Menu/toolbar items like "Open existing file", "New buffer" could be added so "New buffer" just creates a buffer without a file name. This would then be different from what you can do in text mode or when using the keyboard, as C-x C-f is still there. I think that is an minor inconvinience. A more major drawback is that the GTK version of Emacs would then behave differently from all others. The big thing however is to handle other lisp programs/modes. Any lisp program can add menu and toolbar entries, and many do. Ay one of these entries can request a file/directory/non-existent file and many do (I counted around 180 occurences in the Emacs distribution). Some of these lisp packages are not in Emacs, but distributed by other authors separately. We would need a very good reason to break all of this, and I don't think the restricted model of GtkFileChooser is such a reason.
- Having objects that look the same but act different breaks one of the fundamental rules of GUI design. I'm trying to open a file in a subdirectory - in every other app clicking on the subdirectory and hitting [Open] moves into the directory - I should be able to predict that it will do the same in Emacs. If things start acting different in different places this reduces speed (I have to think what will do what) and increases error rate. - s/user of GNOME/user of GTK/ if that is more convincing. Seeing a GtkFileChooser raises expectations on the users part. If you dont' follow those expectations, the dialog has no value beyond screenshots. - I was imagining a C-l style ancilliary dialog. - If exactly matching "standard Emacs behavior that has been there forever" is a hard requirement, then how can you justify introducing a dialog that will have very different user behavior from the command line prompt, no matter what changes we make in GTK+? I assume the end goal is to make the user's experience better? - If you can't change every usage of read-file-name in Emacs (128 in 21.3), then maybe it is best to just change the ones that get used frequently to really do the right thing, and leave the others using the command line prompt? How do you specify the text of the accept button with the current read-file-name interface? What happens to the prompt string? How does the DEFAULT argument work? (Usually callers insert the DEFAULT into the prompt string so that that the user has some idea what is going to happen.) I don't see how you can generically turn a call to read-file-name into a file dialog and make it anything that the user won't want to turn off as quickly as possible.
> Having objects that look the same but act different breaks one of the > fundamental rules of GUI design. Yes it does. This is why GtkFileChooser has so many problems, it does not behave like other file dialogs, like Motif for example. It is also important not to break the expectation of Emacs users and users that are new to GTK. > Seeing a GtkFileChooser raises expectations on the users part. Probably, but what expectation? You are assuming they expect things to behave like in Gnome. I assume they expect things to behave as in other Emacs versions. After all, Gnome is just a small part of all GUI environments out there. > - I was imagining a C-l style ancilliary dialog. The current Ctrl-L dialog is very bad UI design and kind of slow. You should avoid adding more bad things. > ... how can you justify introducing a dialog that will have very > different user behavior from the command line prompt ... We are not introducing something, a file dialog has been there in the Motif version and the W32 version for years. The goal is to get GTK to behave like them. I was not there when this was made, but I assume the goal is to make Emacs more familiar to GUI users. > How do you specify the text of the accept button with the current > read-file-name interface? We don't. It is not important. Basically the default for the various file dialogs are used. In Motif that is "Ok". > What happens to the prompt string? Goes in the title. > How does the DEFAULT argument work? I assume you mean the default-filename? In the Motif file dialog box, it preselects that file. What it does on W32 I don't know, I haven't run that version. > I don't see how you can generically turn a call to read-file-name into a > file dialog and make it anything that the user won't want to turn off as > quickly as possible. Well, all you have to do is run Emacs on W32 or compiled with Motif or Lesstif to see how it works. I've seen many Emacs users that doesn't open files with anything else that the menu and/or the tool bar button and the file dialog that follows. They have not complained. But being Emacs, you can of course turn it off if you want.
GtkFileChooser doesn't look like the Motif file chooser. So, the expectation isn't there that it should behave in exactly the same way. But two instances of GtkFileChooser should behave in the same way. I don't see why popping up a dialog where the user can quickly type a new filename is bad user interface (I even proposed making it an explicit button in your dialog) More generally starting from the assumption that the GtkFileChooser dialog should be able to work just like the Motif file dialog (the Motif file dialog???) is not productive. Starting from the required API (read-file-name) and working backwards to what the user interface should do isn't something we can accomodate. If you want to discuss how we can improve the the way that Emacs user interface fits into the GNU desktop, how to make it use the GNU user interface toolkit productively, I think that's an extremely useful discussion. Please, read through the GNOME HIG (http://developer.gnome.org/projects/gup/hig/). See why rename-file shouldn't have an "OK" button. Why it *is* important.
> But two instances of GtkFileChooser should behave in the same way. As should two instances of Emacs. We obviously have different views of what is more important. > I don't see why popping up a dialog where the user can quickly type > a new filename is bad user interface (I even proposed making it > an explicit button in your dialog) An explicit button is a slight improvement, it doesn't hide it in an obscure keybinding, which doesn't seem to be mnemonic (what would L mean? Letters?). The Ctrl-L dialog (do you have a name for it?) obscures part of the file dialog, removing some of the information for the user. The user have to move it aside to see what is behind. It is not convinient to switch between keyboard input and browsing with the mouse, you have to pop down the Ctrl-L dialog and then bring it back up again. There is no correlation between keyboard input and what is shown in the file dialog. If I am watching src/ and hit Ctrl-L and type src/emacs/ I expect the file dialog to show src/emacs. It also introduces an extra mode for the user, and too many modes are bad (see Raskin for example). This mode can easily be removed by always having a text field visible in the file dialog itself, or showing it on Ctrl-L or the (proposed) dedicated button. > Please, read through the GNOME HIG > (http://developer.gnome.org/projects/gup/hig/). See why rename-file > shouldn't have an "OK" button. Why it *is* important. I've read it, it is not relevant. The HIG is a specification for Gnome applications. The goal is not to make Emacs a Gnome application, the goal is to make Emacs use a free toolkit (GTK+). And the "OK" button is not important. The HIG presents one view, which is just an opinion. It might be relevant if the users never seen a computer before, but I doubt that even then any difference in productivity would be measureable. Of course, that is my opinion. Any discussion on making Emacs in to a Gnome application must first start with the basic question, do we even want to do that? And the emacs-devel list is a better forum for that. The GtkFileChooser would be fine in ACTION_SAVE mode, if the text "Save in folder" was configurable rather than hard coded, and we could set the GtkFileChooser to pop up with the file list expanded. Granted directories would not be possible to open, I'll have to check the most common usages to see if that is something Emacs can live with in the GTK version.
Arguing here why you don't like GtkFileChooser isn't likely to help your case. See my mail to RMS that you are CC'ed on for more detail, but essentially, making Emacs a nice GTK+ application is something that the GTK+ team should be supporting. And can support, because there would be actual user interface design behind it. Making Emacs blindly a GTK+ application by making every read-file-name call pop up a file chooser dialog isn't going to make things better for users. If you get it going, great. But I don't see us making GTK+ enhancments to support that.
> Arguing here why you don't like GtkFileChooser isn't likely to help > your case. You are reading in things I've never said. I like GtkFileChooser, it just have a few problems, as does all file dialogs I've seen. > ... making Emacs a nice GTK+ application is something that the GTK+ team > should be supporting. Unfortunately making Emacs a "nice" (i.e. HIG compliant) GTK+ application would mean rewriting a lot of Emacs. And we probably either loose a lot of cross platform ability in the process, or end up with two separate Emacsen, one GTK+ and one for the other platforms. This is actually what I started to do, but it was descided that code that works with several platforms shall work for the GTK+ port also, to keep the amount of code we have to support smaller. > Making Emacs blindly a GTK+ application by making every > read-file-name call pop up a file chooser dialog isn't going to > make things better for users. You are blowing this bug report out of proportion. This is just a tiny detail on the GTK+ port of Emacs. If you don't want to change the file dialog, that is your call, but in no way does that mean that Emacs won't have GTK+ support in other parts.
Is this now a private e-mail discussion? How can I or any others follow it?
Nothing technical (or for that matter all that interesting) is being discussed in email beyond what was said here. I just didn't want to repeat what I said in that email about how I thought the emacs and GTK+ teams should be working together completely since Jan had already seen it. I'm not suggesting a complete rewrite of Emacs to make it a totally HIG compliant application. What I am suggesting is that of the two axes: Terminal Emacs -------------- A ------------------> Motif Emacs | | B | \_/ HIG Emacs I think it's much more useful to have a GTK+ port of Emacs that moves part way along axes B than all the way along axis A.
> I think it's much more useful to have a GTK+ port of Emacs that moves > part way along axes B than all the way along axis A. If it only was that simple. Emacs is more like this: --------------------------- | core functions (no GUI) |---> terminal version -------------------------- | X11 | Mac | W32 |---> W32 version | ------------ |_________________________| | Xt | | | | | | -------------> Mac version 末末末末 ------------------> X11 version (no Xt or other toolkit) | | | -----------------------> Motif/Lesstif version ----------------------------> Lucid version The Mac and W32 versions actually use some of the X11 part by emulating some X11 functions. So where is the HIG Emacs axis? Well, the core should remain the same. But can it? In the core are stuff like timer and signal handling, and the event loop. Just integrating GTK without changing Emacs event loop was a big problem, as GTK+ wants to deal with signals and inputs by itself. And how about internationalization? GTK+ wants to use Pango and UTF8, Emacs has another model (MULE), and isn't fully UTF8 (work is ongoing on that). Next X11. It contains the redisplay engine that draws all the text. Shall we replace all that with GTK+ routines? Preferrably not, it will be difficult to maintain. Ditto for font, image and colour handling. So currently GTK+ sits beside the Xt box in the figure above, using much of the X11 and core functions and just doing GTK+ stuff for the GUI parts (menus, toolbars, scrollbars, dialogs). It also shares some stuff with the Xt part. The GUI parts are controlled by the core part, so if Emacs is going HIG compliant, the core *must* be modified. And then the W32, Mac, Lucid, X11 and Lesstif/Motif version either have to change also, or HIG Emacs must be a separate version. There just is no "axis" to talk about, unfortunately HIG is an all or nothing approach. That is why I asked earlier, do we even want to do an HIG Emacs?
Of course, a patch to implement something like the FILEMUSTEXIST flag is welcome.
WONTFIX due to lack of interest. Please submit a patch with a reasonable API if you care about this.
I'll take this one. It's not of the FileChooser's really bad features.
All the API needed for this is a property. If no-one objects to that statement I will remove API keyword and move to a non-API milestone.
Isn't adding a property still an API issue? It doesn't change anything that a C compiler would catch, but strings can make up an API -- an application that makes use of the property would work with new versions of GTK but not old ones.
What I don't understand is: The GtkFileChooser currently _does_ allow me to provide a non-existing filename when in open mode. And I think that's a bug.
I've confirmed Murray's comment from 2007, testing with GEdit shows filechooser does allow non-existing filename in open mode.