GNOME Bugzilla – Bug 138260
Enh: XDS support for GtkFileChooser
Last modified: 2005-03-27 20:59:25 UTC
It would be really nice if GtkFileSelector supported XDS by default, by having a file icon displayed that shows the icon corresponding to the current save filetype. XDS is described here: http://www.newplanetsoftware.com/xds/ I had heard that the GTK-2.4 file selector would support this, but I can't find any recent discussion of this. XDS makes the desktop much more usable, because open file manager windows are useful for saving (and not just loading) files; and because you can drag-and-drop to other applications, without having to save to intermediate files. It would be nice if it were supported in all applications by making it a standard feature of the File Chooser dialog, and then using the GtkFileSystem mechanism to actually wrap the XDS protocol, so that it is transparent to the application. Thanks!
N.B. It appears that this was the idea behind the file icons shown in the screenshots at the bottom of Seth's page: http://www.gnome.org/~seth/filechooser-spec/ This is a nice idea -- combining the file type selection widget and the file icon. (N.B. It might be nice to actually show the file extension that will be appended after the "Name" field, too, to show the user that what they type in will have an extension added to it -- that's a separate issue from XDS, but it is tied to setting the correct icon type, based on the save file type.)
See bug #51051 for the original request in GtkFileSelection. I'm not marking this as duplicate because this refers to GtkFileChooser.
Note that the purpose of XDS is to remove file chooser dialogs altogether. I don't think it makes sense to put a drag-thingy in GtkFileChooserDialog; that thing should be in the application's document window.
I agree that the purpose of XDS is to remove file chooser dialogs. But should each application have an XDS drag source icon always visible? That doesn't seem to be a good UI design (it doesn't tie the icon to what is going to be saved -- e.g. if there is a selection, does the drag source icon now only save the selection, or the entire document? There needs to be more feedback.) You get more of a conceptual tie between the icon and the document contents if the user intiates a save action, which pops up a window with an icon in it. Perhaps the default save-mechanism could be XDS, and there could be a "turn-key" icon that opens the "Save in folder" combobox, and then another one that opens up "Browse for other folders"? That seems like a natural progression to me, even though it introduces an extra step if you want to browse for a directory. Having XDS saving as a default is actually really nice when you have a file manager that supports it -- it makes the file manager a much more integral part of the desktop experience, because users are more likely to actually use the file manager. If there was a hide/unhide icon for "Save in folder", then once the folder widget is shown, the XDS icon wouldn't be needed any more, so it could be greyed-out.
Federico - If you don't think that there should be a drag icon in the file chooser, then shouldn't we resolve this bug? (And if you don't want to reinterpret 51051 to refer to GtkFileChooser, then it certainly needs to be WONTFIX'ed)
Whether or not it's in the file chooser, I believe there should be a toolkit-supported mechanism for adding XDS support to an application, so that apps don't all do it differently, and in fact so that apps don't even have to implement anything special to support it (as long as they support saving to an arbitrary GtkFileSystem). Perhaps some usability studies could be done to figure out the best way to accomplish this, UI-wise, and to see if having the icon in the FileChooser is actually a bad thing for the user? As a qualifier, I used a real OS with XDS-like saving for several years (Acorn RISC OS), and it really does increase your productivity, especially when you can drag-save between applications. If an XDS icon isn't included in the File Chooser, I hope this feature is not just forgotten about, but that an alternative toolkit-level mechanism is provided to give all GTK apps this functionality.
Indeed this needs discussion, but the file chooser is not the place to put the XDS icon. Please feel free to take it to the usability@gnome.org mailing list. GtkFileSystem is an internal API and is not visible by applications. It is not a VFS for general use; it is just an internal abstraction for use by GtkFileChooser.
*** Bug 140228 has been marked as a duplicate of this bug. ***
As a slightly related remark, GIMP in CVS does now support XDS and allows to save files by dragging out of the Images dialog or from the active-image preview in the toolbox. Now all we need is a commonly available file-manager to accept these drags...
IMO it does make sense to add an XDS save icon to the file-chooser. XDS doesn't work for unnamed documents, it seems to require a leafname (basename) to be specified. The file-chooser provides an entry to set the filename. It would thus be a good place to add a source for XDS drags. May I reopen the bug-report if I provide a patch that implements this?
I agree that the File Chooser is the best place for the XDS icon. The reason is that every program that can create and save a document of some form implements a call to the File Chooser API. Saving, whether by drag-drop or by using a File Chooser window, should be initiated by the same action from the point of view of the user. Otherwise you have two very different ways of initiating a file save operation. Also, every program has to come up with a way of saving (e.g. GIMP uses image preview icons; what would Inkscape uses, given that it doesn't have the equivalent of an image preview icon anywhere? What about gedit, which doesn't even have the concept of an image preview?). The number and variety of "solutions" that different developers produce for their own program could get out of control, GNOME-1.x-style. It would also be nice to actually see the icon of the file type that is being saved in the Save dialog, as a visual reminder as to the format the document is being saved in. The user would not even have to know that the icon was draggable, but they could drag it if they knew it was. Alternatively, there could be a button in the Save dialog that says something like "Drag-save", that closed the Save dialog and opened a smaller window with a file icon and filename field in, from which the XDS save could be initiated. However I like the filetype icon being in the Save dialog itself, as it serves additional purposes there, indicating visually what the save format is.
BTW, the file-chooser spec as refered to in comment #1 moved to http://www.gnome.org/~seth/designs/filechooser-spec/