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


I want to create an alternative implementation of GtkFileChooserDialog
that doesn't implement a file chooser window itself, but instead
invokes an external, trusted process to provide a file chooser.  This
is for security purposes -- skip ahead for more on the reasons.

Basically I want to treat GtkFileChooserDialog as an asynchronous
call-return interface, so that:

* gtk_widget_show() on the GtkFileChooserDialog sends a message to
  the external process asking it to open a file chooser.  The message
  will contain the start directory, default file leafname, etc.
* When user chooses OK/Cancel, the external process replies and the
  GtkFileChooserDialog invokes the GtkDialog response signal.
  The filename is returned so now gtk_file_chooser_get_filename() can
  return a result.

Nice idea. I have also been thinking about running file chooser in
a process of its own, to ensure that all the allocations it does
are freed back to the system on a resource limitied device.

The way I tough it was that I need to creat a dialog that is
run like any other dialog in the context of the  application in question.
But then the contents of the dialog are provided by another process
using GtkPlug/Socket. This provides you the possibility to
provide the UI for selecting files from another process, while
keepping the interface for the application programmer simple.

Haven't tried this in practice, so I don't know all the problems
it might cause with key events etc., but if you are
intrested in trying, please let me know.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]