[Pkg-kde-extras] Bug#233304: Feedback, comparisons with xdiskusage, hints

[Raúl Sánchez Siles]

  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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.alioth.debian.org/pipermail/pkg-kde-extras/attachments/20080108/e87a4a03/attachment-0001.pgp