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

[Bastien]

"Eben Eliason" <eben.eliason at gmail.com> writes:

> 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.  

I'm not fond of confirmation alerts, no problem if this is not in 8.2.0!

> This is, at least for now, independent of the "trash can issue"
> itself.

To me it's not completely independant: a trashbin (or an equivalent)
feature) functions as a virtual confirmation system.  I think having 
a trashbin somehow spares the cost of confirmation alerts.

> The Journal should be following a
> lazy-deletion strategy, making it really no different from the trash
> can you speak of.  

Ok, fair enough

> The only difference is how the "erased but not yet
> truly gone" files get represented to the user.

Yes, that the difference I'm interested in :)

> 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.  

Let me guess: this button is usually what the trashbin icon does?

> 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.

Ok, good.  The  button itself would be visible.  The trashed files
wouldn't be visible until the button pressed.  When the button is
pressed, only trashed entries are listed.

> 3. Lazy-erased: file stored locally on the XO, but rendered
> differently to indicate "transient" state

Ok, great - for me lazy-erased files should not be displayed unless the
trashbin button is pressed (in which case only trashed files are listed.
Sorry to repeat myself...)

> 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.

Never :)  (never as a default - maybe this could be customisable.)

If the default is to rely on confirmation, this will not encourage users
to lazy-erase their files.  With no backup system, it's becomes more
important to encourage them to be selective about what they keep,
encouraging regular cleaning up.

> 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.

Ok, great - things are very clear now.

Can't wait for it to be implemented :)

-- 
Bastien