Re: [Sugar-devel] [DESIGN] Show file size in Journal
On 08.04.2010, at 02:42, James Cameron wrote: I'd like to see file size described as a row of dots; quantity determined by logarithm to base 2 of size in bytes. ;-) If you want a logarithmic scale, use numbers. Those are logarithmic (though maybe base 10 would work better than 2). For a graphical display, it really should be linear. The major use case is probably to free up space. The visual sum of two entries should equal the size of a single entry that occupies the same disk space as the two. Deleting the two would have the same effect as deleting the larger one. An implementation problem is that the datastore does not track file sizes. It's not part of the metadata, and there is no stat() call on a Journal entry. Also, on compressing file systems (like JFFS2 on the XO-1) it probably should show physical space taken. And take metadata into account too - many entries have no file but still take up quite some space due to their metadata. Maybe instead of adding it to the existing Journal views it should be a separate view? If deleting items is indeed the primary use case there could be a view that shows sizes and allows easy deletion ... - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Show file size in Journal
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. 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. 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. [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/ signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Show file size in Journal
On Thu, Apr 8, 2010 at 7:18 AM, Sascha Silbe sascha-ml-ui-sugar-de...@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@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Show file size in Journal
On 08.04.2010, at 13:47, Eben Eliason wrote: On Thu, Apr 8, 2010 at 7:18 AM, Sascha Silbe sascha-ml-ui-sugar-de...@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. In the details view you only see a single entry, I'd expect the exact size shown numerically there. The graphical form is much more useful for visually comparing multiple entries. 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). Just to be pedantic: that would still be linear, not base-9 logarithmic ;) Otherwise the idea is sound, at least for entries up to a few MB. But what about larger ones? Given that Sugar runs on netbooks that frequently have a 160 GB disk, there should be some theory about dealing with large files IMHO. - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Show file size in Journal
On Thu, Apr 8, 2010 at 8:35 AM, Bert Freudenberg b...@freudenbergs.de wrote: On 08.04.2010, at 13:47, Eben Eliason wrote: On Thu, Apr 8, 2010 at 7:18 AM, Sascha Silbe sascha-ml-ui-sugar-de...@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. In the details view you only see a single entry, I'd expect the exact size shown numerically there. The graphical form is much more useful for visually comparing multiple entries. 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). Just to be pedantic: that would still be linear, not base-9 logarithmic ;) Yeah. Otherwise the idea is sound, at least for entries up to a few MB. But what about larger ones? Given that Sugar runs on netbooks that frequently have a 160 GB disk, there should be some theory about dealing with large files IMHO. Well, for arguments sake, we could assume that 1 unit (about 114 bytes) is 5px square. So 1MB (9 units) would be, say, 5*3 + 2 (for spacing) = 17px square, and therefore up to 9MB is representable within 17*3 + 4 (again, for spacing) = 55px square. That's exactly the maximum area of an icon within one grid cell. Maybe that's too small, but maybe not. The real problem is that linear (which we both want) is fundamentally non-scalable in a fixed screen size. Without a logarithmic scale for size, we'd need to have a zooming factor to continue to fit more blocks into fewer pixels. Perhaps we could drop down to 3px squares for the smallest unit after some critical point. Or, we could try using colors/values to convey the difference in block sizes. Unfortunately, it's a bit harder to educate that 9 blue blocks equals one red block than that 9 small blocks equals one large block. Eben - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [DESIGN] Show file size in Journal
Hey, Bernie and I have been discussing about showing the file size in Journal view of Sugar 0.84.x, because: bernie | km0r3: kids really want to know how big their files are Now, I thought of an extra column Size, showing the size of the file in bytes. 1000 Bytes - 1Kbyte 1000 kB- 1Mbyte [...] Follow-up questions: 1) What to do if filesize is 0/none ? 2) Display the file size optionally? -- Kenny Meyer signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Show file size in Journal
I'd like to see file size described as a row of dots; quantity determined by logarithm to base 2 of size in bytes. ;-) On Wed, Apr 07, 2010 at 08:43:29PM -0300, Kenny Meyer wrote: Follow-up questions: 1) What to do if filesize is 0/none ? Display 0/none, or at least add the size of the metadata. 2) Display the file size optionally? In the journal list, or in the journal details? Perhaps it should be a configuration option. Other sizes that could be displayed: - total size and remaining space on storage of system, - total size and remaining space on removable storage. -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
