GNOME Bugzilla – Bug 324534
Use friendly date/time in treeviews
Last modified: 2007-01-02 16:49:49 UTC
Might be nice to use "friendly" time in the treeviews. They are already used in some of the properties dialogs.
Created attachment 56174 [details] [review] patch OK to commit?
Wouldn't that take much more space than it does currently? If so, wouldn't it be better to use that space to show artist and track name, rather than the time?
Depends on the language, I suppose. In English, the longest friendly time is "Yesterday 10:00 PM". The current format is "2005-12-18 10:00". So, I think the difference in horizontal space is negligible. This is the same format that Evolution uses in the mail list view. In fact, you can choose to save even more space with this format because the most important information is closer to the beginning of the string. For example, consider the following dates: 2005-12-19 15:00 2005-12-18 10:00 2005-12-17 05:00 Now consider the date strings clipped after 5 characters. In ISO-like form they will all appear as "2005-". In friendly form (in English at least) they will appear as: "Today" "Yeste" "Sun 0" The information is much more compact. However, the real win is that it is formatted for humans. See the second to last line of: http://mail.gnome.org/archives/rhythmbox-devel/2005-December/msg00101.html
Oh, that's for the date, not for the time, right? The summary of the bug didn't really make that clear.
Ha. Right, "date/time". :) This affects, Last Played, Date Added, and Podcast Date. I think that's all.
Personally, I don't like it. Scanning a list of Friendly + non-Friendly dates is difficult. Even after sorting, its frustrating to have two formats in the same list, especially for something numeric like dates. So I vote no, unless theres a gconf key to set it somewhere.
rb_entry_view_get_time_date_column_sample() would need to be updated to return sample data for each of the friendly date/time formats, so that the column widths could be measured correctly. Otherwise, the patch looks good to me.
Created attachment 56176 [details] [review] updated patch Nice catch. Updated. It isn't as easy to precisely determine the width of this kind of date but this should be a reasonable estimate or upper limit. Please keep in mind that this patch only changes to using "friendly" dates. Precisely what a friendly date is can be further tuned.
Works for me. It would be nice, however, to optionally have a gconf switch between this and the old ISO date behaviour as mentioned in comment #6.
(In reply to comment #8) > Created an attachment (id=56176) [edit] > updated patch Any chance this patch could be updated and committed? It doesn't apply cleanly against CVS anymore. Friendly dates would be nice.
Ping?
Created attachment 61073 [details] [review] updated patch Updated to cvs. This looks fine to me, aside from the fact that scanning such a list can be harder (as previously mentioned).
Patch works fine for me. Would a gconf setting be appropriate for switching the behaviour (I would make "friendly" the default, but expert users might like ISO format).
Conflicts with CVS HEAD now because of the commit of patch at bug #332992: $ patch -p0 < patches/active/rb-friendly-time-3.diff patching file ChangeLog Hunk #1 FAILED at 1. 1 out of 1 hunk FAILED -- saving rejects to file ChangeLog.rej patching file rhythmdb/rhythmdb.c Hunk #2 FAILED at 2656. Hunk #3 FAILED at 2665. Hunk #4 FAILED at 2679. 3 out of 4 hunks FAILED -- saving rejects to file rhythmdb/rhythmdb.c.rej patching file sources/rb-podcast-source.c Hunk #1 succeeded at 1624 (offset 54 lines). patching file widgets/rb-entry-view.c
Any love for this patch? Seems like nobody was interested in getting in friendly times... Marking patch as obsolete, since it is way out of date w.r.t. CVS.
*** Bug 371062 has been marked as a duplicate of this bug. ***
Created attachment 78144 [details] [review] patch Resync with CVS.
Regarding difficult to scan... obviously I don't agree. The fact is that we (people) just don't use numeric dates internally. For every date you see in a numeric format you have to convert this into some other form. In some cases this is the day of week or month (relation to milestones), sometimes it is the amount of time since then or from now (delta), sometimes it is a combination of these or something else. And to make matters worse this will almost always require actually looking up the current date. Think about how you would react if someone said to you: "What did you think about the meeting on 2006-12-10?" Well you'd first have to determine or remind yourself that today is 2006-12-11, make sure that you heard all the numbers correctly, make sure you are in agreement about the order of month and day, and then punch the person in the face for not saying "yesterday" and making you store all this stuff on your mental stack. Also, what we do with this format is basically only display the relevant information. This reduces noise. Think about how people talk about dates. You say for example: - We went to the movies yesterday at 4:30 - We ate sushi on Friday at 7 - We went to a concert Nov. 11 - I went to the dentist Nov. 2005 The year is always assumed to be the present unless specified. The required precision is inversely proportional to time elapsed (in most cases). So given that this format requires less processing and is easier to parse I think that it is much simpler to scan.
Patch works for me. Regarding comment #18 perhaps a gconf key to get the old ISO-style date behaviour as I suggested in comment #9 would keep people like those in comment #6 happy.
As for bug #359740 getting wider feedback on the mailing list would probably be a good idea.
I think having it committed, so people can try it out would be a good way to get comments on it. Marking as commit-after-release.
2006-12-19 William Jon McCann <mccann@jhu.edu> * lib/rb-cut-and-paste-code.c: Remove trailing whitespace. * rhythmdb/rhythmdb.c: * sources/rb-podcast-source.c: (rb_podcast_source_post_date_cell_data_func): * widgets/rb-entry-view.c: (rb_entry_view_get_time_date_column_sample): Use a friendlier time/date format. Fixes #324534
It'll probably take me a while to get used to this. The main thing that sticks out for me is when there's a "Jan 16 08:58 PM" immediately above a "Thu 11:03 PM" - I keep trying to read the month abbreviation as a weekday or vice versa and it just jars me a bit, and the formatting of the day/time fields doesn't help me figure it out.
A couple more nits: - In the first week of the year, all last played times more than a week ago are in '<month> <day> <year>' form, which doesn't quite seem right to me. Since last played times can only be in the past, "Dec 20 11:35 pm" doesn't seem ambiguous until about the end of November. - At the least, the 'today' and 'yesterday' times should be updated at midnight.
Seem like good points to me. From what I remember we just copied what evolution used. But those seem like good improvements.