GNOME Bugzilla – Bug 722211
improve the file chooser design
Last modified: 2015-07-04 05:04:03 UTC
Created attachment 266305 [details] wireframes Now that we have a shared widget for the sidebar between Files and the file chooser it is a good time to pick up improving the rest. There are a number of goals here. In no specific order: * finally resolve the click vs double click difficulty for both a11y and touch users * provide consistency between the file chooser and planned updates to nautilus * use space more efficiently * make preview more prominent * more obvious/direct multi-selection mode * support preview for typed paths and URLs * re-add search * resolve select folder vs select child ambiguity * more beautiful
*** Bug 642712 has been marked as a duplicate of this bug. ***
*** Bug 671778 has been marked as a duplicate of this bug. ***
*** Bug 121113 has been marked as a duplicate of this bug. ***
*** Bug 719618 has been marked as a duplicate of this bug. ***
*** Bug 707223 has been marked as a duplicate of this bug. ***
Would "Select by URL" also support local URIs? I wonder how I would enter local paths via keyboard with name autocompletion, like e.g. /home/user/Downloads/subfolder/foo.pdf. Maybe the first image in the second row covers this usecase, but I assume it's a type-ahead search field instead.
*** Bug 706384 has been marked as a duplicate of this bug. ***
*** Bug 706024 has been marked as a duplicate of this bug. ***
Shouldn't you be marking those bugs as dependencies rather than duplicates?
* Should not these be marked as dependencies rather than duplicates ? * Instead of by url why not a generic "remote location" , given that we can support sftp/ftp/... via gvfs which do not translate to URL very well in minds of people.
Created attachment 274474 [details] [review] places-sidebar: use separators instead of heading labels
Created attachment 274475 [details] [review] file-chooser: move pathbar into preview pane
Created attachment 274476 [details] [review] file-chooser: move filter combo into extra area
Created attachment 274477 [details] [review] file-chooser: allow views to extend to the sides of the dialog
Created attachment 274478 [details] [review] file-chooser: use an action bar for extra widgets area
Created attachment 274479 [details] [review] file-chooser: no shadow on scrolled window
Created attachment 274480 [details] [review] places-sidebar: add optional enter location place
Created attachment 274481 [details] [review] file-chooser: move location entry into same place as pathbar
Created attachment 274482 [details] [review] file-chooser: don't show a "save folder:" label
Created attachment 274483 [details] [review] file-chooser: style save mode name box as a search bar So we get a bottom border etc.
Created attachment 274484 [details] [review] file-chooser: style location bar as a search bar So we get a nice bottom border etc.
Created attachment 274485 [details] [review] file-chooser: add sidebar class to sidebar
Created attachment 274486 [details] [review] file-chooser: add a search bar instead of using a path bar mode
Created attachment 274487 [details] [review] file-chooser: don't use an special label for recent
Created attachment 274488 [details] [review] file-chooser: remove select a folder info message
Created attachment 274489 [details] [review] file-chooser: merge path bar mode and location mode
Created attachment 274491 [details] [review] file-chooser: make enter location an operation mode
Created attachment 274493 [details] [review] dialog: add a box around the action area to use for styling If we want to set style properties that include the area of the border-width part of action_area we need to use a parent box.
Attaching a screenshot that displays the proposed changes is welcome.
Oh, and replying to comments 6, 9 and 10 is also welcome.
Yes as someone who has put work into bugs such as bug 121113 I would appreciate a response as to why these bugs were marked as duplicates rather than dependencies? Most of the work for that bug has already been done in that bug report it seems silly to move it here and clump it with a bunch of unrelated patches and issues.
Created attachment 274888 [details] screenshots I tried the patches the other day. Screenshots are attached, for those who are interested.
Re 6, 9, and 10: Most of the bugs that have been marked as duplicates are addressed one way or other here. The 'single-click mode' bug isn't - at least not yet. Neither Jon nor I are convinced that making that an option or setting is a good idea, though. 'Select by URL' is not included in the patches yet, but I assume that we'll make it work like the current location entry, which accepts either urls or local paths.
Created attachment 274925 [details] [review] GtkFileChooserDialog: Avoid a bottom border in the dialog We recently started to respect border-width on the action_area again, so set its border-width to 0 so it doesn't get in the way.
Review of attachment 274474 [details] [review]: Since the places sidebar is now shared with nautilus, this will also affect it. I assume you've made sure that this looks good there too ?
Review of attachment 274475 [details] [review]: looks fine
Review of attachment 274476 [details] [review]: ok
Review of attachment 274477 [details] [review]: ok
Review of attachment 274478 [details] [review]: ::: gtk/resources/ui/gtkfilechooserdialog.ui @@ +17,3 @@ <child internal-child="action_area"> <object class="GtkButtonBox" id="dialog-action_area1"> + <property name="border_width">6</property> I had to remove this to avoid an ugly 'footer' on the dialog - is there a reason why you added it ?
Review of attachment 274479 [details] [review]: ok
Review of attachment 274480 [details] [review]: Do we need a nautilus patch to handle ::enter-location ?
Review of attachment 274481 [details] [review]: ok
Review of attachment 274482 [details] [review]: ok
Review of attachment 274483 [details] [review]: ok
Review of attachment 274484 [details] [review]: ok
Review of attachment 274485 [details] [review]: is adwaita using this for something ?
Review of attachment 274486 [details] [review]: ok
Review of attachment 274487 [details] [review]: ok
Review of attachment 274488 [details] [review]: ok
Review of attachment 274489 [details] [review]: ::: gtk/gtkfilechooserwidget.c @@ +5732,3 @@ && priv->operation_mode == OPERATION_MODE_RECENT) { + /* FIXME: ERROR_NO_FOLDER */ What are we going to do about this ?
Review of attachment 274491 [details] [review]: ok
Review of attachment 274493 [details] [review]: See my question above about the action area border - do we actually want that ?
Attachment 274474 [details] pushed as 5a73757 - places-sidebar: use separators instead of heading labels Attachment 274475 [details] pushed as 256a3a5 - file-chooser: move pathbar into preview pane Attachment 274476 [details] pushed as 458cd04 - file-chooser: move filter combo into extra area Attachment 274477 [details] pushed as df9522d - file-chooser: allow views to extend to the sides of the dialog Attachment 274478 [details] pushed as c253bc3 - file-chooser: use an action bar for extra widgets area Attachment 274479 [details] pushed as e2b2339 - file-chooser: no shadow on scrolled window Attachment 274480 [details] pushed as 1e925a8 - places-sidebar: add optional enter location place Attachment 274481 [details] pushed as 5c42068 - file-chooser: move location entry into same place as pathbar Attachment 274482 [details] pushed as 22e3552 - file-chooser: don't show a "save folder:" label Attachment 274483 [details] pushed as b05b91c - file-chooser: style save mode name box as a search bar Attachment 274484 [details] pushed as b5e13cd - file-chooser: style location bar as a search bar Attachment 274485 [details] pushed as cf9b297 - file-chooser: add sidebar class to sidebar Attachment 274486 [details] pushed as a644b34 - file-chooser: add a search bar instead of using a path bar mode Attachment 274487 [details] pushed as d46ed4e - file-chooser: don't use an special label for recent Attachment 274488 [details] pushed as d8ca588 - file-chooser: remove select a folder info message Attachment 274489 [details] pushed as 20dfe1d - file-chooser: merge path bar mode and location mode Attachment 274491 [details] pushed as 384b227 - file-chooser: make enter location an operation mode Attachment 274493 [details] pushed as 7e479aa - dialog: add a box around the action area to use for styling Attachment 274925 [details] pushed as d871105 - GtkFileChooserDialog: Avoid a bottom border in the dialog
didn't actually mean to push all of these, but its ok - I was fine with most of them anyway. But see the few questions I had
(In reply to comment #33) > Re 6, 9, and 10: > > Most of the bugs that have been marked as duplicates are addressed one way or > other here. The 'single-click mode' bug isn't - at least not yet. Neither Jon > nor I are convinced that making that an option or setting is a good idea, > though. > > 'Select by URL' is not included in the patches yet, but I assume that we'll > make it work like the current location entry, which accepts either urls or > local paths. Thanks for the explanation Matthias. I say this not so much as a criticism but as a concern that it took so long for a simple explanation it runs counter intuitive to the whole Enabling Participation blog post Allan wrote recently.
(In reply to comment #33) > Most of the bugs that have been marked as duplicates are addressed one way or > other here. The 'single-click mode' bug isn't - at least not yet. Neither Jon > nor I are convinced that making that an option or setting is a good idea, > though. Why don't you think it's a good idea, and what alternative would you propose? Single click is more important than a preference, it's an accessibility issue too. There already is an option/setting, but it only affects Nautilus, and not related controls like the file chooser. So the option you don't want is already present, but adds inconsistency to the desktop:- surely the current behaviour is the worst of both worlds.
(In reply to comment #56) > Why don't you think it's a good idea, and what alternative would you propose? 'fix my system' settings are usually not the right approach. Better to change the design so that the use of double-click becomes unnecessary.
I don't want to sound cheesy, but I would love to see the location replacing the "open a file" label. Content is king. Just saying "open" two times, makes it redunant, imho. Or do you fear people dont know what they are after with the dialog? The action button should show the context purpose.
(In reply to comment #58) > I don't want to sound cheesy, but I would love to see the location replacing > the "open a file" label. Content is king. Just saying "open" two times, makes > it redunant, imho. > > Or do you fear people dont know what they are after with the dialog? The action > button should show the context purpose. I don't think it's possible to do this with the way header bars work for dialogs.
And why not :/
Created attachment 275280 [details] File Chooser navigation mockup I attached a design proposal for a new file chooser navigation design. I took the Allan's mockup and started a short GIMP session on it. Creating a new design proposal seems to be too heavy for now. Ideas: * No more section headers * Putting bookmarks to the below users main home folders * The "Cancel" now looks and behaves like Web's back button * It might be handy, if browsing through directories is as easy as browsing webpages. * Websites and URLs are not very different from browsing file structures * The user has the same feeling browsing the web and files * URLs = DIRs!? Collapsing sections: * If vertical space is shrinking, more and more sections shrink to section icons. * Clicking those section icons to the bottom slides in a greyish section from the bottom to (overlay) show it's content. * Open/Close sections by clicking those icons * Almost no scrolling needed. A benefit for touch devices Don't wonder where "Recent" is gone. I simply forgot to insert its icon button to the left of the file path. :)
Comment on attachment 274925 [details] [review] GtkFileChooserDialog: Avoid a bottom border in the dialog fixed differently
(In reply to comment #61 > Created an attachment (id=275280) [details] > File Chooser navigation mockup > > I attached a design proposal for a new file chooser navigation design. I took > the Allan's mockup and started a short GIMP session on it. Creating a new > design proposal seems to be too heavy for now. ... Hi t.ask, thanks for the mockup! I think it would probably best to discuss this elsewhere - can you maybe add it to a wiki page and swing by #gnome-design?
(In reply to comment #63) > Hi t.ask, thanks for the mockup! I think it would probably best to discuss this > elsewhere - can you maybe add it to a wiki page and swing by #gnome-design? Hi Allan, I just finished the Wiki entry of this proposal https://wiki.gnome.org/Design/Whiteboards/FileChooser with a small animation to ease the read :) Unfortunately, I currently can't enter the use IRC, therefore, comments are welcome for the time being.
can someone please tell me whats wrong with my proposal (^) ? Nautilus and the filepicker should look almost identical.
PING... Still no SingleClick, at least according to this bug.
(In reply to comment #66) > PING... > Still no SingleClick, at least according to this bug. This is not helpful. You can CC: yourself without adding comments.
(In reply to comment #67) > (In reply to comment #66) > > PING... > > Still no SingleClick, at least according to this bug. > > This is not helpful. You can CC: yourself without adding comments. That's also not helpful. My question was not to CC myself (I thought I already was CCed). Nearly 9 months since the mega-meta-bug-merge, quite some patches got imported, every patch (but one rejected) got committed. And not a single action on SingleClick. I simply thought this one slipped through/got forgotten...
This bug is still open. Nobody is working on it at the moment. If there were news on this bug, you could read them in this bug.
(In reply to comment #65) > can someone please tell me whats wrong with my proposal (^) ? > Nautilus and the filepicker should look almost identical. The nautilus window is not a dialog. The pattern for headerbars in dialogs is CANCEL title ACTION, and deviating from that would break the dialog-ness of the file chooser. At least that is how I interpret Allans reply. If you are not convinced, the best way forward is to hack it in and demonstrate your vision.
A considerable amount of filechooser redesign work has just landed.