Add a field "Hidden items" to display the number of hidden items, allowing the user to show or hide it.
FIXED-IN: 19.12
BUG: 412396
Details
Details
Diff Detail
Diff Detail
- Repository
- R824 Baloo Widgets
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Comment Actions
I think we should include the number of hidden files only when hidden files are shown and then include them in the total count.
But the information panel does not have a patch to access the ViewProperties holding the "show hidden files" settings, so to reach that point would need much more work.
So in the meantime, only hide the hidden files from the total count since it is sufficient to close the bug.
Comment Actions
Given the limitation, IMO it is more user-friendly to always exclude hidden files from the count even when they're visible than it does to include them in the count even when they're hidden. People who know about hidden files and want to look at them will understand what's going on here.
Long term, I would like to move baloo-widgets into Dolphin itself and give it some more smarts so it can intelligently display a count that includes or excludes hidden files depending on whether or not they're currently visible.
Comment Actions
The code only is used for local directories (not sure why it doesn't use KIO). Do non-local directories also have the same issue?
Comment Actions
I don't hate this idea, but for the average user I don't think it adds any value to show the number of hidden files, since they're hidden. The average user doesn't even know that there are hidden files. It's just noise.
Comment Actions
I see your point, but on the other hand would we teach users that hidden files do exist, which is not necessarily a bad thing. The "noise" level could be reduced working on the UI (shorter label? two different properties?).
My problem with this patch is that we would show a wrong information. In the worst case, this could even lead to data loss ("this folder has 0 items, I can delete it!")
Comment Actions
Well, without this patch it's already showing wrong information. "There are only 3 things in here, why does the information panel say there are 7?" Hence the bug report from a user.
I'm okay with showing "3 items (4 hidden)" because it's at least better than what we have right now and I will accept that too. However I still think the best solution is the more technically complicated one that includes hidden files in the count only when hidden files are visible. Then the existence of hidden files can still be hidden (heh) from regular users. In general I agree about teaching new concepts to users, but in this case I don't think the value is very high. Hidden files are not relevant to the kind of workflows that regular users typically engage in. People who do need to occasionally work with hidden files (sysadmins, software developers, other technical experts) are the kinds of people who already know about them.
Comment Actions
No fortunately there are guarded by isLocalFile.
Except FileMetaDataProvider::insertFilesListBasicData that did not and made dolphin display negative size when selected non-local directories.
My patch now fixes this.
I totally agree with @ngraham https://phabricator.kde.org/D24362#541173
Comment Actions
Sure, the current behavior is also wrong. But why switch from wrong to wrong when there is a way to make it right? ;)
I'm okay with showing "3 items (4 hidden)" because it's at least better than what we have right now and I will accept that too. However I still think the best solution is the more technically complicated one that includes hidden files in the count only when hidden files are visible. Then the existence of hidden files can still be hidden (heh) from regular users. In general I agree about teaching new concepts to users, but in this case I don't think the value is very high. Hidden files are not relevant to the kind of workflows that regular users typically engage in. People who do need to occasionally work with hidden files (sysadmins, software developers, other technical experts) are the kinds of people who already know about them.
Fair enough.
Comment Actions
The switch moves from wrong to right in most common cases.
I can add the hidden files count still if you insist, that add the hidden files count all the time.
I have a patch for this, but I am not sure that is what we want.
Here in my home directory :
Comment Actions
X files (Y hidden) can be misleading if X >> Y, for example 240 files (3 hidden) could be interpreted as there are 240 files from which 3 are hidden.
Maybe a X files + Y hidden is more obvious.
Comment Actions
I know, but you do agree that in some cases it would be wrong, right? What if we break some workflow relying on this info?
With this solution we are sure the info will be always 100% correct.
| src/filemetadataprovider.cpp | ||
|---|---|---|
| 223–233 | Prefer if (!isSizeKnown) {
continue;
}
const QPair<int, int> counts = ...
...so that we save one indentation level. | |
Comment Actions
I almost feel like we would need to add a setting to hide the hidden count, as at least some users will be annoyed by this, in particular those using local view settings with .directory files.
Comment Actions
We can do that if we add a kfileitem#hiddenCount metadata entry, so that normal count and hidden count would be two different properties with latter could be hidden by default. Needs changes in the metadata widget, of course...
Comment Actions
Ah, this is much better. The only problem I can find is that the visibility of the "Hidden items:" field doesn't show and hide itself automatically when hidden files are shown or hidden. You need to navigate away and back.
Comment Actions
Even if the field would hide when the hidden files are hidden, some users might want to keep the hidden items field displayed though.
But to me this is a very little paper cut here, since even with hidden files hidden, having their count can already be valuable.
Simple users that rarely show use hidden files, can hide this field happily.
Advanced users can show hidden items field or not depending on their workflow. And this field can be used to detect hidden files by those users (the field is hidden when there are none).
Comment Actions
The change to the return type of FileMetaDataProvider::subDirectoriesCount broke the windows build, as that code variant was not adapted, see
https://build.kde.org/view/Failing/job/Applications/job/baloo-widgets/job/kf5-qt5%20WindowsMSVCQt5.13/6/
Please have a look to fix this.