Version: 0.9.2 (using KDE 3.5.8) OS: Linux When the album names are numeric, they should be sorted in the natural way, not the logical way as is now. For instance, if a user has albums for each month of the year, they are currently in this order: 1 10 11 12 2 3 4 5 6 7 8 9
This is also true for current svn. The resorting seems to be done in void AlbumFolderView::resort() which calls AlbumFolderView::reparentItem . However, I cannot see that any sorting takes place in the case of the folder view, namely, in each step if (newParent) newParent->insertItem(folderItem); else insertItem(folderItem); is done To achieve some ordering here, the insertItem should not happen at the end of the list, but at the right place. Does this analysis make sense? Actually, when ordering folders by date, the parents are correctly sorted by date, but the items below come in a random order. Origin of the problem is the same.
To Dotan #1, To prevent this problem, just place "0" before 1,2,3,4...9. That work fine as well... Gilles
I habitually do that. However, some other Digikam users that I know are annoyed by this. I install Ubuntu on friend's computers and tell them to let me know _all_ the usability issues that crop up. This is a common one, both in Digikam and in Konqueror (it is fixed in Dolphin).
Yes, i have seen in Dolphin code. Currently, KDE4 port of digiKam use the same Qt3 old/transition classes to render folder tree view everywhere. I need to port it in pure Qt4 using model/view programming. I study the code of Dolphin as ref. It still in my todo list Gilles
Thanks Gilles. I appreciate all the amazing work done on Digikam. So long as the Qt4 version will be fixed then the Qt3 version can stay as it is in my opinion.
@Gilles: I wanted to provide a patch for this issue (svn trunk), but I've a crash in Xine when starting Digikam :-( Anyhow: Also with the KDE3 code is should be straight forward having a natural sorting. Just use the static method KStringHandler::naturalCompare() from kstringhandler in kdelibs. I did a quick search in Digikam and I think replacing the calls case(AlbumSettings::ByIName): { return d->info.name().localeAwareCompare(iconItem->d->info.name()); } with case(AlbumSettings::ByIName): { return KStringHandler::naturalCompare(d->info.name(), iconItem->d->info.name()); } inside albumiconinfo.cpp (method AlbumIconItem::compare()) might be sufficient. If you have any questions how Dolphin does the sorting, please drop me a mail :-) Thanks!
Created attachment 29015 [details] Patch for natural comparing of names
I got Digikam to run on my system (it seems I had a dirty build) and have attached a patch to fix this issue. Is it OK to commit this patch?
Created attachment 29016 [details] order For me this patch isn't working. I guess is should sort it like this now: 1 2 10 Right? Andi
The patch only fixes the sorting of the images within a view, not the sorting of the folders :-( I hope I've some time tomorrow to find out where the code for sorting the folders is located, I guess it can be patched as easy as the item sorting...
Ah ok, I thought you mean the album sorting, since you were talking about this in the first post: > When the album names are numeric, they should be sorted in the natural way, not the logical way as is now. Andi
Hmm, I could not find the code for sorting the albums. Initially I thought adjusting the <operator of AlbumInfo should be sufficient, but it had no effect. But I'm sure Gilles can do the fix in a few minutes with the help of KStringHandler::naturalCompare() :-)
SVN commit 893478 by aclemens: fix unnatural sort order in album iconview, patch by Peter Penz CCBUG:158868 M +8 -7 albumicongroupitem.cpp M +15 -14 albumiconitem.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=893478
Still need to fix unntural sorting in album folderview... Gilles, Marcel, any idea where to look for? There seems to be no such easy solution as with iconview, maybe we need to change DB queries? Andi
I think we can not do anything here, at least Q3ListView doesn't seem to provide some natural sorting method. Maybe this will work much better when switching to ModelView after 0.10 release? Andi
My two (slightly contradictory) points: - yes, it would be good thing to have natural sorting - this should be only an option and I am not sure if it should be default If it requires more work, do it only in newer versions. Hey, users should have some incentive to switch over ;)
Andi, Yes it's Model/View relevant. tagged... Gilles
(In reply to comment #16) > - this should be only an option and I am not sure if it should be default Why should this be an option? Or why is natural sorting unwanted in some cases? It is definitely easier to implement as a permanent solution then as an option I guess. Some minutes ago I added natural sorting to the find duplicates tree view, so that the numbers of duplicate images are sorted correctly. It should be rather easy to implement it for AlbumFolderView now, anyone who doesn't like it? Patch is already done... Andi
I will commit the natural sort to 0.11 branch, and if nobody complains in here, backport it later on to 0.10 trunk. Andi
SVN commit 935373 by aclemens: Add naturalCompare() to AlbumFolderView, TagFilterView, TagFolderView and TAlbumListView CCBUG:158868 M +5 -2 digikam/albumfolderview.cpp M +2 -1 digikam/tagfilterview.cpp M +8 -0 digikam/tagfolderview.cpp M +6 -0 libs/imageproperties/talbumlistview.cpp M +1 -0 libs/imageproperties/talbumlistview.h WebSVN link: http://websvn.kde.org/?view=rev&revision=935373
Andi, Sound like good for me. Just tested with my huge collections. Marcel ? Gilles
So should I just backport this? We can close the file then. Andi
yes fine for me Gilles
SVN commit 939079 by aclemens: backport: Add naturalCompare() to AlbumFolderView, TagFilterView, TagFolderView and TAlbumListView BUG:158868 M +4 -1 digikam/albumfolderview.cpp M +2 -1 digikam/tagfilterview.cpp M +8 -0 digikam/tagfolderview.cpp M +6 -0 libs/imageproperties/talbumlistview.cpp M +1 -0 libs/imageproperties/talbumlistview.h WebSVN link: http://websvn.kde.org/?view=rev&revision=939079
@18, Andi Problem lies in multiplication of "natural" sorting algorithms. When you want/have to access files from various programs and each one is using natural sorting order of files can be different in all of them. This happens especially with local characters, punctuation and sometimes even with capitalization (A vs. a). In such heterogeneous environments only binary sorting is safe way to safely perform your job.