On Tue, 23 Mar 1999, Asger Alstrup Nielsen wrote:
> Here's my idea of the inset design at the moment. I hope this will
> settle the discussion between Alejandro and Allan, which mostly is a
> discussion about words.
Just in part. I understand when you use wrongly the word "inset" as a
structure that holds font info, etc. I disagree with this usage but
we won't stop the much more interesting discussion on the internal
structure for this. (I just read that Allan will forget about font
insets anyway, so let's all do it as well.)
Currently in 1.1 the text inset (InsetText) is the base class for all
insets that have inside editable text and that can be adapted to a
given box. I'd like to keep this terminology (not the model): the
most basic text inset to be the InsetText and use other names for
more complex text insets.
> We have an inset that can contain a list of paragraphs. This inset
> corresponds to the flow inset: We give it some geometry to tell it
> where to draw itself, and it returns information about what screen
> estate it needs to do the job (i.e. the height). Let's call this inset
> a InsetFlow for the lack of a better name (I want to preserve the name
> InsetText for something else. See below.) This InsetFlow contains a
> list<Paragraph *>.
With this description it's clear that the Paragraps don't have to be
insets, they are already contained by an inset that would manage the
geometry.
> A paragraph is not necessarily an inset, but it contains a vector<Inset
> *> that holds the text of a paragraph. It also contains a pointer to a
> ParagraphParams structure that keeps all the structural information:
> Which layout it is, the nesting depth, whether it's a heading or not,
> and all the other information that we have in the Paragraph * structure
> now. (Notice that this information is enough to solve the nesting
> problem that Allan posed.) By moving these parameters to a
> ParagraphParams structure, we can save a lot of memory, because the
> ParagraphParams structures can be reused.
yes, this seems to be clear.
> Besides the InsetFlow and the Paragraph, we have the ordinary glyph
> Insets: References, label, math insets, and others. Take the footnote
> inset. This is an inset that contains a FlowInset. Next to these
> "ordinary" insets, we also have the InsetText. This insets contains the
> text of the document, in the form of an LString. It also contains a
> pointer to a CharParams structure, that is similar to the
> ParagraphParams structure, and contains the information about the text
> in the inset. This includes Font, Logical Font, language and other
> character level information.
So you suggest the InsetText to be a very basic text inset without no
information about font changes nor other insets allowed in its
contents. Some sort of atomic text inset with an LString as basic
container. And are the other text inset derived from this one or are
they independent?
At first sight I see this model impractical and unnecessarily
complex. Imagine you have a very large phrase without font changes
that have to be broken in several lines to fit on the screen.
Immediately becomes impractical to have it all inside a rectangular
inset. I guess your answer would be: let's break it in three insets,
as your example of the three boxes for a footnote inset. Or better,
never allow a basic text inset to have more than one line. If it goes
beyond the box boundaries, break it!
> Notice that this implies that we will have no more Inset-codes, no more
> font tables, and no more inset tables.
We all agree in that it's necessary to get ride of that stuff, what
is not clear is how to do it. Your model doesn't automatically
eliminates the need of the inset codes. You have to check how and
where are they used. It does with font and inset tables, but still is
not IMO a very ellegant solution (the low levet font info
structures).
I'll discuss this later (see below).
> This design is the result I have come to from the discussions we have
> had so far. There are more details about this in my head, and this is
> what I'll try to write down in a proposal kernel document when I get the
> time. However, if you feel that this overall approach is flawed, please
> tell me.
At least it is not complete. How are InsetText and InsetFlow related in
your model and can an insetflow be contained inside an insettext (I guess
the insets that are contained in a paragraph are insettexts).
IMO a simpler solution would be much better:
1- A paragraph would have only the ParagraphParams and a container with
the text data. It would not be an inset.
2- A text insets would contain paragraphs and would manage the
geometry: that is, to break paragraphs in lines on the screen (or
in a box) making it to "flow". Maybe a very basic inset would not
allow more than one line (and of course no more that one
paragraph.) This kind of basic text inset would be used as "text"
mode inside a math inset.
In the most basic cases we could have only a text inset, the
workarea inset. In case of having other text insets (footnotes or
whatever) they would use the same mechanism to edit and draw that
the work area in a recursive way.
The current InsetText (the real one in 1.1) is repeating several
things already used to manage normal text on screen. This kind of
redundance is not good because editing is rather a very complex task.
The solution is to adopt a recursive way. Please give me some
credit, this is the way the nested math insets are designed! An equation
on the screen is as inset as the most deeper sqrt inset inside it. I
don't see why this model can't be applied to the more general text case.
3- About the font info stuff. In LyX the font of each paragraph is
defined by its layout in a paragraph basis and there are font info
structures that changes locally this info. IMO we don't need to
have a font info for each... (let me call it) phrase. We have already
the font info corresponding to the layout of the paragraph. Local
changes can be setted by simple high level logical style codes.
This can be done with a smarter font class. And we ellimintate
both font tables and font info structures inside a paragraph.
4- With all this in mind, the remaining structure to discuss is the
"atom" container (which btw has never been an LString and it
doesn't have to be it). Imagine it as a vector<int*>. Even a single
character would be an inset. How to save from the memory bloating?
See the Flyweight pattern (pag. 195, Design Patterns, Gamma et al
1994, complete reference in the devs homepage).
Other solution would be vector<wchar>. Some values beyond the
boundary of useful values for char codes would be special codes
like style codes and inset indices from a global inset container
(gic). From the vector<wchar> we could get an inset index and
we would get the real inset* from the gic. Yes it is something
like the old inset table but it is not carried inside each
paragraph, it is global like a memory manager.
In both approaches we would take full advantage of STL iterators
and basic operations like copy, cut, paste, search, replace, etc
would be made almost as easy as applying directly STL algorithms!
However this solution is not yet perfect. Your turn! :)
Alejandro
