Andre Poenitz wrote:
> We won't know this until we look at fixing that. I'm inclined, actually, to
> do something more general, namely, to try to bring InsetGraphic into the
> InsetCommand hierarchy. I think this was intended all along as part of a
> more general transition that was never finished.
Could you please elaborate on why having the InsetCommand hierarchy is
useful at all?
As far as I can tell the main benefit was to have a uniform means to
pass "Parameters" through the Controller layer in the Old Days. This
layer is gone now, and it feels a bit strange to pass around unrelated
pieces of data from otherwise unrelated insets in a common structure.
Wouldn't per-inset specific data with direct access from the GUI simplify
overall structure and reduce conversion costs?
Frankly, I don't know the overall structure here well enough to be sure
exactly what the advantages or disadvantages to keeping the
InsetCommandParams business the way it is. Mostly, I try to go on how
Georg explained this to me some time ago, and the understanding I've
developed since then of why he (they?) did things the way they did. In
particular, Georg insisted that we are not to subclass
InsetCommandParams, not unless we have a really, really good reason.
There are times it seems it would be very natural to me to do so, but
Georg made a strong case (I don't remember all the details) for not
doing so, and if that's how he designed the code, then, well, I'm
guessing there are reasons, and I'd probably find them out if I violated
his orders.
I agree that there's something unhappy about the stringification,
unstringification, and so on and so forth. But, as JMarc often says, we
know we have to do that anyway---remember that the strings are in
exactly the form they are in the .lyx file---so it's not that
unreasonable to use the same infrastructure to pass things around. 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;
and then you can pass params itself to the inset if you like. Doing so
has a downside, though, one that JMarc (again) is always pointing out,
namely, that if you go via an LFUN, you get all kinds of updates, etc,
for free; in particular, going via the dispatch mechanism gets you this.
But then you do need a common representation of the parameters being
passed, and a string is a pretty natural choice. (I don't even want to
think about all the casting that would otherwise be required.) But the
main point, really, is that this is a different issue. The conversion
cost question is really separate from the question whether ICP is A Good
Thing. By itself, getting rid of ICP wouldn't help you there.
Anyway, even if there were reasons to do a large scale re-write of this
stuff, I don't see anyone doing that any time real soon. So, unless
someone is going to do that, then, as things stand, I strongly suspect
that there's substantial duplication of code across InsetGraphicsParams,
InsetExternalParams, and InsetCommandParams. (There has to be.) Barring
the massive re-write, then, the strategy I suggested seems sensible. And
for the same reason, barring some large-scale change of direction, I'm
reluctant to introduce InsetBibtexParams and take InsetBibtex out of the
existing framework.
Hope that helps.
Richard
