Re: File selector talk writeup

[Owen Taylor <otaylor redhat com>]

On Thu, 2003-02-13 at 12:48, Thomas Leonard wrote:

> API-wise, the most important features for DnD saving are:
> 
> - Notification of when the save finishes (so the data can be sent to the
>   remove machine / application).
> 
> - A separation between where the file is actually saved and where (and
>   whether) the application should report it as saved and mark it
>   unmodified.
> 
> Some examples might make it clearer:
> 
> Case 1 (normal save):
> 
> 	App->GTK: Save a file, default name TextFile.
> 	GTK->App: Save it to ~/MyFile.
> 	App->GTK: Done.
> 	GTK->App: Data is safely saved as ~/MyFile.
> 
> Case 2 (saving to remote machine):
> 
> 	App->GTK: Save a file, default name TextFile.
> 	GTK->App: Save it to /tmp/foo1234
> 	App->GTK: Done.
> 	GTK->App: Data is safely saved as file://some.host/path/TextFile
> 
> Case 3 (saving to another application):
> 
> 	App->GTK: Save a file, default name TextFile.
> 	GTK->App: Save it to /tmp/foo1234
> 	App->GTK: Done.
> 
> This all assumes using a temporary file for transfers. In python, we use
> stream objects, but I guess people don't want to make this so ROX-biased,
> and the tmp-file solution works well enough for us.
> 
> Is this / could this be considered?

I'd have to say this is all out of the scope of what I was considering
for the GTK+ file selector. Everything is a lot simpler if the 
file selector is simply a way of getting a filename or filenames.

If you actually do the saving as part of the interface, then 
you get all sorts of additional problems:

 - Stream interfaces. gnome-vfs has an entirely different stream
   interface, so does Bonobo, if I recall. GIOChannel is in GLib, but
   rather crude, etc. I assume that ROX's stream interfaces are
   different from any of these.

 - Backup files, files with history embedded, and other reasons why 
   the saving application might be doing something more complex
   than simply writing out the data.

 - Libraries for saving content that want just a filename.

It seems to me that with a filename based approach, what you loose for
DND saving are:
 
 - Being able to do snap-back animation for the drag if the save
   fails for some reason.

 - Being able to transparently do remote saving by pushing the save
   data over the X connection.

But you gain a whole lot of API simplicity.

Regards,
                                               Owen