GNOME Bugzilla – Bug 642712
improve the file chooser design
Last modified: 2014-01-14 23:01:37 UTC
I think it makes sense to use some of the good ideas that are part of the Nautilus 3.0 design to improve the file chooser. It also makes a lot of sense to me to have consistency between them. I'll attach an experimental (but mostly working) prototype of this.
Created attachment 181269 [details] [review] set initial pane position
Created attachment 181270 [details] [review] Use some spacing between buttons in the pathbar
Created attachment 181271 [details] [review] Add a class to the chooser sidebar so we can style it
Created attachment 181272 [details] [review] Streamline the layout of the file chooser To make it a bit more orderly and more like Nautilus
Created attachment 181273 [details] [review] Remove add/remove bookmark toolbar
Created attachment 181274 [details] [review] Move filter box to top location bar
Created attachment 181275 [details] [review] Make pathbar and location entry mutually exclusive
Review of attachment 181269 [details] [review]: Commit this if you want. I'd prefer it if bug #524295 were fixed instead - it's about saving the position of the sidebar pane, along with the rest of the file chooser's state. (Complaints about the default size of the file chooser basically vanished when the chooser started saving its window size - you resize it once and be happy thereafter.)
Review of attachment 181270 [details] [review]: Heh, I changed it from 3 to 0 back in commit d955928bd :) I'd actually prefer it if the buttons were really zero pixels apart, rather than having whatever minimal spacing they have right now (due to the spacing for the default widget? no idea.). Of course one day the elves will write us a really pretty pathbar widget, etc. etc. etc.
Review of attachment 181271 [details] [review]: Go for it!
(In reply to comment #9) > Review of attachment 181270 [details] [review]: > > Heh, I changed it from 3 to 0 back in commit d955928bd :) I'd actually prefer > it if the buttons were really zero pixels apart, rather than having whatever > minimal spacing they have right now (due to the spacing for the default widget? > no idea.). > > Of course one day the elves will write us a really pretty pathbar widget, etc. > etc. etc. Zero doesn't really work as it is. If you want that at minimum you need to set up junction sides.
Review of attachment 181272 [details] [review]: The new shortcuts bar looks great! I'd like this commit split in at least two pieces, one to revamp the look of the shortcuts bar, and another to move the widgets around (but see below). I don't like it that the shortcuts bar is no longer aligned with the file list. We went through rather big pains to make them line up and to have the location entry / pathbar / stuff in the top row always stay the same height. So, while the shortcuts bar with headings looks great, I'd rather leave it aligned. A few problems I caught with some quick testing: - When you click on a bookmark, it disappears from the shortcuts, and reappears when you go to some other folder. This makes the other bookmarks jump up and down. The bookmark row should stay put. - As a result of that, the right-click menu on bookmarks no longer works. - If you click on something under the Computer heading (say, your own Home) and then go to another folder, the shortcut you clicked on remains highlighted. The idea is that something in the shortcuts bar is highlighted iff you are in that folder. - If you drag a folder from the file list into the shortcuts bar, and hover on the items in the Computer section, they highlight as if you were able to drop on those rows. But when you drop, the item gets added on the Bookmarks. You need to update the fancy code that detects the tentative drop positions, so that the line that indicates "your drop will happen here" will appear in the right place - and so that the Computer's subitems won't highlight at all.
Review of attachment 181273 [details] [review]: Thanks; I've wanted to remove the add/remove buttons for a long time. For this to be really effective, we need a more obvious way of bookmarking things and removing bookmarks. Removing is simple enough; see my comments above about not removing the current folder from the bookmarks list - that should make the right-click menu work. For bonus points, you could add an on-hover trashcan icon that when clicked, removes the bookmark. For bookmarking folders, there are several options: - Show an on-hover "+" sign on folders in the file list, with a "bookmark this folder" tooltip or something - like what Youtube has for adding videos to your queue. - Show a "Drag a folder here to bookmark it" text in the shortcuts bar at some point. Maybe if the list is empty? Maybe if you hover the list for some time? So, please push this commit, but take the above into account.
Review of attachment 181274 [details] [review]: If we keep the "Edit" button on the left of the patbar, then sure, we can move the filter combo to the top right. Otherwise it looks cluttered.
Review of attachment 181275 [details] [review]: I like the idea. However, with this patch as-is it means that if you have the location entry turned on, then you cannot know which folder you are in. Try browsing in that mode for a little; you get lost pretty fast. I'm open to suggetions about how to deal with that. I think the file chooser would look pretty acceptable as it is, with your changes to the shortcuts bar, to move the filter combo to the top right, and to remove the add/remove buttons. The location entry is hidden by default, and it's pretty clear that when you turn it on, it just adds a row between the pathbar and the treeviews.
(In reply to comment #3) > Created an attachment (id=181271) [details] [review] > Add a class to the chooser sidebar so we can style it We talked about using "GtkPlacesView" as a name, for when that widget gets pulled out as a public widget.
Cosimo suggests adding a GTK_STYLE_CLASS_SIDEBAR to gtkstylecontext.h and using that. That should be useful for the file chooser's sidebar as well as others.
Comment on attachment 181269 [details] [review] set initial pane position Attachment 181269 [details] pushed as 882cdf3 - set initial pane position
Comment on attachment 181271 [details] [review] Add a class to the chooser sidebar so we can style it I committed a very similar patch which uses a sidebar style class.
Comment on attachment 181273 [details] [review] Remove add/remove bookmark toolbar This actually needs more work, as the sidebar and the main view end up being misaligned at the bottom, which is unpleasant. I discussed with Jon and we decided to punt this to 3.2.
Created attachment 183869 [details] [review] Remove unused variable Commit from comment #19 added an unused variable. Trivial patch to remove it.
Some updates: We now have GTK_STYLE_CLASS_SIDEBAR, and that is used for the shortcuts pane instead of an ad-hoc style class name. The pathbar's buttons have zero spacing between them, but now the pathbar is properly jointed as per bug #658077. I've consolidated a lot of code that deals with the pathbar, location entry, and the various widgets in the top area of the file chooser. This should make it easier to change that part of the code now. The people in #gnome-design are talking about how to make this topmost area as similar as possible to Nautilus's. We need to think about how to fit a switch for list/icon view (see bug #141154 for the icon view patches); whether to move the filters to the top; and how to put Back/Forward buttons there. I'll revisit your patch to streamline the shortcuts bar; this is the major area of divergence with Nautilus, and the current shortcuts bar is pretty annoying anyway.
Comment on attachment 183869 [details] [review] Remove unused variable rejecting my old patch as that small side-issue has been resolved since
Created attachment 233977 [details] mockup (folder selection)
About the mockup: generally I think it's great. Three remarks: 1) The Select button at the top is a good idea to save space, but so far all dialogs have buttons at the bottom. This is really disturbing. Plus, without client-side decorations, you will not be able to draw it at that place at al. 2) Is there a way to close the dialog without selecting anything (Cancel button)? 3) If, as the window title says, the user is requested to choose _one_ folder, then the check boxes should be radio buttons. Else, the user will assume several items can be selected.
I like the folder selection mockup in comment #24: * It makes very clear what is going to be selected. * From an implementation viewpoint, it should be simple to add a checkbox column to the file list (or radio buttons if it's in single-selection mode). Some corner cases: 1. How would you select $HOME? Expect the user to navigate up to /home and select your home directory inside there? 2. How would you select /?
*** This bug has been marked as a duplicate of bug 722211 ***