Why was this done? It messes the display of the browser pretty bad IMO.

The way it was displayed before was better for usability.

Mixing folders with files also makes thing confusing:

Folders should be listed first then files.

previous behaviour was much better

Sort by name was added because each provider may add an entry for a dir or file and additional entries for the same dir were added far from the dir and thus not noticed by user.

I'll try to implement something more complex, not messing root and dirs with files.

I already implemented a custom sorting logic in the proxy filterAcceptsRow(), you can fix things there.

Can you show a specific example illustrating the problem (or explain how to reproduce it)? which providers add dir entries and where?

I'll try, but not before Monday, I am offline.

GRASS ;-)

hmmm I thought as much! cheers.

One approach would be to implement QgsBrowserTreeFilterProxyModel::lessThan().
I guess it would work if the default would be to sort by modelIndex values (to preserve original insert order). For directory and file items, use the items' directory/file names.

Another, simpler approach, would be to call sort() on all root items that are directory items.

I've just implemented lessThan() that sorts files by item's name(), others use the item's modeindex so original order is preseved

see bcfe0a8

as I don't use grass could not test this with grass, but order is fine in gdal/ogr items

Thanks Etienne and sorry for problems I introduced.

Unfortunately it is not yet optimal for GRASS because GRASS location entries (location is directory) are now listed between files but they should always follow directory of the same name. I have no idea how to resolve it. If an entry appears within dirs or within files should depend on whether the item was created based on dir or file (I believe). But we don't have such a flag on QgsDataItem.

But QgsGrassLocationItem is not QgsLayerItem, it doesn't have providerKey(). I cannot invent any simple clean solution without adding more info to QgsDataItem, like source type (dir/file). I dont know about other providers adding virtual item but in general it is possible that multiple providers add items for the same file/dir.

I have already considered that all, but

• cast to QgsGrassLocationItem seems really a hack over acceptable limits because grass header is not part of core, even providerKey() would be quite hacky
• QgsDataItem::Collection type cannot be used because QgsZipItem is also QgsDataCollectionItem

Do you have another idea? I wanted to add enum SrcType { SrcDirectory, SrcFile } but then considered it as overkill and too much mess for nothing but cannot come up with anything else.

Could you change the QgsGrassLocationItem type() method to return Directory
instead of Collection? The existing filter would work in this case.

In theory yes, but that is just another hack. The idea of Collection was something with children which is not Directory.

I like the srcType() approach, but there should be more values i.e. db,
network, etc. I think it would be ok to add new methods, even now in
feature freeze as long as it helps fix a bug.

Of course more types are necessary. But what other use apart sorting GRASS it may have? Maybe it could be used also to sort top level items, e.g. keep db providers and W*S in together groups - which seems to happen already anyway.

actually sorting of top-level items is avoided, the initial inserting order is preserved, which I think is better. So I don't any further uses for srcType() than this specific case.

I still think the best option is to change the QgsGrassLocationItem type() to Directory, which it really is when you think about it. It's a directory with some children (files), in the same sense that a "real" directory has gdal or ogr children files, and another Collection type (e.g. spatialite .db) has some children. Or perhaps I'm simplifying it.

OK, I'll probably change it to Directory, at least for now.

Last cosmetic detail, to always put GRASS item under the dir, it should be enough to compare row(), right?

for now all comparison is done using QString::localeAwareCompare(). In this case it will return 0, so I'm not sure which other criteria to use. But I think you are right to use row() (when compare==0) if the grass dir item is detected after the normal dir item.

There was already sorting implemented in QgsDataItem::addChildItem(). I hope it's fixed in 59c88cc.