Adds a new checkbox to choose to list hidden files and folders after those not hidden. Other sorting criteria (size, date, etc) is applied afterwards.
- Open a directory with a mixture of hidden and not hidden files and folders.
- Select a sorting i.e. default, size, creation date, last modification date.
- Go to menu View -> Sort By -> Hidden Last and check the new option (by default it is unchecked). Alternatively do the same from the folder view context menu.
- Not hidden files should appear before hidden (or dot) files. Files and folders from each of these categories shuold still follow the sorting selection made previously.
- If Dolphin is configured to 'Remember properties for each folder' a new entry will appear in the '.directory' file called HiddenLast
PS: I would like to write a new test in kfileitemmodeltest.cpp but I don't know how to run the tests. Any help would be appreciated.
Well for me it is pretty clear that this should be at least an option, if not the default. If you don't work with hidden files visible then this does nothing. But if you do, like myself, which view do you think is more useful/productive:
I open my home directory, i see only hidden folders. In most normal use cases I would go to my main folders like Documents, Downloads, Development, etc, i have to scroll through a vast number of hidden folders first.
With this option a user can still make use of having hidden files shown but also list the most likely often used entries at the beginning which only makes sense to me.
I don't think this over clutters an already long menu. But these are opinions of course.
About testing, you need to install the tool ctest then go to build dir and run the whole tests with ctest (it has many options to be more clever for instance ctest -R kfileitemmodeltest
Thank you for the info. I will try to add a test then.
So do you all want me to remove all the clutter code regarding the new setting and just keep the logic as to make it the default and only behavior?
I would rather very much keep the extra option. But it is up to you I guess.
You said it yourself: every setting needs a good amount of clutter code, which makes the overall codebase harder to test and harder to maintain. That's why we try to avoid adding a new setting every time we add a new feature.
We can reconsider if enough people complain about this new behavior not being optional.