[Xfce-bugs] [Bug 11524] Make thunar display recursive file size

[bugzilla-daemon at xfce.org]

https://bugzilla.xfce.org/show_bug.cgi?id=11524

--- Comment #6 from Derek Freder <acs82 at gmx.de> ---
Created attachment 6281
  --> https://bugzilla.xfce.org/attachment.cgi?id=6281&action=edit
a first, incomplete patch

Currently I dont have much time to do the coding ( new baby + we move to a new
house )
So here what I did so far. (patch for Thunar-1.6.3 attached). It already works
nicely .. however there is a list of things which are TODO in order to ensure
that it works in all cases, with the best performance, etc.

What currently works:
- For each folder of a tab, a deep-count-job is started to count the total size
of the folder. Updates are displayed, until the total size is calculated.
- The jobs are cancelled when the directory, displayed by the tab is changed.
- If two tabs show the same folder, recursive size calculations are only done
once
- The feature can be enabled /disabled in the preferences

What still needs to be done:
- Not realy good to run one job per folder, if this spawns a thread for each
job ... could get a real problem for folders with many sub-folders
- save folder-sizes in tree-model for all sub-folders if possible (So that
calculation is done only once when browsing a tree )
- Possible to use "thunar-folder" instead of "thunar-file" in order to save
calculated size , etc ?
- move impl to separate file, if it makes sense
- bug: Update list-model if box in preferences is un-checked
- possibilitie to run all jobs in the same thread ?
- Usage of G_Likely / G_UNLikely 
- mutex protection for critical variables
- Possibility to refresh / re-calculate ? ( react on "reload" STR+R" .. maybe
even automatically, if the size of an sub-folder/file is changed )
- Ensure that there are no memory-leaks !
- Usage of  g_object_ref, etc ? Does that make sense ?
- alphabetic order for methods ?
- update documentation
- create patch for trunk version of thunar (git ?)

Thanks alot to Woj, bug 10338 helped me alot to get started ! ( .. Probably my
patch will conflict with the patch for bug 10338, since often it touches the
same lines )

I will try to continue work on the patch, when I have free time however if it
takes too long for you, feel free to take over!

-- 
You are receiving this mail because:
You are the assignee for the bug.