|
ERDI Gergo wrote:
> > Quite simply, a file icon is added to
the Save As dialog box which may
> > be dragged to > > (a) a File Manager window, or > > (b) another application. > > Hmmm. Personally, I can see the benefit of a), but b) just strikes me > as wrong. Save As does just that - it saves the document to a file. > "Saving" to another program should (IMHO) involve cut/copy/paste or > Bonobo-esque embedding, which removed the need for b) in the first > place. That's a very
valid point, assuming that you already have a document to
embed. However you would have to either create a document in the first application, save it to a temporary file, and insert that temporary file as an embedded component in the second application, or create a "New" empty embedded object in the second application which can then be edited in-place (and all programs would then have to support this additional functionality). Notice that the system I propose does not preclude the use of in-place editing; it merely allows for "push-" embedding and not just the usual "pull-" embedding if you know what I mean. (This directly corresponds to "save-" embedding versus "load-" embedding.) Additionally, as you remarked, (a) is obviously useful; however it won't hopefully be too much more effort once that is done to implement (b) (just use the standard D'n'D or even the Cut/Paste mechanism). Remember that if you don't like it you don't have to use it; it's just a slight addition to the current paradigm: why should only disk-based containers be able to hold new objects? I believe that the processes of storing something to disk, the process of save-embedding into a separate application, and "saving" to email, i.e. sending, should have a reasonably similar interface: in all situations you are placing the object firmly where it belongs for later use in the way that is intended. Try explaining to a computer newbie what the difference between saving to disk and having something loaded into memory is. They think the computer case is the "hard-drive", that the hard-drive is the "memory", and that the 3.5" floppy is a "hard-disk"... Visual saves are good, and why should drag-saving to Nautilus (which will probably display the file contents in an icon) be any different to drag-saving to SodiPodi (which will display the "file contents" embedded in the document)? Go back to the original desktop metaphor.. One last thing: as I mentioned this facility has been around in Acorn RISC OS for years (since 1987). RISC OS is a British OS which ran on the ARM processor (the Acorn Archimedes was the first 32-bit home computer). Thousands of RISC OS users will tell you that it doesn't take much of a stretch to learn how this works, in fact it's quite natural and easy-to-learn, even for new users. Luke. [As an aside: Back in 1987 RISC OS had a panel (Task Bar) and windowing system very similar to GNOME's today, and way before W95 came out with some similar stuff (remember this is in the days of W3.1). We share some common philosophies and I think it would be worth it for some GNOME UI people to check out the RISC OS Styleguide.] |