Bug 158868

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.