GNOME Bugzilla – Bug 45659
icon and list views should share the same sort order
Last modified: 2021-06-18 15:49:34 UTC
files in icon view can be "laid out" according to certain characteristics, just as list view files can be sorted by clicking on the attribute's column header. since the two views can be sorted in the same ways, sorting should remain in effect across switches between list and icon view (as they do when one returns to the original sorted view). * REPRODUCIBLE: Always * STEPS TO REPRODUCE: view /bin as a list; sort it by filesize; switch to icon view. * ACTUAL RESULTS: the files appeared alphabetically ordered. * EXPECTED RESULTS: they should have remained sorted by size. a corrollary to this bug would be the inclusion of the "lay out items" option in the list view. its funcitonality would be synonymous with clicking on the column headings. this would reinforce the connection between the two different sorting methods in the UI. ------- Additional Comments From darin@bentspoon.com 2001-01-15 16:20:58 ---- We considered having a single sort shared by both views and decided not to do it that way. Maybe we should reconsider that some day. ------- Additional Comments From sullivan@eazel.com 2001-03-13 10:14:26 ---- I don't remember why we kept the sort orders separate. My first impulse now is that they should be the same, as aaron suggests. Arlo, Andy: Any opinions here? ------- Additional Comments From eli@eazel.com 2001-03-26 11:11:28 ---- QA Assigning to self. ------- Bug moved to this database by unknown@bugzilla.gnome.org 2001-09-09 20:51 -------
Changing to "old" target milestone for all bugs laying around with no milestone set.
This is still the case in HEAD. Updating and marking it a minor bug, since it is a usability/sanity problem and not an enhancement.
nautilus 2.5.7: listing order is only saved for the particular view, a per window variable that tracks sorting would feel natural
Two questions I still haven't heard a convincing answer to: - how to do map manual layout to the list view? - what to do if the sort criterion doesn't have any associated visible list view column?
Yeah, I guess there's a good reason why OSX (and Windows, IIRC) keeps the sort order separately for each view :) I guess, in theory, you could map a manual icon view to a list view by looking at the icon view and listing the icons from top to bottom, left to right (locale dependent?). In other words, list them in the order you might expect to Tab through them in the icon view (if that's what Tab actually did in the icon view), or to Tab through controls in a dialog if they were laid out the same way. I'm not sure it actually makes any sort of usability sense to bother doing that, though. (Aside: on OSX icon view, Tab continues to cycle through icons alphabetically regardless of how you lay them out manually, so they don't even make that effort... I'd guess for accessibility reasons.) As to your second question: I can't think of any solution at all :) I think this has to be verging on a WONTFIX, personally.
Calum: So "Manually" would effectively be "Sort by Name" in list view. Considering that we have a submenu like View->Arrange Items "Manual Layout" "Sort by Name" "Sort by Size" "Sort by Type" "Sort by Modification Date" "Sort by Emblems" how would you suggest that we denote that we effectively sort by name in list view although manual layout is selected? a) grey out the "Manual Layout" item but have it selected. Disadvantage: It's not obvious that we sort by name. b) grey out manual icon and select "name" icon. Disadvantage: It's not obvious that for the Icon view, we still sort manually c) grey out manual and name items but select name item. Would be quiet fishy, since we allow to select the name item after the user switched to another item. I've actually a proposal for number 2: We could simply sort by the specified criterion without displaying any sort indicator at all.
> Calum: So "Manually" would effectively be "Sort by Name" in list view. Hmm, I'm not sure that's what I meant, but let me think about it! Can you explain how you get to that conclusion, so I can work out whether we're talking about the same thing? :) > how would you suggest that we denote that we effectively sort by name in list > view although manual layout is selected? Well, again theoretically, you could actually have a 'real' manual layout mode in List View, too... allowing you to rearrange the list as you like, by dragging and dropping. The problem again is how that would map to a 2D icon view when you switched back... you could perhaps just do the 2D->1D thing in reverse, i.e. map the new linear order onto the previous manual icon view positions, but I can't really imagine why you'd want to. > I've actually a proposal for number 2: We could simply sort by the specified > criterion without displaying any sort indicator at all. Yes, that would work I suppose. I was thinking there might then be an issue around getting back to this state after you'd clicked on a heading to sort by something else, but the HIG actually suggests how to do this so it's probably not an issue.
> Can you explain how you get to that conclusion, so I can work out whether we're talking about the same thing? :) "In other words, list them in the order you might expect to Tab through them in the icon view". The icon view internally uses the name of the displayed icons in manual layout mode. But you don't seem to know this, so you obviously didn't refer to it ;). > I was thinking there might then be an issue around getting back to this state after you'd clicked on a heading to sort by something else the user still has the "View" menu, which should list all available criterions.
Marking as ui review, since the UI if we want this is not clear.
What I suggested in #gnome-hackers is: 1) Always respect the last sorting choice in both views 2) If the sorting option can't be represented in the current view, show the sorting options inconsistent, either as per gtk_toggle_button_set_inconsistent() in the popover radio buttons, or unsetting sort triangles in treeview column headers.
NEEDINFO is not needed for ui-review
Created attachment 353480 [details] Unified solution to sort criteria This is one solution to the problem. The sort criteria are given for example only, to show that this can work for any given sort criteria.
Created attachment 353481 [details] Unified solution to sort criteria: buttons/icons versions This version is like the previous, only based on icons/buttons for each sort type, and solves several of the problems listed in the previous pdf document.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of Files (nautilus), then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/nautilus/-/issues/ Thank you for your understanding and your help.