On Wed, 24 Mar 1999, Alejandro Aguilar Sierra wrote:
> On Wed, 24 Mar 1999, Allan Rae wrote:
>
> > In my language it would be derived from InsetParbox not InsetText.
> > The recent discussions have:
>
> The editing mechanism is so complex that it's recomended that all text
> insets share it, so InsetParbox might be derived from InsetText anyway.
It may in fact be better to derive from a second parent that knows about
flowing in rectangles rather than forcing some weird hierarchy in Inset
ie. multiple inheritance using a mix-in class for flow.
> > class InsetParbox : Inset {
> > list<Paragraph *>;
> > }
> > class Paragraph : ??? {
> > vector<Inset *>;
> > }
> > class InsetText : Inset {
> > LString;
> > }
> In this model InsetParbox and InsetText are not related. A bad idea, as I
> explain in my post about inset structure.
As Asger has explained (or at least as I understand it) Asger's InsetText
is just a fancy InsetString (a string of text with some extra local font
change info). Its got almost nothing to do with the InsetText from the
current code base. Asger's InsetParbox is more like an improved version
of the existing InsetText (your InsetText (and Juergens)).
Asger's InsetParbox flows text and insets by managing the flow of the
different insets in its vector<Inset *>. A bit more complicated than the
existing InsetText -- it would probably be easier if each inset could flow
itself and then Asger's InsetParbox would have a simpler job of managing
the flow. That may in fact be what he wants I'm not sure.
> > So surely a minipage would be either
> >
> > class InsetMinipage : InsetParbox {
> > }
>
> But this is what I meant in my reply!
I thought that might be the case but I wanted to be sure. There's more
than enough misunderstandings already.
> > or
> >
> > class InsetParbox : Inset {
> > bool minipage;
> > list<Paragraph *>
> > }
>
> imagine that we have a bool for each specific kind of InsetParbox.
> Impractical, isn't it?
How about an enum? Its a sort of meta-paragraph characteristic anyway
belonging above paragraphs but below document level.
[...]
> > It might even be conceivable that footnotes and margin notes would also be
> > variants (a union within if you prefer) of InsetParbox. Since IMO every
> > section should also be collapsible like an outline editor or a folding
> > editor. That would mean that rather than a derived InsetCollapsible we'd
> > simply need a bool in a layout style to say whether its foldable* or
> > collapsible or not.
>
> A foldable inset has two drawing methods. (btw another example of a
> "foldable" inset is the math macro.) The basic (current) InsetText only
> has one drawing method, the intermediate class InsetCollapsible provides
> the second method so all derived text inset are foldable.
So do we really need to have that extra derivation step? If we allow a
layout to define whether or not a particular style is foldable or not then
with a separate InsetCollapsible each time we change a paragraph style
from a non-foldable one to a foldable one (or vice versa) we'd need to
convert it into a different Inset type!
I don't think I've convinced anyone yet of the desirability of layout
files controlling foldability but I hope to :-)
Even if we simply said that we will only support folding at normal outline
mode places like sections and subsections then they would all need to be
InsetCollapsible. If I then changed my mind and converted a Section into
Standard then LyX would need to convert the InsetCollapsible into an
InsetText (that is, the existing version of InsetText). If LyX didn't
then the derived type (Collapsible) would still be the one handling all
the calls and I could still collapse it.
So I therefore suggest that make folding a layout based attribute and
merge the current InsetText and InsetCollapsible (merge in Asgers ideas
and we have the new improved InsetParbox).
[...]
> foldable is shorter so it's better. :)
s/InsetCollapsible/InsetFoldable/g
Allan. (ARRae)
