On Fri, Nov 08, 2002 at 05:22:22PM +1100, Ben Stanley wrote:
> I'm trying to distill the rules for insets and paragraphs...
>
> * Inset classescan only hold a single inset object.
>
> * Paragraph objects are not an inset, but may contain more than one
> inset.
>
> * Paragraph objects may be inserted into an inset tree using an
> InsetText object.
>
> All this must make it rather difficult to traverse the object tree.
Indeed. This construct is broken. It's there only for historical reasons
as far as I am concerned.
> Surely we need a CompundInset or similar, the father of all insets which
> can contain more than one sub-inset. This simplifies ieterators
> enormously.BNut then what happens to the text between the insets?
> Perhaps a new inset is required for straight text.
>
> I am reminded of the design patterns book here, which has an extensive
> example of one way of doing this. if this has been discussed here before,
> could people point me to the discussion?
Have a look at mathed which uses insets differently.
It's the way I believe how insets should be handled The core is:
Everything is an inset which derives from MathInset.
An inset is either atomic (e.g. MathCharInset and MathSymbolInset) or
compound (i.e. MathFracInset derived from MathNestInset).
Compounds consist of a number of "cells", each of which is a plain
vector of insets.
There are of course a few implementation details: I use a "MathAtom" as
some kind of smartpointer to wrap a MathInset *, and outside math it would
probably not very prudent to put each character in an inset of its own, but
there are solutions for this kind of "problem".
> Thinking aloud,
That's fine. Actually my main goal for 1.4 is to "unify" the two
inset hierarchies...
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
