| Summary: | ISO Album dates for 2009 2010 sort wrong | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Joe Biden <mailinglist> |
| Component: | Albums-Filters | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | caulier.gilles, marcel.wiesweg, mike |
| Priority: | NOR | ||
| Version: | 1.1.0 | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 1.2.0 | |
| Sentry Crash Report: | |||
|
Description
Joe Biden
2010-02-21 09:20:23 UTC
Sorting is done by Qt's tree view now in the svn and also produces this result. Also file managers like dolphin sort like this. The problem seems to be the different length of the number parts. I would doubt that we want to fix this problem. Also it seems to be consistent across KDE to have this behaviour. Should be KStringHandler::naturalCompare My guess is this: naturalCompare sees numbers, the first is two hundred thousand, the third one is twenty million. How should it know it's a date? Sometimes this is a valid assumption, sometimes not. I don't think it's a good idea to change this behaviour. Yes, that is the obvious, general-case assumption, but digikam is not general-case software designed as the building blocks for whatever you wish. There should probably be a way to specify the album names encountered. Like setting a flag to sort to expect numerics, or ASCII, etc. Most photographers I know set up a system of folders like I have. I actually learned it in class ten years ago, and since then have seen it countless times. Something along the lines of: Clientname/Date Or even Date-EventPlace Both of these would be affected by this sorting "issue". Since digikam is catering to this crowd, we should probably think up something to help counter this issue since it flows the opposite way of how many work. But there maybe other people using this like a counting number. And a gui option for such a minor detail can look really confusing and bloated. You could easily solve this by renaming your albums like 20090400 or using 2009-04, Thats what I do and it works without problems. But this is only my opinion. Any others? Ahhhh, the old "You should convert to how the software works, even if you've had a system that has worked for a decade"...Nevermind that I personally know of perhaps a hundred or two photographers I've met, etc, who used the same system. Software should flow with how someone works. A GUI option could be "Album sort type" with a mask, just like how mp3 taggers do it. It's not a leap at all. If someone doesn't want to tweak it, it's stays at the default. (In reply to comment #6) > But there maybe other people using this like a counting number. And a gui > option for such a minor detail can look really confusing and bloated. Well, there are already a lot of options in the "Album View" tab and one more does not make it bloated in my opinion. After all, there are options to change the font, so this alone makes it possible to have digikam behave differently from other KDE applications in some regards. Maybe this could be promoted to be added to the KDE locale settings? Of course, only my opinion ;-) Michael SVN commit 1095703 by jwienke: Provide a setting to define how string comparison is performed. BUG: 227905 M +2 -1 NEWS M +21 -1 digikam/albumsettings.cpp M +31 -0 digikam/albumsettings.h M +16 -2 libs/models/albumfiltermodel.cpp M +24 -4 utilities/setup/setupmisc.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1095703 |