Andre Poenitz wrote:
That said, I also agree with
Abdel that we shouldn't bind ourselves to doing that if it makes things
overly complex, and I don't really care that much how things are passed
back and forth from the GUI. But that's really a separate issue from how
ICP works. You can build an ICP without all the stringification. You just
do it directly:
params.setParam("bibfiles") = whatever;
I understand that. But all such parameters are bound to a specific Inset
instance, so why is this not
InsetBibFoo::setBibFiles(whatever);
?
Actually, the parameters need not be bound to a specific inset instance
when they are created, and very often they are not. This is one of the
things Georg most strongly insisted upon, and I expect it's really the
core reason that ICP is separated out from the insets the way it is. In
the GUI, for example, instances of InsetCommandParams are used to
represent the state of the parameters *according to the dialog*, not
according to the inset. So those are not bound to any inset (though the
dialog may be). In short, an instance of ICP is the *kind* of thing that
might be an inset's parameters, but it doesn't actually have to be an
inset's parameters. Of course, there are sure to be way to work around
this. You could create insets in the dialogs and use them to represent
the parameters. But I don't expect you want to do quite that.
So if the idea was to roll ICP into the insets, well, I'm sure you could
do that, but it would involve a lot of changes elsewhere.
Richard
