GNOME Bugzilla – Bug 29087
Rework GtkFileSelection widget
Last modified: 2011-02-04 16:12:26 UTC
Package: gtk Severity: wishlist Version: Synopsis: Homebutton Class: change-request Distribution: Red Hat Linux release 7.0 (Guinness) System: Linux 2.2.16-22 i686 unknown C library: glibc-2.1.94-3 C compiler: 2.96 glib: 1.2.8 GTK+: 1.2.8 ORBit: ORBit 0.5.3 gnome-libs: gnome-libs 1.2.4 libxml: 1.8.10 gnome-print: gnome-print-0.20-8_helix_1 gnome-core: gnome-core 1.2.2.1 Description: It would ber nice to have a homebutton in the default opendialog. Like the create dir. Cheers Daniel ------- Bug moved to this database by debbugs-export@bugzilla.gnome.org 2001-01-27 14:48 ------- This bug was previously known as bug 29087 at http://bugs.gnome.org/ http://bugs.gnome.org/show_bug.cgi?id=29087 Originally filed under the gtk+ product and general component. The original reporter (danfr527@student.liu.se) of this bug does not have an account here. Reassigning to the exporter, debbugs-export@bugzilla.gnome.org. Reassigning to the default owner of the component, gtk-bugs@gtk.org.
Let's put all these file selection requests-for-enhancement that would be significant changes to the current widget under one bug.
Put all GTK 1.3.x bugs on 2.0.0 milestone
Setting API-affecting bugs to the API freeze milestone
*** Bug 17114 has been marked as a duplicate of this bug. ***
Not happening for 2.0
Created attachment 326 [details] [review] Various binary-compatable enhancements
The above patch does a few things to make GtkFileSelection better: * Removed the redundant label above entry * Multiple, sortable columns in the CList * _Configurable_ columns * With #ifdef'ed gnome support, gnome-config support and support for a column with mime types and scaled-down icon images * A 'go to home directory' button * Tooltips It is also binary compatable with the old one, so there would be no problems using it for existing programs. If build as an .so, it can be LD_PRELOADed in fine.
*** Bug 82233 has been marked as a duplicate of this bug. ***
See thread starting at http://mail.gnome.org/archives/gtk-devel-list/2002-March/msg00179.html
*** Bug 82791 has been marked as a duplicate of this bug. ***
Bug 82791 asks for the capability to make a "select multiple directories" dialog; I don't think this is suitable as a short-term addition to the current dialog, but "directory selection" is something that should be considerd for the new widget.
*** Bug 93818 has been marked as a duplicate of this bug. ***
*** Bug 92769 has been marked as a duplicate of this bug. ***
*** Bug 98643 has been marked as a duplicate of this bug. ***
Move bugs which are tracking planned 2.4 features to the proper target milestones.
*** Bug 104269 has been marked as a duplicate of this bug. ***
can we add sorting files in the directory date/filename/type to the wish list here?
I don't understand why filedialog from http://home.wanadoo.nl/sbm/ still not in gtk/gnome ?
That dialog is a mockup, no one has implemented it yet.
I'd propose to add charset-encoding selection feature in both open and save if not been proposed yet.
In case the mockup is a model for implementation: Please rename "Open file" in the Save File dialog, to "Save file". Please put the "File type" combo list before the "Emblem" one. Filetype is selected more often than emblems are assigned. Please rename the "Add folder" button to "New folder..." or "Create folder..." -- those seem more clear. The ellipsus hints that more actions will follow after the button is clicked. Consider replacing the "Emblem" list with a list of views: detail (as in the current mockup), or simple icons. A simple view is preferable when detail is not needed. For most file dialogs, folder selection controls are above the filename textfield. The only exception I know is MacOS X. It seems better to follow conventions, unless there are considerations to the contraty. But I think most users choose where to put or get their file before they think about its name. (Also, I think they only use the filetype filter to check what other files of the type to be saved are already in the current directory.) To reduce clutter, consider making the description of each combo list be the first list item. For example, the first item of the Emblem list could be "Choose Emblem..."; there would be no "Emblem:" text label, and it would be understood that selecting "Choose Emblem..." means that no emblem is chosen. As far as I can see, this would not violate the HIG. Perhaps it would help to have filetype icons in the filetype combo list.
*** Bug 105470 has been marked as a duplicate of this bug. ***
Owen Taylor <otaylor@redhat.com> has published a detailed description of the requirements and a preview on a possible future API: http://people.redhat.com/otaylor/fosdem2003/file-selector.html regs, Chris
*** Bug 109926 has been marked as a duplicate of this bug. ***
Adding an entry for hiding "." and ".." entries and instead have "refresh" and "up" buttons. Refresh might also be done automatically on non-NFS filesystems by stat'ing the dir. Also should allow hiding dot-files -- most of the time the user wants a non-dot file and would have to scroll through them, esp. in the home dir.
Just a question (not a troll): Is anyone seriously looking at adding XDS to the Save dialog? http://www.newplanetsoftware.com/xds/ (linked to from freedesktop.org) This pages says "Coming soon" under GTK+ -- but has the API been designed with XDS in mind? It is a very useful functionality to have in a save dialog, since you can now use your save dialogs with the file manager windows that you already have open, without having to re-navigate to the directories that you can already see on your screen in some file manager window. It is also a useful feature to have working between applications -- drag-save to another application works like cut-n-paste. Thanks..
Any news about new fileselector ? In GTK 2.4 release plan (http://www.gtk.org/plan/2.4/) I see this: "1 June 2003 All major features are in" News fileselector is a major feature. Does anybody work on this ? Is this now in CVS of GTK+ ?
I just did an apt-get upgrade in debian/sid and have a new file selector which is just great! I don't know where it came from, but it's very nice. mike
Maybe Debian integrated the Ximian filesel hacks. I don't know. No modified file selector is or will be supported by the GTK+ team; the GTK+-2.4 file selector doesn't attempt to fix the current file selector, it is a completely new API.
After a little research, that's precisely what happened -- the debian maintainer applies the ximian patch (and I love it!)
Re: the comment from Owen Taylor, Where is the new widget? Are there at mockups/screenshots available?
There aren't screenshots that reflect the final user interface available. Most of the work so far has been on API and internals. http://mail.gnome.org/archives/gtk-devel-list/2003-March/msg00324.html http://people.redhat.com/otaylor/fosdem2003/file-selector.html
Hongli Lai has written a patch for gtk+ 2.2.2 which improves the existing fileselector's interface and usability. Sofar it works without problem, even Gimp (and the preview-thing it does) work. This may be no final solution but does quite a good work. I still hope the new API gets in place for 2.4.
Created attachment 19605 [details] [review] Patch made by Hongli Lai. Improves the existing fileselector, ABI compatible.
We won't be applying any patches to change the current file selector user interface. For one thing, GTK+-2.2.x is maintainence only.
Owen Taylor, do you think new fileselector API will be included in GTK+ 2.4 ? It seems, that GTK 2.4 feature freeze is planned October, only one month left... If new API isn't ready for 2.4, then maybe Hongli Lai's patch is the best solution?
The new file selector is the one mandatory feature that we will have in 2.4. 2.4 won't happen until we have the new fileselector.
http://gnomesupport.org/forums/viewtopic.php?t=3635 what about this?! this is ready arent it?
GTK developers should really take code from http://members1.chello.nl/~h.lai/gtkenhancements/ brief description of improvemens: Enhanced file selector * The file selector now has Back, Up, Reload, Home, Bookmarks, Terminal and File Manager buttons. All toolbar buttons have tooltips. * The file operation buttons are turned into toolbar buttons with nice icons. * Removed the . and .. from the file list; they are now replaced by the Reload and Up buttons. * UI cleanups: I changed the spacing in order to make the dialog look nicer and more HIG-compliant. * The file list now has a Date and Size field. * Removed the "Selection: /foo" label since it's kind of redundant. This also gives more space to the file list. * The pulldown menu has been changed to a combo box. This can also be accessed using Ctrl+L. * It will remember the last directory you visited, even when the GtkFileSelector widget is destroyed. * If the app is linked to gnome-vfs, the file selector will display each file's file type name. If the app is linked to libgnomeui too, the file selector will also display the file icons. This feature does not add any dependancies to gnome-vfs or libgnomeui! Pure GTK+ will work like before, but GNOME apps will "magically" gain the ability to display file types and icons. also look at http://gnomesupport.org/forums/viewtopic.php?t=3635 - there are lot of good comments from users about this file selector. Yoav, thanks for pointing to very usefull software.
I've read in news, that in gtk+ 2.3.0 is new fileselector. Maybe someone know where people can see screenshots of new fileselector ?
*** Bug 59747 has been marked as a duplicate of this bug. ***
There where lot's of ideas in OsNews recently.. Why dont you use this: http://www.gnomepro.com/gtk-file-sel2.png This is excellent!
Here are some (hopefully more realistic ~,^ ) suggestions for the UI: 1) The Add/Remove buttons are not obviously related to the bookmarks. Especially not as they're right nex to the Up button. I'd suggest putting the add/remove buttons under the bookmarks, to make it a more clear relation. 2) I get a popup telling me the add/remove buttons don't work with the current backend - if they don't work with the backend, then either remove them or (since that means the UI might change around) just make them insensitive. Popups are evil. The buttons by being sensitive 'advertise' that they work. 3) Let us resize, add, or remove columns from the file list. The Modified column tends to be a heck of a lot wider than the file name column, and the file names feel cramped. Personally, i can't even think of the last time I used Modified for sorting (of course that is only one user, me). Being able to remove/hide columsn (a la Evolution's mail list) would be useful. Resizing the columns is a *must*. 4) Should the Modified dates for directories be bold as well as the file name? Personally, I think it makes the dates over-power the file name, sort of pscyhologically hiding them. Just the file names should be boldened. 5) Icons would be nice; assuming these are temporarily broken based on certain mails/blog messages. ~,^ 6) The spacing around the buttons/label at the top of the dialog is whacked. It looks chincy. Add/Remove (again) probabyl shouldn't even be up there. 7) Context menues to add items to the bookmarks and to remove them would be great, and increase consistency across the desktop (as everything should have context menus). 8) The dialog size is waaay too small. Impossible to use small. Only one folder/directory fits in the list by default. And since the dialog doesn't remember its size (per-app issue?) it's a bit of a pain to use. 9) The separator between system bookmarks and custom user bookmarks shouldn't be present if there are no user bookmarks - unnecessary clutter. Also, the separator has a margin from the left side of the bookmarks container but not the right, the incongruity looks weird. 10) I think there are other spacing issues which need solving. The dialog as a whole just has odd spacing. Very likely not HIG compliant. 11) *very evil* - when saving a file, the file name entry has (of course) the file name. when clicking on a folder, the folder name over-writes the file name. BAD!! Of all the above, 11 is probably the worst - the rest are mostly cosmetic (which can cause usability problems, of course) but 12 actually makes the dialog very, very difficult to use for saving files, and is a serious regression from the (rather recently fixed, iirc) previous file dialog.
Now that GtkFileChooser is in place, I'm going to close this bug. I'm sure many people will have questions, so please read the following as it is likely to answer them: http://people.redhat.com/otaylor/fosdem2003/file-selector.html http://people.redhat.com/otaylor/fosdem2003/fosdem-filesel.ps.gz To answer to the last comment's points: 1) It was this way initially, but it looked ugly. I'm still not completely happy with the way it looks right now. 2) This works now; it was bug #129872 3) Resizing is trivial to add; just add a call to gtk_tree_view_column_set_resizable(). A size column is trivial to add, as the code already exists but is #if-ed out. I'm not sure we want configurable columns; in any case, it should follow the Natilus setting. This would require infrastructure work. 4) See gtkfilechooserdefault.c:list_mtime_data_func() if you wish to change this. 5) This works now; it was bug #132314 6) Got concrete suggestions rather than "whacked" and "chincy"? 7) Good point; please attach a patch to a new bug report. 8) This is bug #129020 9) On the first point, good idea; please attach a patch to a new bug report. On the second point, GtkCellRendererSepText needs to be enhanced to support this. 10) All the spacings are 12 pixels, which I think is the HIG standard. Please file a bug report for specific spacings that need to be corrected. 11) Known issue; I don't think a bug has been filed for it yet.