<div dir="ltr">2008/8/19 Zarro Boogs per Child <span dir="ltr"><<a href="mailto:bugtracker@laptop.org">bugtracker@laptop.org</a>></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
#8041: Sugar lacks a "Trash/Recycle bin" system<br>
--------------------------------+-------------------------------------------<br>
   Reporter:  HoboPrimate       |       Owner:  Eben<br>
       Type:  enhancement       |      Status:  new<br>
   Priority:  high              |   Milestone:  9.1.0<br>
  Component:  interface-design  |     Version:  Development build as of this date<br>
 Resolution:                    |    Keywords:  9.1.0:?<br>
Next_action:  design            |    Verified:  0<br>
  Blockedby:                    |    Blocking:<br>
--------------------------------+-------------------------------------------<br>
Changes (by Eben):<br>
<br>
  * next_action:  never set => design<br>
 * cc: christianmarc, tomeu, martin.langhoff (added)<br>
  * priority:  normal => high<br>
  * version:  not specified => Development build as of this date<br>
  * milestone:  => 9.1.0<br>
  * keywords:  => 9.1.0:?<br>
<br>
<br>
Comment:<br>
<br>
 The Journal is, by design, meant to make a trash system completely<br>
 unnecessary, on account of an incremental backup mechanism that allows<br>
 kids to peruse record of (preview, title, description etc.) things they've<br>
 made and since deleted (much like looking in the trash), as well as<br>
 restore individual files from backup if they want to recover them again<br>
 (much like removing something from the trash).  There will, of course,<br>
 also be a way to permanently erase entries which they don't want any<br>
 record of anymore (much like emptying the trash).<br>
<br>
 Obviously, at some point, there won't be enough backup room either, and<br>
 things will have to go permanently, but this can be handled in much the<br>
 same way that the initial deletion process happens, which, as is described<br>
 in many other places, should guide the user through their documents,<br>
 suggesting a number of entries for deletion based on some heuristics<br>
 (including backup-present, file size, favorite status, recency of use,<br>
 frequency of use, etc.).<br>
<font color="#888888"><br>
--<br>
Ticket URL: <<a href="http://dev.laptop.org/ticket/8041#comment:2" target="_blank">http://dev.laptop.org/ticket/8041#comment:2</a>><br>
One Laptop Per Child <<a href="http://laptop.org/" target="_blank">http://laptop.org/</a>><br>
OLPC bug tracking system</font></blockquote><div> </div></div>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.<br>
I understand the idea of the backup system. I still propose for the existence of a ~/.Trash directory, either on the XO, and/or on the users /home directory at the backup server, used explicitly to store "erased" entries, with strict limits on the size and age of items stored there.<br>
</div>