This is getting a little out of hand, here. Let's break this down again, because I think we're all arguing for pretty much the same thing.
On Wed, Aug 20, 2008 at 12:19 AM, Bastien <[EMAIL PROTECTED]> wrote: > "Eduardo Heleno" <[EMAIL PROTECTED]> writes: > >> But my point was that, at the moment, you can choose to "Erase" an item, and >> it's gone forever. I expect that many kids will do this, and will at some >> point >> regret erasing some item. > > Yes. This is a request that has been made here in Haïti. The issue of deletion confirmation is covered under ticket http://dev.laptop.org/ticket/7859. I flagged it as blocks?:8.2.0, but I don't think it is going to be nominated as a blocker at this point unless there is a strong push for it. This is, at least for now, independent of the "trash can issue" itself. On Wed, Aug 20, 2008 at 1:27 AM, Bastien <[EMAIL PROTECTED]> wrote: > "Martin Langhoff" <[EMAIL PROTECTED]> writes: >> >> AFAIK, the plan is to *discourage* deletion until the disk is getting >> full. When you are getting to disk-full, "trashcan" doesn't help. > > Yes it does: it contains entries that the system can safely delete > without forcing the user to go thru the entries and sort them out on > the fly. This is no less true in the future Journal design. Anything which has been previously erased can be transparently deleted by the system without another prompt. The Journal should be following a lazy-deletion strategy, making it really no different from the trash can you speak of. The only difference is how the "erased but not yet truly gone" files get represented to the user. > People now want deletion because the Journal is not optimal. They want > deletion to sort out entries in the Joural and get rid of unfinished or > useless entries. With too many entries, the (current 703/708) Journal > becomes unusable. I do recognize this. The one detail we could add to potentially solve this argument is a button which turns on/off visibility of erased entries. That is, a button which basically shows and hides "trashed files" by toggling their visibility inline within the Journal, in addition to a way to view only those files as well. >> When you are running out off disk space, we have two cases: >> >> - ds-backup has been doing its job, there's a copy of the files in >> the XS, so the journal has old-and-backed-up files that it can decide >> to rm > > I'm afraid XS servers won't be of use in *many* schools. That's fine. The backup solution is an enhancement, not a requirement. Consider the possible states for entries: 1. Normal: file stored locally on the XO 2. Normal+Backup: file stored locally on the XO, and also on the server 3. Lazy-erased: file stored locally on the XO, but rendered differently to indicate "transient" state 4. Lazy-erased+Backup: same as above, but also backed up to the server 5. Erased: not stored locally on XO 6. Erased+backup: not stored locally on XO, but still available on the server States 1, 3, and 5 are the basic states without backup in the picture. They map directly onto a file, a trashed file, and a file which has been emptied from the trash, respectively. Without a server, you can still recover anything in state 3. When you have a server, you can recover anything in states 3, 4, and 5 (call these the "recoverable" states). In all of these recoverable states, we will visually represent a the entry in a way distinct from normal, "present" entries, and the entries in these states will have buttons which allow them to be a) recovered or b) permanently erased. If we want, we can be a bit more clever about which cases require deletion confirmation (based upon whether or not the action results in a recoverable state), but we could simply ask for confirmation all the time for consistency. Or, never. >> - no old-and-backed-up files we can safely remove? Prompt the user > > I'm curious whether someone did this job of being prompted. > How long does it take? If you can't remember what a file contains, > checking if it's safe to delete it by trying to reopen it might be > tiring. The Journal does (will do) better than many other systems. The preview is sadly underutilized at the moment, but it should provide a hint without the need to open it. We have a few ideas about how to encourage naming and tagging as well, which will improve this situation a lot. Finally, we have the notion of favorites in the Journal. If we encourage their use as well (which we will in the next version, since it will be possible to filter the list to show only favorites, thus eliminating the unwanted entries which currently make it difficult to find things), then it should be easy to at least preserve the things you've already indicated in the past mean something to you. We'll also have true versioning in the future, so it will be possible to prune the version tree, keeping fewer intermediate versions the further back in time we look. 2008/8/20 <[EMAIL PROTECTED]>: > > prompt the user, interrupting whatever they were trying to get > done? that seems less than optimal. if my current UI-of-choice > implemented "disk full" this way, i would have long > ago created personal mechanisms help me organize my work into > "very important, must save", "would be nice to keep, but i can > recreate it if i want", and "don't really need it, but i won't > throw it away until necessary". Well, not entirely. The system can transparently remove entries in state 4, when it has been lazy-erased and is also backed up, since this doesn't change the perceived state of the file (that is, the child said "I don't need this" already, and has to hit restore to get it back. The restore would have been faster before the erasure of the local copy, but as long as restore works, things are fine). Also, the intention for the alert, again, is to have the Journal indicate to the user that things are getting full. When this happens, the Journal will create a suggested list of files/entries it thinks are expendable. This list will be created with knowledge of what things are favorites, what things are backed up, what things have ben recently used, or used frequently, how large they are, etc. Thus, the Journal will cheerily aid you in sorting everything into piles, and then let you review its efforts to make sure it didn't make a mistake. The goal is to make this step as painless as possible, if its ever even required. (We can, of course, indicate to the kids that "The Journal is getting full" well before we indicate "The Journal is full"; only in the latter case do we need to pull them away to deal with the issue Right Now.) I hope this clarifies my position on this subject a bit, and paints a picture which is really just a different perspective on the usual "trash can" metaphor, rather than an abandonment of it. - Eben _______________________________________________ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar