UI: File Browser Optional Created and Accessed Date Columns
AbandonedPublic
Actions

Authored by Harley Acheson (harley) on Sep 3 2019, 5:51 PM.

Details

Reviewers

Brecht Van Lommel (brecht)
Julian Eisel (Severin)
William Reynish (billreynish)
Bastien Montagne (mont29)

Summary

By default the file browser shows detail columns showing the file's modified date and file size. This patch adds two optional columns that can show the file creation date and access date. Arguably the access time can be of limited use on some platforms.

Once applied you can select these other columns in the options:

And then you see them, can sort by them, etc.

Diff Detail

Repository: rB Blender

Event Timeline

Harley Acheson (harley) created this revision.Sep 3 2019, 5:51 PM

Duarte Farrajota Ramos (duarteframos) awarded a token.Sep 3 2019, 6:28 PM

Note st_ctime is creation time only on Windows, on Linux and macOS it means "last status change".

@Brecht Van Lommel (brecht) - Note st_ctime is creation time only on Windows, on Linux and macOS it means "last status change".

I know, but I asked William and he showed me a capture where his Mac OS pretended that it was "Created". LOL

So yes, not sure how generally useful this data is. Created is nice on Windows but Accessed is fairly useless on many file systems. Both might be cool on Mac if we can pretend that c_time is Created.

On Linux who knows. If useful we could call it something else but "Changed" would imply content change to most people, not metadata change.

noki paike (amonpaike) awarded a token.Sep 3 2019, 10:55 PM

Regnas (Regnas) mentioned this in T69455: New File Browser UI is listing incorrect file sizes.Sep 3 2019, 11:16 PM

William Reynish (billreynish) awarded a token.Sep 3 2019, 11:32 PM

Generally fine, just noted a few minor points.

It's a bit difficult to know for sure what times the OS actually gives us. In worst case we can add OS specific handling (e.g. not display a certain column type if the OS doesn't give useful info for it).

Would be good to have this signed off by Bastien before it gets in. Mainly because it adds new sorting methods that may not be available for some asset types.

source/blender/blenlib/BLI_fileops_types.h
39–40	Should be committed separately.
source/blender/editors/space_file/file_draw.c
563–598	Would deduplicate code here a bit, the cases are handled almost identically: case COLUMN_MODIFIED: case COLUMN_CREATED: case COLUMN_ACCESSED: if (!(file->typeflag & FILE_TYPE_BLENDERLIB) && !FILENAME_IS_CURRPAR(file->relpath)) { int64_t time; char time_str[...]; if (column == COLUMN_MODIFIED) { time = file->entry->c_time; time_str = file->entry->c_time_str; } [...] if ((time_str[0] == '\0') \|\| update_stat_strings) { update_datetimest(time, small_size, &time_str, sizeof(time_str)); } return time_str; } break;
source/blender/makesdna/DNA_space_types.h
899–901	Please use more descriptive names for these. Proposal: int64_t mod_time; int64_t create_time; int64_t access_time;
904–906	Would be good to have a comment here showing why it's 32 + 8.

This revision now requires changes to proceed.Sep 8 2019, 5:39 PM

Updated patch for current master.

Changes as per Julian Eisel (Severin)

I have kind of very mixed feeling here… Mainly, I wonder how useful those additional timestamps are really? Besides (maybe) creation time, but only on Windows, I wonder if users would really need those extra options. Most in-apps file browsers (Open/Save dialog boxes) only ever show the modified timestamp. Would like to hear from our UX/UI team here (@William Reynish (billreynish), @Pablo Vazquez (pablovazquez) ?).

Also, am not especially thrilled at the idea of adding more extra info in core structures here, because we could then also add support for tags (which are supported by some systems nowadays), author, and all kind of other meta-data. ;)

My point is, if we want advanced sorting/filtering, then we should rather finish the asset engine project, where each engine can define its own options and behavior for that. Imho filebrowser itself should stick to basic, core data/info, nothing more.

@Bastien Montagne (mont29) at least on Mac & Windows you can enable these too - seems ok to add them here in that case.

I’m mostly with @Bastien Montagne (mont29) here. It was a fun exercise to put together but I don’t think I’d actually ever enable those columns for any purpose.

This mostly came about because I originally suggested adding tooltips with this extra info. I’m still more likely to look at something like that occasionally than enable an entire column. So I like having this extra data available. In fact would also add an int for attributes like system, hidden, etc if it were up to me.

So again, don’t consider me in the “yes” camp for this patch - I only wrote it.

I can’t see why not to add this. We now have columns, which lends itself well for displaying this. Our host OSs rend to have these too. I think we should include them as optional columns.

@William Reynish (billreynish) - I think we should include them as optional columns.

As mentioned, not saying you are wrong here. Was just stating that I personally wouldn't use these columns, but I'm far from a typical Windows user or Blender user. So although I won't advocate for this, that doesn't mean there are not valid reasons for you to do so.

Our host OSs tend to have these too.

Only to a degree. Windows will typically show Modified, will make it easy to show Created, and will make it more difficult to see Accessed. This is because Accessed time is only available on some volume types, the updating of such is an option, and that option is now off by default.

On Linux the "Created" time is really last change of meta data, which is quite often the same as created but might not be. There is a sometimes a separate "birth time" but that is not available on many systems.

I can’t see why not to add this...

Lots of reasons why not. Every feature has a cost of support and maintenance. And those things have to be balanced with the benefits they bring. In this case there might not be great benefit but there is potential for support issues. Like having to give a response to a Windows user who does not understand why Accessed time is the same as Modified on his system. Or to a Linux user why one file shows a Creation time that is not expected.

Even adding this for one platform and not another could cause support issues. So add both optional columns to Mac but only Created to Windows and we might get questions about why. Add neither to Linux and we will be asked why we are treating that platform like a second-class citizen.

We shouldn't add things just because we can, but because there is clear benefit to users that outweighs any added cost of maintenance and support.

Date Created is quite useful generally IMO. There’s a reason why the host OSs include these columns too. Anyway, to me it seems worthwhile - I’ll leave it up to @Bastien Montagne (mont29) and @Brecht Van Lommel (brecht).

For sure.

One possible option is to REMOVE "Accessed" from this patch completely, as it is the least useful and most problematic. And then label "Created" as "Changed" for Linux only. Although having "Modified" and "Changed" for them might seem odd, they tend to be a bit more technical anyway.

William Reynish (billreynish) accepted this revision.Sep 22 2019, 12:25 PM

Abandoning. I just don't like this to be honest. LOL