When in 'icons mode' or 'details view', the number of files inside a folder doesn't count the hidden files, but it should imho. Reproducible: Always Steps to Reproduce: 1. Switch to icons or details mode 2. Enable the 'Additional info -> size' option 3. Create a new folder 4. Create a hidden file inside that folder 5. The 'size' (count) of the folder's elements is still 0, but it should be 1.
Thanks for the bug report! Do you mean: 1. always include hidden files/folders for the size calculation 2. only include hidden files/folders for the size calculation when hidden files/folders are visible (already implemented)
I think Dolphin should always count invisible files, whether they are visible or hidden in the settings, as they are files. Anyways, if you don't want to break the UX, just add another option in Dolphin, something like "Count hidden files always".
(In reply to Emmanuel Pescosta from comment #1) > 2. only include hidden files/folders for the size calculation when hidden > files/folders are visible (already implemented) This behavior is intentional. If hidden files are not visible, then it would be confusing to see that a folder contains "1 file", but to see the folder empty after entering it. See also the related bug 325587, where a user complained about the fact that the Information Panel does count hidden files. (In reply to Alexander Nestorov from comment #2) > Anyways, if you don't > want to break the UX, just add another option in Dolphin, something like > "Count hidden files always". I think that no option should be added for this issue. There have been so few complaints about this that the added user interface complexity and maintenance burden of the new option outweigh any benefit that the option might have. From my point of view, this is WONTFIX.
(In reply to Frank Reininghaus from comment #3) > This behavior is intentional. If hidden files are not visible, then it would > be confusing to see that a folder contains "1 file", but to see the folder > empty after entering it. Hidden files are still files, just not visible by default. What is confusing is to see "0 files" but "423kb folder size". (Why is this, apparently, empty folder taking almost half a Mb?) > I think that no option should be added for this issue. There have been so > few complaints about this that the added user interface complexity and What interface complexity? Is a single checkbox that says "Count hidden files when counting total amount of files in folder" that complex? > maintenance burden of the new option outweigh any benefit that the option > might have. This is a 4 lines patch, literally. Like +if( !count_hidden_files){ count_files(); +}else{ + count_files(count_empty_files = true); +} What maintenance burden would that introduce?
(In reply to Alexander Nestorov from comment #4) > What maintenance burden would that introduce? * Each new option/feature needs additional testing, both automated testing (not a problem for maintenance) and manual testing! * Translation * Documentation * The change may introduce other bugs -> Bug triaging and fixing * People will complain about an overgrown settings dialog * ... I hope this helps to understand the problem and why we are sceptical towards new features/options. We try to pick out and implement the most interesting features (which is only a small subset of all the requested features) for most of our users - this isn't an easy task btw. ;)
(In reply to Alexander Nestorov from comment #4) > What interface complexity? Is a single checkbox that says "Count hidden > files when counting total amount of files in folder" that complex? If we added every checkbox that was ever requested by a single user each, then the Settings dialog would be completely unusable. So yes, adding a single checkbox will ruin the user interface if it's done too often, so whenever the question arises if one should be added, we really must ask ourselves if that option would be beneficial to a large part of the user base. > This is a 4 lines patch, literally. Like No, it's not. You forgot the code for the checkbox and for saving/loading its value to/from the config file on disk. > What maintenance burden would that introduce? Just like I said above for the user interface complexity: the code required for a single option may seem harmless, but it adds up if lots of new options are added all the time. Emmanuel gave some examples of the added workload that new options cause. Additionally, we would ideally test all combinations of options and check if any odd combination of options triggers some bug (this has happened in the past - it's often hard to figure out what combination of options is required to trigger a bug that a user reports, but that is not reproducible for us). However, the number of combinations of option values that need to be tested grows exponentially with the number of options, and this means that exhaustive testing becomes impossible quite quickly.
It doesn't make sense to count items that aren't visible. That's just super confusing. People will wonder, "wait, why does it say there are 25 items when I can only see 10?" 99% of users don't know or care about hidden files and this would just confuse them. The only thing that I can imagine making sense is updating the count only when hidden files are made visible. I think we could consider a patch for that (for real, we would). But until then, I'm going to have to close this bug.