[Sugar-devel] [DESIGN] Show file size in Journal

[Eben Eliason]

On Thu, Apr 8, 2010 at 7:18 AM, Sascha Silbe
<sascha-ml-ui-sugar-devel at silbe.org> wrote:
> On Wed, Apr 07, 2010 at 08:43:29PM -0300, Kenny Meyer wrote:
>
>> Bernie and I have been discussing about showing the file size in Journal
>> view
>> of Sugar 0.84.x, [...]
>
> As already mentioned on the ticket, Sugar 0.86+ does that (in the details
> view). The commits are 85b833 [1] and 6c3fd034 [2]. A quick look suggest
> they should be easy enough to backport.

Yeah, that's certainly one place it makes sense to show it; the
palette for Journal objects also makes sense. I like the idea of
exposing it as blocks, and agree with Bert that its essential that
those blocks be linear. With that approach, maybe the details view is
the only place that there is room to illustrate size that way.

One approach to showing size might be to "pretend" that we're in base
9, so that one "big block" is 1MB, and 9 small blocks stack together
in a 3x3 grid to form a big block. I'm not sure granularity needs to
be more precise than that (though we could also show a precise value
as a number, too).

>> Now, I thought of an extra column "Size", showing the size of the file in
>> bytes.
>
> I don't think taking away space from other columns is a good idea on the XO.

Agreed.

> Reclaiming space sounds like a good use case for a separate activity that
> shows the data store in a view optimized for this particular task.

Long ago, we anticipated that the Journal would, at some point when
space reached a critically low point, assist children in cleaning up
their Journals. The plan was to create some heuristic for identifying
entries in the Journal that may not be that useful, and/or would be
most beneficial to remove. For instance, with versioning, it might be
safe to remove old and/or intermediate versions that were auto-saved;
it might be safe to remove really old entries that aren't starred;
entries that haven't been opened in a while; entries that are extra
large; etc. Entries that fit several of these conditions might be the
first recommended.

Anyway, in "cleanup mode", we could present a list which did highlight
size as a key element. Basically, take your suggestion of making a
separate activity, and just wrap it into a separate mode of the
Journal instead. Whether or not this mode was always entered
automatically, or also had a manual trigger, would need to be decided.

Perhaps instead of representing the total number of blocks the Journal
takes up, this mode could instead represent the number of blocks
needed to be cleared to continue using their Journal normally. Then
kids could compare the blocks of various entries against the remaining
number in their "goal" meter to make decisions about what to remove.

Eben


>
> [1]
> http://git.sugarlabs.org/projects/sugar/repos/mainline/commits/85b833960ded9148fbb42e773720ba3bcb02145e
> [2]
> http://git.sugarlabs.org/projects/sugar-toolkit/repos/mainline/commits/6c3fd0346c1876ad501c3c91d50cdf42f7e0a9dc
>
> CU Sascha
>
> --
> http://sascha.silbe.org/
> http://www.infra-silbe.de/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQEcBAEBAgAGBQJLvbtrAAoJELpz82VMF3Da7/kH/R6IMUCJi9QUEgSFGrj88EmO
> /OhArTf2vHaeiovI4Ew06xDdQLZbtLoX3+0AdXHyuMvKg+aR93F7BdGkXozB4QBY
> Dm3P6yOCI25yIKjolAOEoLpujDiHPOCldqEjqMnvmshv3IlgaB1dIM/KHQa0OY43
> I5qZYz6xxZ8fUPv238y+11qiId1VedWLHPiQVb0xHRJAELDRtiXv+D325zOrM8cm
> qY34Rq+NNF0bPDxHVCmDJ2J/QQvk40U5JD0qoxyNhWy77XVpWJHJwrSJxVqZGVAQ
> UvKojBYCxipDAsNwfPTeXX7NsSuS3/0TORpnLk/2HcZkYD/VbiOksLR//Q0eH/4=
> =RBBS
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>