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

[sampo nurmentaus movial fi]

Hi,

> 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.


Br,
Sampo