У Пнд, 2005-01-31 у 13:16 -0500, Sean Middleditch пише: > 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. The save button doesn't have to go completely, it can still be there for those cases. I agree though that it would be better if it was completely unneeded. Abiword can save the file at every keystroke, appending information at the end of the file so that this operation is fast. It's a file format change, though, granted. > 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. So that's what we need. Implementation ideas? :) > 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. I think the concept that while editing a document you can't copy it (or at least you don't get a consistent copy is easier to explain than the difference between RAM and the hard disk. And if the saving is fast enough, you _can_ copy, send by email and everything at every time. I think the saving can be fast enough. We'd need only the file format change. Markus -- Markus Bertheau <twanger bluetwanger de>
Attachment:
signature.asc
Description: =?koi8-u?Q?=E3=C0?= =?koi8-u?Q?_=DE=C1=D3=D4=C9=CE=D5?= =?koi8-u?Q?_=D0=CF=D7=A6=C4=CF=CD=CC=C5=CE=CE?= =?koi8-u?Q?=D1?= =?koi8-u?Q?_=D0=A6=C4=D0=C9=D3=C1=CE=CF?= =?koi8-u?Q?_=C3=C9=C6=D2=CF=D7=C9=CD?= =?koi8-u?Q?_=D0=A6=C4=D0=C9=D3=CF=CD?=