On Tue, 27 Apr 2010 16:54:48 +0200, Enrico wrote:
On Mon, 26 Apr 2010 15:42:25 +0200, Colomban wrote:
Hi!
Ho!
As some of you might have noticed, the sorting in the "Documents" side panel is not perfect when extensions are involved. For example, if you have the three files a.c, a.h and a-b.c, they will be sorted in the following order [1]: a.c, a-b.c, a.h rather than [2]: a.c, a.h, a-b.c This is a little annoying to find the a.h file.
As you expected, I've written a patch to fix this, an I propose it here. Hum, well no: I've written two different patches. Why? Both have advantages and inconveniences over the other. Both use g_utf8_collate_key_for_filename() to get a clever sort, which fixes the problem I spoken above, and also sorts 1, 2 and 10 numerically rather than alphabetically - thus we have 1, 2, 10 and not 1, 10, 2.
The difference between the two patches is the way thy integrate in Geany.
0001-improved-documents-sorting.diff: This one is small, almost no code changes, and don't persistently use more memory. But OTHO, it computes the collate key of both names to compare each and every time the sort function is called.
0001-improved-documents-sorting-2.diff: This one is probably faster, but persistently use a little more memory: it computes the collate key only when adding the item, and stores it in the tree model. Another "advantage" of it is that it easily allow to use different collate functions for files and directories - not sure it is useful.
Then, there are the two patches, I let you chose/discuss the one is the better if you're interested.
First: thanks.
Then, I'm no sure. It might be better to take the more memory to get a little more speed, i.e. to not loose too much speed :(. Sorting of the list happens on each newly opened document and maybe on closing documents and even when switching tabs as I just noticed while
We don't re-sort on closing documents. So, in contrary to my previous opinion, I'd vote to go the easy way and compute the keys on each run instead of polluting the memory.
testing. Though re-sorting the list on tab switching seems weird, maybe there is a reason but without looking into it, it feels like a bug.
I'm not yet sure. Maybe we first should try to reduce sorting attempts to a minimum...:).
Ok, the re-sorting on tab switching was wrong and should be fixed in SVN now. Not strictly related to whole topic but nice that we found it by talking about the topic :).
Regards, Enrico