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 _______________________________________________ gtk-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtk-devel-list
