Instead of checking for "." you should use KFileItem::isHidden() which also checks UDS_HIDDEN among other things.

The patch doesn't look too invasive, but still, someone will need to maintain this code. And as Frank said in #297435, it would also make the sorting behavior not consistent.

The actual problem here is that hidden entries "get in the way" when sorting is not by Name, right?

1. What's wrong with hiding the hidden files, when necessary? There is a shortcut that can be used to quickly toggle the hidden visibility.
2. Maybe we could improve the view to better distinguish between hidden and normal entries?

@broulik oh awesome. Uhg, not sure why I didn't see that function.

@elvisangelaccio:

The actual problem here is that hidden entries "get in the way" when sorting is not by Name, right?

They get in the way no matter the sorting when you have "folders first" enabled in ~/ since it has 10 to 20 hidden folders (like ~/.local and ~/.config) before your user folders (~/Music). Your home directory is likely where you'll toggle it on anyways since it has all the dotfiles usually.

• Right now it expects you to browse with hidden files invisible, which means you have to know they are there before you go looking for them.
• Toggling hidden files on means you need to toggle it off afterwards, before you leave the current directory, which you can't if you want to enter a hidden directory. Otherwise you have to toggle it off the next time you visit the folder.
• It's a lot easier to just leave them visible at the bottom and type .config [Enter] or scroll to the bottom and click.

Just realized I probably need to also write a test in src/tests/kfileitemmodeltest.cpp if this gets accepted. KFileItemModelTest::testSorting() probably.

As for maintaining, so long as I use KDE I'll probably be rebasing an expirimental branch on dolphin/master with a few experimental features. Merging this upstream is mostly for the others who were interested in this feature that don't want to compile every few months. I can understand if you don't want to bet on me not being around 10 years from now though.

In D7498#139531, @Zren wrote:

@broulik oh awesome. Uhg, not sure why I didn't see that function.

@elvisangelaccio:

The actual problem here is that hidden entries "get in the way" when sorting is not by Name, right?

They get in the way no matter the sorting when you have "folders first" enabled in ~/ since it has 10 to 20 hidden folders (like ~/.local and ~/.config) before your user folders (~/Music). Your home directory is likely where you'll toggle it on anyways since it has all the dotfiles usually.

• Right now it expects you to browse with hidden files invisible, which means you have to know they are there before you go looking for them.
• Toggling hidden files on means you need to toggle it off afterwards, before you leave the current directory, which you can't if you want to enter a hidden directory. Otherwise you have to toggle it off the next time you visit the folder.
• It's a lot easier to just leave them visible at the bottom and type .config [Enter] or scroll to the bottom and click.

For the record, there is also another way: click the url navigator widget and type .c [Tab] (will auto-complete to .config). No need to toggle hidden visibility and no need to group hidden files.

Just realized I probably need to also write a test in src/tests/kfileitemmodeltest.cpp if this gets accepted. KFileItemModelTest::testSorting() probably.

Yes please, if you could add a test I'd probably be ok with accepting this patch.

I'm sorry, but i'm very much against adding this feature.
It was shot down by the previous maintainer for (in summary) being a really small feature that a _really_ small percentage of the users would be using (if any).
See Frank's reasoning for closing it as wontfix: https://bugs.kde.org/show_bug.cgi?id=333219

Submitting it now as patch strikes me as weird. It was rejected, not even by complexity but by being a really minor feature that could cause more confusion then clarity.

Also, it will really impact the performance of sorting. Perhaps not in small folders, but hey, you guys know i benchmark with millions of files to stress test so anything that gets added in the lessThan function (which this patch does) will impact performance!

A more acceptable version would be one that does not impact current sorting. That can be done by filtering out the hidden files (which actually would improve sorting), that would be sane as the hidden files would be at the end anyhow.
Then independently of the rest sort the hidden files. That would - technically - be more OK for me.

At the very least, get this past the current maintainer.

Regarding maintainability. I think you miss the point there.
The maintainer of dolphin is responsible for maintaining all the code. The occasional contributor (you, me, dozens of others) can add or reduce to that maintainability burden. If we make code simpler, we likely reduce it. If we make it more complex, we add to the maintainability. At first sight there is no or just marginally extra burden. But imagine what would happen if there is a bug somewhere in code that you touched where it isn't immediately evident that your patch caused it (it could just be in the path). That adds to debug complexity and ultimately in maintainability of the code. It doesn't really matter if you stick around for 10 more minutes or 10 years, that would only matter if you were to maintain dolphin.

@Zren your "When a folder is a mount point (usb/hard drive/partition), show progressbar in the "Size" column instead of the number of files it contains." patch on the other hand (in your github fork) does seem quite interesting :)