On Tue, Apr 01, 2008 at 06:49:25PM -0400, rgheck wrote:
> 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.
You refered to this conversation lately and I had a look then. It
contained sound arguments for the time, with the Controller layer being
still around - which is gone now.
> In particular,
> Georg insisted that we are not to subclass InsetCommandParams, not unless
> we have a really, really good reason.
That's still true.
> 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.
Well, the existence of a road from Berlin to Paris does not necessarily
mean we have to take it when coming from London...
> 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);
?
> 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.
The conversion costs are not outrageous. I would be just a nice bonus.
I question the extra horizontal layer...
> 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.
Right now we have (rough estimation) around 70-80 lines worth of code
handling the Parameter stuff per 'participating inset' (sum of per-inset
glue code and 1/14th or so share of the common infrastructure).
I am fairly sure that per-inset code using a few common helper function
would end up rather in the 20-30 lines range, and be more flexible in
the end as we do not have to stick to yet another framework.
Andre'
