#8041 HIGH 9.1.0: Sugar lacks a "Trash/Recycle bin" system

Zarro Boogs per Child bugtracker at laptop.org
Wed Aug 20 12:41:49 EDT 2008

#8041: Sugar lacks a "Trash/Recycle bin" system
   Reporter:  HoboPrimate       |       Owner:  Eben                             
       Type:  enhancement       |      Status:  new                              
   Priority:  high              |   Milestone:  9.1.0                            
  Component:  interface-design  |     Version:  Development build as of this date
 Resolution:                    |    Keywords:  9.1.0:?                          
Next_action:  design            |    Verified:  0                                
  Blockedby:                    |    Blocking:                                   

Comment(by Eben):

 I pulled this in from the mailing list, since I think it summarizes a lot
 of the discussion.  This is my response to the thoughts of others.  (Sorry
 for the length.)

 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

 On Wed, Aug 20, 2008 at 12:19 AM, Bastien <bastienguerry at googlemail.com>
 > "Eduardo Heleno" <hoboprimate at gmail.com> 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 <bastienguerry at googlemail.com>
 > "Martin Langhoff" <martin.langhoff at gmail.com> 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

 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  <pgf at laptop.org>:
 > 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.

Ticket URL: <http://dev.laptop.org/ticket/8041#comment:3>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system

More information about the Bugs mailing list