GNOME Bugzilla – Bug 145255
Nautilus should use bold font for any files that have changed
Last modified: 2021-06-18 15:30:33 UTC
Description of Problem: A very nice feature of ROX-Filer is that any files which have changed, or been added to folder since the last time the user opened it, are highlighted by using a bold font for their names. It makes finding new/modified files in a busy directory very easy and pleasant. I've recently switched from ROX to the standard Nautilus distributed with Fedora Core 2, and really miss this feature.
I have exactly the same notion on this and was just about to enter it as enhancement request. Please highlight changed files somehow. Especially thinks like Download directories will be much more usable then ;)
I would prefer an emblem for this (though bold and /or italic font may do just as well). Maybe we need a recently changed emblem?
"emblems": I don't know about that. The reason bolding the names works is that you don't have to focus your eyes or examine the screen in detail to see what's changed -- your eyes can very quickly pick out the new/modified files. I don't see emblems working like that (although I'm not all that familiar with what they can do).
embelms are more visible than bold text. If you dont knwo what they are right click on a file and select properties then the emblems tab and add an emblems to that file/folder - they are very conspicuous!. Nautilus automatically adds emblems to files when they are read only so it would be consistent to have a recent change emblem there.
The emblems I've seen have all required me to look at each icon and examine what's attached (which sort of defeats the point of being able to quickly take in what's changed in a folder) -- whereas bolding the text jumps out immediately. This is particulary true when using View as list. Using ROX I can see which file has changed in a folder with hundreds of entries in a fraction of a second. I'm just a bit dubious that can be achieved by attaching a little emblem to each entry.
Created attachment 219348 [details] [review] Make new items bold New is defined as mtime >= atime.
Review of attachment 219348 [details] [review]: Looks nice and simple, I just have a couple of minor comments. ::: src/nautilus-list-view.c @@ +1496,3 @@ gtk_tree_model_get (model, iter, view->details->file_name_column_num, &text, + NAUTILUS_LIST_MODEL_FILE_COLUMN, &file, Should unref the file after we're done using it. @@ +1517,3 @@ "text", text, "underline", underline, + "weight", nautilus_file_is_new (file) ? 800 : 400, Better to use the PANGO_WEIGHT defines instead of the numeric values here
I'm wondering if we should we also have some sort of decay time here? For instance apply the marker only if mtime >= atime and current_time - mtime < a week or something like that.
Created attachment 219350 [details] [review] Make new items bold New is defined as mtime >= atime.
Created attachment 219386 [details] [review] Make new items bold New is defined as mtime >= atime. Update in sync with gio patch.
Created attachment 220044 [details] [review] Make new items bold New is defined as mtime >= atime. Updated to only show bold items in Recent. Since we can be more sure of the atime there and it is where new items make the most sense.
I think it's a good idea to limit this to Recent; the problem is that mtime and atime information for virtual files in recent:// is populated with the values taken from the actual backing file, which has the same reliability problems we discussed here and in the GIO bug. Since GtkRecentInfo already has concepts of "visited" and "modified" time, we probably should use those in the backend rather than the real values, and have Nautilus update the "visited" value when a file from recent:// is opened.
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.