GNOME Bugzilla – Bug 744237
Refine list columns
Last modified: 2015-02-18 08:43:01 UTC
Now that bug 737189 is fixed, it would be really nice to try and tidy up the list columns, in order to to reduce the amount of noise, focus the UI, and make the whole thing look better. This is especially important for the trash and recent views. Some things we could do here: * Expand the name column, so the other columns are always aligned to the right of the window. * Move the Modified column to the far right, and right-justify. * Hide the size column by default [1]. * Hide the type column by default [2]. * Dim the text of all columns other than name. * Make the modified column human-readable [3]. * Don't show the path in the Original Location and Location columns [4]. [1] I can't remember a single occassion when the number of items in a folder has been a useful piece of information. Sometimes it is useful to know the size of a file, but you can see that from the floating status bar, which seems enough. [2] Generally speaking, the icon and file ending tell you what type of item it is. [3] So it says "Today", "Yesterday", "Wednesday" and so on. [4] Instead, just show the name of the folder. It would help if the string acted as a link.
(In reply to Allan Day from comment #0) > Now that bug 737189 is fixed, it would be really nice to try and tidy up the > list columns, in order to to reduce the amount of noise, focus the UI, and > make the whole thing look better. This is especially important for the trash > and recent views. > > Some things we could do here: > > * Expand the name column, so the other columns are always aligned to the > right of the window. > * Move the Modified column to the far right, and right-justify. as default the modified colums is the last one of the defaults ones, so not sure why are you seeing somethign different if you didn't modify the preferences. For right justify is a problem, since we let the user reorder the columns and choose which columns to show, so one column right justified will look odd. > * Hide the size column by default [1]. > * Hide the type column by default [2]. > * Dim the text of all columns other than name. > * Make the modified column human-readable [3]. > * Don't show the path in the Original Location and Location columns [4]. Location is useful for the search view, since we don't have a good way to show the location of the items displayed (yet =) ). So putting there only the containing folder will do things worse no? > > [1] I can't remember a single occassion when the number of items in a folder > has been a useful piece of information. Sometimes it is useful to know the > size of a file, but you can see that from the floating status bar, which > seems enough. > > [2] Generally speaking, the icon and file ending tell you what type of item > it is. > > [3] So it says "Today", "Yesterday", "Wednesday" and so on. > > [4] Instead, just show the name of the folder. It would help if the string > acted as a link.
(In reply to Carlos Soriano from comment #1) ... > > * Move the Modified column to the far right, and right-justify. > > as default the modified colums is the last one of the defaults ones, so not > sure why are you seeing somethign different if you didn't modify the > preferences. When I said move to the far right, I meant out of all possible columns, not just those on display. (Also, don't forget about the recent and trash views, where Modified isn't the final visible column by default.) ... > > * Don't show the path in the Original Location and Location columns [4]. > > Location is useful for the search view, since we don't have a good way to > show the location of the items displayed (yet =) ). So putting there only > the containing folder will do things worse no? There will be issues when there are multiple folders with the same name (this will be exacerbated if they contain files that have the same name). I see this being a particular issue for programmers. It would be good to try to think of ways to show the full path on demand (such as when the file is selected). That said, the current practice of showing the full path quite awful - it doesn't leave enough room for the other columns, typically expands the view so it has to scroll horizontally (yuck), and introduces a lot of information that isn't generally needed. I think that the trade-off would be worth it, particularly when you bear in mind that it is possible to see the file's full path from its properties dialog.
I don't really think hiding the size and type column is a good idea, the first one it's actually a usefull information, directory item number included¹, while the latter is pretty usefull for sorting, so without other ways to sort stuff quickly is a no-go imho. Also I generally think it's a bad idea, since switching to listview is a way to have more infos regarding the files, a list view is not just yet another layout for of the same content, but it's usefull mostly to change sorting to find stuff more easily, this would defeat it. [1] when dealing with complex directory hierarchies, think about file server maintainance (soho grade NASses included), immediatelly knowing if a directory is empty or not or if it has tons of files inside is pretty handy.
(In reply to Lapo Calamandrei from comment #3) > I don't really think hiding the size and type column is a good idea, Why do you think it is necessary to retain the type column?
(In reply to Allan Day from comment #4) > (In reply to Lapo Calamandrei from comment #3) > > I don't really think hiding the size and type column is a good idea, > > Why do you think it is necessary to retain the type column? As I said (badly I assume :-)) in my previous comment, for sorting purpose
(In reply to Lapo Calamandrei from comment #5) ... > As I said (badly I assume :-)) in my previous comment, for sorting purpose Heh. Honestly, I don't think I've sorted by type in my whole life! Remember that this is just about the defaults - you will still be able to add columns if you do need them. So the question is how common it is to use these columns. (Another, more radical solution - probably not for right now - would be to remove the headings, and use the view menu to sort, like for the icon grid.)
(In reply to Allan Day from comment #6) > (In reply to Lapo Calamandrei from comment #5) > ... > > As I said (badly I assume :-)) in my previous comment, for sorting purpose > > Heh. > > Honestly, I don't think I've sorted by type in my whole life! > > Remember that this is just about the defaults - you will still be able to > add columns if you do need them. So the question is how common it is to use > these columns. > > (Another, more radical solution - probably not for right now - would be to > remove the headings, and use the view menu to sort, like for the icon grid.) for context, you mean like this right? https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/nautilus/nautilus-next/recent-list.png
(In reply to Carlos Soriano from comment #7) ... > > (Another, more radical solution - probably not for right now - would be to > > remove the headings, and use the view menu to sort, like for the icon grid.) > > for context, you mean like this right? > https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/ > nautilus/nautilus-next/recent-list.png Roughly, yes. It's just an idea...
(In reply to Allan Day from comment #6) > (In reply to Lapo Calamandrei from comment #5) > ... > > As I said (badly I assume :-)) in my previous comment, for sorting purpose > > Heh. > > Honestly, I don't think I've sorted by type in my whole life! > > Remember that this is just about the defaults - you will still be able to > add columns if you do need them. So the question is how common it is to use > these columns. Defaults are what users see. From what I've seen in my IT guy days list view and sorting is pretty common, most of my users (on windows clearly :/) used list view all the time especially for sorting purpose. > > (Another, more radical solution - probably not for right now - would be to > remove the headings, and use the view menu to sort, like for the icon grid.) With a quick way of sorting stuff, I think hiding type is totally doable, probably even column headers, even if you add another indirection (two clicks to change sorting instead of one), atm is not a good idea imho especially since the search filters are pretty much broken.
Created attachment 296923 [details] [review] nautilus-list-view: Don't show type column The extension/icon should be enough
Created attachment 296924 [details] [review] nautilus-list-view: put dates always the last columns Design request.
Created attachment 296925 [details] [review] nautilus-column-utilities: align to right the date column Design request.
Created attachment 296926 [details] [review] nautilus-list-view: dim label of columns that are not the name Design request
Created attachment 296927 [details] [review] nautilus-file: implement smarter dates Design request. Now we show the name of the day of the week if the file was modified in the last week. On the other hand, given that now we have more space to show details, we show the hour and minutes on the date.
Created attachment 296928 [details] [review] nautilus-list-view: use containing folder name as location Design request. Having a full location is too much in most of the cases. So show only the direct containing folder.
Everything is here. Patch "nautilus-list-view: dim label of columns that are not the name" depends on https://bugzilla.gnome.org/show_bug.cgi?id=744397 being fixed, and also Allan wants to put here some guidelines for the dates.
(In reply to Carlos Soriano from comment #16) > Everything is here. Patch "nautilus-list-view: dim label of columns that are > not the name" depends on https://bugzilla.gnome.org/show_bug.cgi?id=744397 > being fixed, and also Allan wants to put here some guidelines for the dates. I've just tried the patches, and can see a few issues: * The type column is still visible. * In the recent and trash views, the modified column isn't displayed on the far right. * The exact time is always shown in the modified column [1]. Having an option to always show the exact time might be interesting to look at, but is out of scope for this bug, I'd say - it'll need more thought. * I just noticed that the size column is right-justified. Shouldn't it be left justified? Oh, and for the record: I think Lapo convinced me that always showing the size column is a good idea. I'm sticking to my guns on the type column though. :)
(In reply to Allan Day from comment #17) > (In reply to Carlos Soriano from comment #16) > > Everything is here. Patch "nautilus-list-view: dim label of columns that are > > not the name" depends on https://bugzilla.gnome.org/show_bug.cgi?id=744397 > > being fixed, and also Allan wants to put here some guidelines for the dates. > > I've just tried the patches, and can see a few issues: > > * The type column is still visible. > * In the recent and trash views, the modified column isn't displayed on the > far right. > * The exact time is always shown in the modified column [1]. Having an > option to always show the exact time might be interesting to look at, but is > out of scope for this bug, I'd say - it'll need more thought. > * I just noticed that the size column is right-justified. Shouldn't it be > left justified? > > Oh, and for the record: I think Lapo convinced me that always showing the > size column is a good idea. I'm sticking to my guns on the type column > though. :) whops.... I pushed and old branch and deleted the new instead =( I will update the patches now..
Created attachment 297000 [details] [review] nautilus-list-view: Don't show type column The extension/icon should be enough
Created attachment 297001 [details] [review] nautilus-list-view: put dates always the last columns Design request.
Created attachment 297002 [details] [review] nautilus-column-utilities: align to right the date column Design request.
Created attachment 297003 [details] [review] nautilus-column-utilities: align size column to left Design request
Created attachment 297004 [details] [review] nautilus-list-view: dim label of columns that are not the name Design request
Created attachment 297005 [details] [review] nautilus-file: implement smarter dates Design request. Now we show the name of the day of the week if the file was modified in the last week. On the other hand, given that now we have more space to show details, we show the hour and minutes on the date.
Created attachment 297006 [details] [review] nautilus-list-view: use containing folder name as location Design request. Having a full location is too much in most of the cases. So show only the direct containing folder.
Created attachment 297007 [details] [review] nautilus-list-view: add a modified column with time It is useful for cases like a folder with pictures from the same day.
Implemented everything proposed here, except still depending on a fix for https://bugzilla.gnome.org/show_bug.cgi?id=744397 for the dim labels. Let's push the code anyway.
Attachment 297002 [details] pushed as ae1257d - nautilus-column-utilities: align to right the date column Attachment 297003 [details] pushed as 1493811 - nautilus-column-utilities: align size column to left Attachment 297004 [details] pushed as 416a813 - nautilus-list-view: dim label of columns that are not the name Attachment 297005 [details] pushed as 2f4b6d6 - nautilus-file: implement smarter dates Attachment 297007 [details] pushed as ee24b75 - nautilus-list-view: add a modified column with time
Forgot to mention, here is also the new column with the modified date with time. I didn't deleted the accessed time column yet, since it's used for the recent view and we need to discuss further. Since the UI freeze is tomorrow, I would delay that for the next release.
Just tested this. In general it looks good, although there are a few remaining issues: * A number of columns still appear to the right of Modified, including Location and MIME Type. * The Type column is still shown by default. * A new column has crept in "Modified - Time" - doesn't seem related to this bug. Also, it reproduces information already present in the modified column. Also, another request - can we increase the width of the default columns? Right now there's not a lot of padding between them.
(In reply to Allan Day from comment #30) > Just tested this. In general it looks good, although there are a few > remaining issues: > > * A number of columns still appear to the right of Modified, including > Location and MIME Type. > * The Type column is still shown by default. > * A new column has crept in "Modified - Time" - doesn't seem related to > this bug. Also, it reproduces information already present in the modified > column. > > Also, another request - can we increase the width of the default columns? > Right now there's not a lot of padding between them. It seems that I needed to reset the view settings - this all seems ok to me. Thanks Carlos, and sorry for the noise.
Review of attachment 297004 [details] [review]: This is not right - you should use either GdStyledTextRenderer from libgd or add a similar feature in GTK proper (see bug 676536). I'll open a new issue. GdStyledTextRenderer has apparently the same problem with alpha text rendering though.
Review of attachment 297005 [details] [review]: ::: libnautilus-private/nautilus-file.c @@ +4675,3 @@ time_t file_time_raw; + GDateTime *file_date, *now; + gint daysAgo; Should be days_ago @@ +4678,2 @@ gboolean use_24; + gchar *format; Shouldn't this be const gchar *? @@ +4686,3 @@ + file_date = g_date_time_new_from_unix_local (file_time_raw); + if (!full_date) { + now = g_date_time_new_now_local (); This is leaked as far as I can see
Review of attachment 297007 [details] [review]: ::: libnautilus-private/nautilus-column-utilities.c @@ +134,3 @@ + "name", "date_modified_with_time", + "attribute", "date_modified_with_time", + "label", _("Modified - Time"), This string sounds odd to me - how about just "Modified"?
(In reply to Cosimo Cecchi from comment #34) > Review of attachment 297007 [details] [review] [review]: > > ::: libnautilus-private/nautilus-column-utilities.c > @@ +134,3 @@ > + "name", "date_modified_with_time", > + "attribute", "date_modified_with_time", > + "label", _("Modified - Time"), > > This string sounds odd to me - how about just "Modified"? It is to differentiate from the real Modified, even if it's weird to have both activated at the same time. Still do you think is better to change it?