Andre Poenitz wrote:
> On Thu, Jun 12, 2003 at 10:06:00AM +0000, Angus Leeming wrote:
>> André,
>>
>> how do you forsee IU of the simple things like "button insets" panning
>> out? Will they take a form similar to that in mathed where the inset
>> itself derives from MathNestInset and is wrapped in an interface to the
>> outside world (Formula), or will it be something like the code in insets
>> where the inset and its interface to the outside are one and the same
>> thing?
>
> The latter.
>
> Basically, Inset, InsetBase and MathInset should be the same thing
> (plan is to move common parts from Inset and MathInset to InsetBase
> until Inset and MathInset are empty, kill Inset and MathInset and
> optionally rename InsetBase to Inset)
>
> The "glue" InsetFormula should not be needed in the end, so basically it
> will be merged with MathHullInset to a 'new' InsetFormula.
>
> The derivation of (Math)ButtonInset from MathNestInset is just a hack to
> get a container "for free". I guess a simple string member would have done
> as well (or even better).
Hmmm. The nice thing about MathNestInset of course is that the data is
stored so:
typedef std::vector<MathArray> cells_type;
cells_type cells_;
so you can take advantage of generic components like the math parser.
The nasty thing about insets/insetcommand.[Ch] is that it is hard-coded as
string cmdname;
string contents;
string options;
which means that it isn't very flexible. No one has had the energy to
enhance the citation inset to handle natbib's second optional arg, for this
very reason.
It seems to me that there are two alternative strategies.
i. Create new mathed insets citation_inset, bibtex_inset etc that take
advantage of your clean, flexible code.
ii. Change InsetCommand to store a std::vector<MathArray> and modify the
derived insets appropriately.
Which strategy would you recommend?
--
Angus
