Re: Call-return interface for file choosers? (and: security using powerboxes)

[Federico Mena Quintero <federico ximian com>]

On Sat, 2005-11-19 at 12:57 +0000, Mark Seaborn wrote:
> Obviously the interface wasn't designed with this in mind.  It is a
> shame that Gtk doesn't also provide a simpler file chooser interface
> that omits control over the dialog box while it is open.  (Contrast
> this with Qt and Windows, which do offer such call-return style
> interfaces.)

GtkFileChooserIface is more or less what you want --- it's the way the
current file-chooser-as-GtkDialog is implemented, and you conceivably
create an object that implements that interface, but that is not a
widget.

The problem, of course, is that applications would not use this
automatically, since they expect to get a descendant of GtkDialog when
they call gtk_file_chooser_dialog_new().

Hildon/Maemo uses an alternative approach:
http://www.maemo.org/platform/docs/tutorials/Maemo_tutorial.html#HildonFileChooserDialog

They basically created another implementation of GtkFileChooserIface
that is also a GtkDialog.  This is still not what you want, but comes
closer.

I wonder if you could do most of what you want by creating your own
implementation of GtkFileSystem, delegating all requests to a separate
process.  If the app tries to access /home/user/.ssh, the file system
implementation would return a GError to indicate that you don't have
permission.

Alternatively, please see the proposal to implement a form of lock-down
for GtkFileChooser:
http://primates.ximian.com/~federico/docs/file-chooser-extension-spec/

You could also leave existing apps as they are, and just modify
GtkFileChooserWidget to instantiate not a GtkFileChooserDefault, but
rather something of your own that delegates everything to a separate
process.  You would then just distribute a modified GTK+ that preserves
the API.

  Federico