![](https://secure.gravatar.com/avatar/eb3fe37da4a199eb4e3b479d8a57f808.jpg?s=120&d=mm&r=g)
On Mon, 2004-04-19 at 12:22, Kees Cook wrote:
Hmmm, I like the idea. The one thing that I was trying to preserve was the idea that a external script could have it's own preferences. But, I don't think that is worth saving, and it adds other complications like setting extension parameters externally. I think that if we just make it so that scrips have to use a generated interface, then we can do this, and not have the parameters problem.
That's the way that I'm going to go - any other thoughts?
This may be related to the work I'm doing on the print dialog. There is an interface to put "other" config options into the gnomeprintui dialog, but I wasn't sure how to handle it with the extensions.
Should I just let the extension work directly on the dialog using this GtkSocket? (Or am I misunderstanding how this should work?)
Well, I am still personally leery of extensions providing their own UI -- the problems with extension/driver models that do so (directly, as part of the same module) have been demonstrated repeatedly (in the arena of scanner drivers, for example, compare TWAIN versus SANE).
Of course, in our case, nontrivial extensions often really do demand their own UI. So we can provide them a UI generation facility that is sufficiently flexible (XUL, maybe?), or have a separate category of UI extensions, among which can be specialized frontends for other extensions.
But that is long-term, and just my own thoughts on the subject. For now I think we will have to live with GtkSocket and the understanding that the extension model is still subject to change.
-mental