Re: The State of (in)Consistency of Save Confirmation Dialogs

[Sean Middleditch <elanthis awesomeplay com>]

On Mon, 2005-01-31 at 12:04 -0600, Federico Mena Quintero wrote:
> On Fri, 2005-01-28 at 14:17 +0100, Markus Bertheau ☭ wrote:
> 
> > I understand that it would be better if all apps did not expose the
> > implementation model of hard disk vs. RAM, but I don't understand why
> > the behaviour described above should not be appropriate for the
> > currently used model. Can you detail on this?
> 
> You have two cases:
> 
> 1. Already-saved documents with modifications
> 2. Unsaved documents
> 
> When you exit the program, you don't want it to automatically save (1)
> to the existing filename since you may not want the document's changes
> to be on your "final" on-disk version.
> 
> For both cases, though, you may want to save to ~/.gnome2/tmp/myapp or
> something, so that you can re-open those files when you restart the
> program.  The files would be deleted when you actually save the
> documents to a "real" filename, or close them without saving.
> 
> If this model is desirable, maybe the HIG should hint to it.

Hmm, ideally, file formats would be able to include the necessary change
information to restore the undo/redo history.

To make this all really useful, though, you'd need a way for apps to be
notified when the user is about to access a file.  For example, if apps
don't make save part of the UI, then the user has no way to know what
state the actual file is in.  Imagine having a file open in AbiWord and
then dragging the file in Nautilus from its current folder to a remote
folder.  If the user has no way to explicitly save to disk, then the
file copied will probably be an older snapshot, not the current version
the user sees.  So Nautilus (or gnome-vfs, at least) would have to be
able to know that Abiword is working on the file, tell Abiword to save
its changes, and wait for that operation to complete.

While the idea of getting rid of save is really nifty, and something I
think would be a better user interface model, there just isn't way that
GNOME can pull it off in the short-term.  Far, far too much of the basic
system architecture, such as the VFS and almost all file formats, would
need to change.  Otherwise you'd end up with a nasty hybrid where users
never explicitly save stuff but constantly find reason they really need
to.

> 
>   Federico
> 
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>