In the size column, currently it always shows the disk space taken by the file, even if the file is a directory. For directories it would be much more useful put the count of files in the directory (including subdirectories). Thus "0" would indicate an empty directory. This could have an option to do so only for local directories, as does nautilus. (If displaying remote directories is possible with Thunar. I have never used remote directories myself.)
Created attachment 5184 patch for 1.6.3
Hi. I tried to implement this behavior for Thunar 1.6.3 (version from git: thunar-1.6.3). Patch attached. There is new option in preferences dialog.
Created attachment 5185 Screenshot of patched Thunar
Thanks. Looks good :)
Thank you! Pretty feature. Looks much better than almost useless byte sizes.
(In reply to Andrew from comment #2) > Hi. I tried to implement this behavior for Thunar 1.6.3 (version from git: > thunar-1.6.3). Patch attached. There is new option in preferences dialog. It is the easiest (from coding) solution. But counting objects in directory could costs a lot (or even too lot), if directory contains thousands (or more) of files. Maybe such action should be executed only on user's direct request?
(In reply to Ikonta from comment #6) > (In reply to Andrew from comment #2) > > Hi. I tried to implement this behavior for Thunar 1.6.3 (version from git: > > thunar-1.6.3). Patch attached. There is new option in preferences dialog. > > It is the easiest (from coding) solution. > But counting objects in directory could costs a lot (or even too lot), if > directory contains thousands (or more) of files. > Maybe such action should be executed only on user's direct request? Few directories would contain that many files, and counting the files in a directory it doesn't take as long as listing it. There is an option, if one never wants to see the count. As well, generally competing desktops show the file count, without any evident lag. In any case, showing the space taken up by the directory (as before) is meaningless. Almost always 4k, which can hold info for over 100 files. (The exact number depending on the length of file names.) If it is bigger, it could just mean that more files were in the directory at some point in time.
Bug 11524 is somehow related to this.
(In reply to Woi from comment #8) > Bug 11524 is somehow related to this. Not really. That bug is to show all the DISK SPACE used in and below that directory, much like du --max=0 {directory} (It could be solved by adding an option to the context menu. Otherwise a very expensive feature.) This is to show the COUNT OF FILES in the directory, instead of the (rather useless) disk space reserved for the directory itself.
(In reply to Ikonta from comment #6) > (In reply to Andrew from comment #2) > > Hi. I tried to implement this behavior for Thunar 1.6.3 (version from git: > > thunar-1.6.3). Patch attached. There is new option in preferences dialog. > > It is the easiest (from coding) solution. > But counting objects in directory could costs a lot (or even too lot), if > directory contains thousands (or more) of files. > Maybe such action should be executed only on user's direct request? 1) To count the files, all the sectors allocated to the directory have to be loaded. If local, that probably happens in a single read. After that it is only scanning memory, a very fast process. There is no noticeable delay for directories with thousands of items. 2) If the directory is not local, there could be asynchronous processing, but it wouldn't accelerate arriving at the final count. As well, if not already added (I can't tell until my next distro update in a few weeks), there could be an option to only display the count for local files. Which I would select.
(In reply to andré594 from comment #9) > (In reply to Woi from comment #8) > > Bug 11524 is somehow related to this. > > Not really. From bug 11524, comment 6 > ... Probably > my patch will conflict with the patch for bug 10338, since often it touches > the same lines )
(In reply to Woi from comment #11) > (In reply to andré594 from comment #9) > > (In reply to Woi from comment #8) > > > Bug 11524 is somehow related to this. > > > > Not really. > > From bug 11524, comment 6 > > ... Probably > > my patch will conflict with the patch for bug 10338, since often it touches > > the same lines ) what it said is "Probably my patch will conflict with the patch for bug 10338, since often it touches the same lines". "probably" is a key word. "touches" in what sense ? As well, what is the interest in having such a process-intensive feature always running if the feature is activated ? A number of directories typically have gigabytes of disk usage below them, in millions of files. It makes much more sense to use a context menu option. Also, where would this disk usage display ? An extra column ? In place of the (much more useful) file count ? Or all files in and below the current directory ?
*** Bug 12185 has been marked as a duplicate of this bug. ***
I still hope that will be implemented one day because it's so useful !
Created attachment 7604 updated patch Thanks for the patch ! And sorry for the late reply! Attached an updated version of the patch - updated to current thunar master - moved file count logic to thunar_folder instead of thunar_file - improved file count logic and caching - moved setting to "column selection", since it is only relevant for detailed view Now I would be happy if someone else could test the patch, before commit to master.
Created attachment 7605 Screenshot of patched Thunar
Testing results from AndreLDM ( thanks alot for testing! ): - found a "bug", the po folder from thunar's source says it has 128 items, when I open it the status bar says 127 items. Of course, this is due hidden files, but might confuse the users - regarding hidden files, nemo/nautilus honor the "Show Hidden Files" option, but after one toggles that (Ctrl+H), a manual refresh is needed to update the count - I think there's considerable performance hit here. I'm listing the root of my VPS hosted on Google via ssh, with this option disabled it usually takes 2s or less to Thunar list and no freezing is noticed. With the option enabled and Thunar just started (i.e. no cache) it takes about 20s while Thunar is almost locked. The second time takes 6s, likewise Thunar freezes for a moment. - When this option is enabled for remote files on Nemo and Nautilus, they take about the same time to finished the file counting, *but* it's done asynchronously, you see counts appearing one by one. - Also when I open another folder and return, the file counting takes about the same time, I think they don't use cache. I wonder if it's really necessary, perhaps the kernel itself does a bit of magic, it's like running du a second time, it'll be much faster. So still some work to do for this bug :( --> Check how it is done in nemo / nautilus and use the same concept --> Afterwards test performance on remote file systems
*** Bug 14608 has been marked as a duplicate of this bug. ***
I really wish to have this feature in Thunar.
I'm praying for it.
*** Bug 15935 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/thunar/-/issues/61. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev