Hello Enrico: I think it's time to tackle this bug.
El Martes, 17 de Febrero de 2004, escribió: > Package: filelight > Version: 0.6.3.1-1 > Severity: wishlist > > Hello, > > Thanks for filelight! > > I was talking via IRC with another DD about filelight, and various > feedback, comparisons with xdiskusage and suggestions came out. I > thought it was a good idea to share them here. > > - xdiskusage is much smaller: you can use it to check disk space even > in situations in which you have very little disk space left and all > the KDE libs aren't fitting in :) What could filelight do about this? filelight is a kde application and as such it will always need kdelibs. I guess this is wont' fix. > - xdiskusage prompts what to scan in terms of partitions, showing a > df-like summary of usage. This is vety useful when you have a > disk-full situation and want to pinpoint it: the df-like output > allows you to pick the right starting path with just one click I think filelight already does this, but I think clicking on it doesn't work as one could expect :S Just noticed it. I should inform upstream author about this. > - when scanning, xdiskusage uses a progress bar that gives an idea how > how much time it's going to take. filelight writes an > always-increasing number instead, which doesn't give such an estimate You are right. We should file a wishlist upstream as well. > - the directory selection thing is really just an unlabeled text field, > which provider very little clues about what it's for. The only thing > it recalls to me is a browser location bar, which would suggest me to > put a URL there, which is wrong I sort of understand that you should place the path there, but maybe more explanation wouldn't hurt. Upstream as well. > - the "scan successfully aborted" printed in stdout when aborting a > scan introduces an interesting concept of "success" :) No longer such a message appear on stdout, maybe that was debugging output. > - filelight is cuter than xdiskusage. xdiskusage is however more > functional: it employs screen space better and can display much more > labels without resorting to mouseovers IMHO this are 2 design options, filelight has its own which could not be perfect and improvable. A specific suggestion should be addressed upstream if you have one. > - OTOH, filelight's output is more intuitive, as it looks as a pie > chart, which is a well-known abstraction for representing allocation > of space Yeah! > - when clicking on a slice to zoom in it, the slice's child slices are > radically rearranged, and this is hard to follow. Transition > animation would help, but I can imagine it's a mess to implement. > The rectangular space-division of xdiskusage, instead, gives similar > shapes to subtrees before and after zooming, making the transition > easier to follow (and possibly to animate, if they wanted to). I guess this is a side effect of the mechanism used to implement the pie chart. Could be also proposed upstream. > - small but annoying problems in filelight's interaction: mouseovers > appears in the child levels wrt where the mouse is, which doesn't > correspond to intentions: I want to see effects where I have the > pointer, which would means having mouseovers in the same level I have > the mouse pointer in, not elsewhere Either I don't understand this properly or I don't find annoying such annotations. > - since the circular division leaves a lot of unused space, a directory > listing (just some file names and sizes) of the directory you're > flying over with the mouse would be something to try adding (and > possibly removing in case it clutters too much) IMHO, that would be a little cluttered, but it's something still could be discussed. > - I can't understand what are the arrows at the end of the peripheric > areas They are the file/dir name represented by that annulus[1]. Possibly related with previous. > - Browsing up in the directory hierarchy could be made quicker by > silently continuing to scan upper directories in background while the > user is busy exploring the one (s)he selected I think I agree with you here. > > That's it for the first try. The biggest issue I see so far is the > impossibility to quickly select mount points as browse roots, as it > impairs using the program to pinpoint causes for disk space exaustion in > a partition. As I mentioned before that's (almost fixed) but it's not working for me so half fixed ;) In summary this is a great wishlist proposal but as you can see there are plenty of them instead of just one. So I suggest discussing them all here and then decide which action to take on each one and eventually split the result into a bug report each. Also take into account that all should be transposed upstream, I won't have any problem to do so once this is all sorted correctly. Regards, [1] http://www.rpdp.net/mathdictionary/english/vmd/full/a/annuluspluralannuli.htm -- Raúl Sánchez Siles
signature.asc
Description: This is a digitally signed message part.