Add support for natural sort algorithm
lesauxvi opened this issue Β· 26 comments
Currently, the sort functionality is based on the standard std::sort algorithm, which sorts the strings in a pure alphabetical sort order. Natural sort is a variant of the alphabetical order where multi-digit numbers are treated as if they were a single character. It leads to something more human-friendly. This kind of sort algorithm is apparently used in the explorers available on the different OSs to navigate through the files and folders.
It could make sense to add support for natural sorting algorithm (see this link for an example of library).
Is it a good idea and is it complex to add support for alternative sort algorithm?
hello,
no its easy and i could provide a way for anyone use his own sorting or integrate as a third party the one header library alphanum i have mirrored on github some years ago
Hello,
That would be perfect. Many thanks!
Vincent
in fact Alphanum is not a "one header only" lib (forgotten that ^^). so your proposal is a better choice
I have added the feature for sorting of filenames and extensions.
Finally self made and maybe optimizable a bit.
Since its slower than the base sorting, the use is optional.
You can enable it by using the flag ImGuiFileDialogFlags_NaturalSorting
Many thanks for you time and reactivity. I just tried the lastest version on a simple test case. I have three files in a folder: file1.txt, file2.txt and file11.txt.
The standard sort algorithm gives the following order: file1.txt, file11.txt, file2.txt.
The natural sort algorithm that has just been added gives: file11.txt, file1.txt, file2.txt.
My file explorer (Finder) gives: file1.txt, file2.txt, file11.txt.
From what I had in mind and understood, my file explorer gives the correct output as as the number should not be treated digit by digit but as a "whole".
What do you think?
i just tried your test files and this is what i obtain via the DemoApp :
i have added the testing of this feature and he is ok on macos, so its weird..
Yes, this is weird. Anyway, that means that the issue is on my side! Thank you very much for this implementation.
yes maybe but i would like to know what can be the bug.
any particular locales ?
can you tried the DemoApp branch ?
No nothing specific. I have not tried yet the DemoApp. I will try that and let you know! Thanks.
I did compile the DemoApp and here is what I got :
That is really weird. Just to make sure, we just have to click on the arrow located on the left of File name to sort the content, right?
By the way, to be able to use the DemoApp, I had to change line 67 of the file mainWinLinuxMacOS.cpp from
#if APPLE
to
#if __APPLE__
otherwise I had the following error message when I tried to execute the application:
Glfw Error 65543: NSGL: The targeted version of macOS does not support OpenGL 3.0 or 3.1 but may support 3.2 and above
yes just click on the header. even if you dont click the sorting must be ok
thanks for the define
can you enable the tests and run them ?
I compiled the tests and run them. Nothing happened and nothing was printed in the terminal (I tried to execute the test from my IDE - CLion - and from the terminal). Is it the attended behavior when everything is fine?
I found a log file whose content is
Start testing: Jul 07 16:44 CEST
----------------------------------------------------------
End testing: Jul 07 16:44 CEST
I dive a little bit in the code and I think I do not understand how the tests work. In the CMakeLists.txt file of the test folder, there is a line
include_directories("../src")
but there is not src directory... What am I missing?
no, when its fine you have a full list fo sucessfull tests
i think you dont have enabled them, you must set the cmake option USE_TEST=ON
you can check the files im using for github actions in .github/workflows/
and take a one for your compiler
ex for gcc :
mkdir build
cd build
cmake .. -DCMAKE_BUILD_TYPE=Release -DUSE_TEST=ON -DUSE_DIRENT_FILESYSTEM=ON
cmake --build build --config Release
ctest --test-dir build --output-on-failure
thanks for your time, i appreciate a lot :)
No, I enabled the test in the main CMakeLists.txt file. I compiled manually (and no longer with my IDE). It worked. You can find the results here. All the tests passed successfully.
This is really strange! What can I do to help you?
PS : you are welcome and thank you for the wonderful library.
nothing, in my mind, is the tests was passed successfully, so the natural sorting must be ok.
i have a linux vm i will test. maybe i missed something for the unix behavior( mac or linux)
FYI, I have compiled my code on a windows machine, the DemoApp also and the unit tests. Nothing has changed. This is not working as expected using the DemoApp, but all the tests are OK.
There must be something I do wrong!
there is a but related to the ordering on linux. im investigating..
you have compiled on windows but with a win32 toolchain ?
why was you on mac.. not sure understand.
you have tested on win and mac ?
no finally i have the same result. i just got an exceptions for a particular comparison.
but the sorting is bad in one sense..
in ascending i got test1, test2, test11
but in descending i got test11, test1, test2 but could be test11, test2, test1
will fix that
Yes, I tested both on MacOS (my main machine) and on Windows (with a win64 toolchain). I can try on linux if needed (but I'm not sure as you are already doing some tests on linux).
"Happy" to see that you also have an issue ;-).
i have the issue in the dialog but not in the tests with the same file list...
It seems to be vicious issue. How can I help you?
Just tried the latest version with the fix you released two hours ago. It is working like a charm, many thanks!
nice for you but i always have an issue around :(
i have fix it i guess.
if you have some time can you test the last build pls ?
I just compiled the latest build, and more specifically the DemoApp. Everything runs smoothy and works as expected. All the unit tests passed successfully.
I think we can conclude that everything is ok and we can close definitely this issue.
Many thanks for your time and efficiency.
yep cool.
many thanks for your time too. π