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?
