On Tue, 23 Mar 1999, Alejandro Aguilar Sierra wrote:
> On Tue, 23 Mar 1999, Allan Rae wrote:
>
> > Why does an Inset need to have a defined rectangular box it fits into?
> > Why can't an Inset be given a box and told to fill this as best it can?
>
> Who said an inset can't do it? In fact the workarea inset would fit your
> description. It would be given a box of the View's size where it would
> drop its contents. Its contents are of course paragraphs.
I got the impression from your first email that you were saying that all
insets were restricted to their rectangular box and making a paragraph
inset would mean we couldn't flow its text.
> > Perhaps a member function that takes a width and returns a height-required
> > -to-fit-everything-in. Not every Inset needs this freedom and quite a few
> > do have fixed size requirements but that is a peculiarity of those insets
> > only and doesn't have to generalize to all Insets.
>
> An example of this kind of inset is a table cell. It would be given the
> width, and it would have to calculate the height.
Exactly what I had in mind when I wrote it although it can equally apply
to a table as a whole or a figure.
> > If something like this existed, and I've gotten the impression from other
> > discussions that others want to flow text like this, then I see no reason
> > why an InsetParagraph couldn't exist and couldn't flow to fill whatever
> > box it's put into.
>
> The problem here is that there seems to be a misuse of the word "inset".
> In few words an inset plays the role of a glyph inside a paragraph. Basic
> paragraph properties don't deserve an inset. However we can encapsulate
> some things in an inset that goes beyond the original purpose of the
> insets.
We've been discussing making everything an Inset so the term "inset" has
changed its meaning slightly. I wouldn't describe a table or a figure as
a glyph but they are both Inset types now. There is already the InsetText
and InsetFootnote and so on that aren't really glyphs either. So "inset"
has moved beyond just quotation marks and unusual characters. Then again
maybe I have a different idea of what a "glyph" is. :-)
[...command vs. environments...]
> > As to whether or not an InsetParagraph should be included here's a short
> > list of observations:
> >
> > * A single layout style may affect multiple paragraphs
>
> We could move layout styles to be a text inset attribute. A text inset
> contains a list of paragraphs, a paragraph is a container of text data.
This text inset is almost exactly the same as what I've called an
InsetContainer except a paragraph is made up of a list of Insets where
those Insets may be strings of characters or InsetQuotes or InsetMath or
InsetWhatever. We (well I do anyway) want to eliminate the inset tokens
that we currently embed in our text strings and make them Insets instead.
Most of this has or is happening already. As a result of these changes
the Insets are no longer just the old Insets they used to be.
> > * A single paragraph may have multiple Insets
>
> In the classic mean of an inset, playing the role of a glyph.
Except a font change isn't a glyph but it still needs to be an Inset.
The table of fonts and positions in the existing code seems to me to be
more restrictive than having InsetFonts.
> > * A single paragraph may have multiple fonts changes within it
>
> [Things related with latex/sgml generation]
>
> > We seem to be agreed on using paragraphs as building blocks for a document
> > so one question is: If we don't have a paragraph Inset which Insets are
> > allowed to contain Paragraphs? or do none of them contain paragraphs and
> > we figure out where a paragraph begins and ends by some interpretation of
> > Insets (eg. everything between two InsetLayouts is a single paragraph)?
>
> No, as you told before, several paragraphs can have the same layout. IMO
> the text inset would be the base for all insets that can have editable
> text. It should be able to hold several paragraphs inside, as a list of
> data containers.
But InsetText as in the code is something different although it could be
expanded to meet your description.
> I had not followed this thread until now but I have the impression that at
> this point there are some kind of "inset abuse". What you call InsetFont
> and InsetLayout are not really insets, they are not glyphs but local
> properties. That doesn't mean that I disagree with your ideas but I do
> disagree with the misuse of the word inset in the current thread.
As I stated above "insets ain't insets." InsetFont was mentioned early
last week (or the week before) as a holder of font info that would affect
everything that came between it and the next InsetFont. This could
therefore apply across multiple paragraphs or across individual letters.
Each InsetFont would therefore contain only the changes from the current
running font.
Without an InsetFont we end up with the same sort of font table stuff we
have now except if we don't change a font we still have a table and its
extra baggage. Putting each element into its own self-contained Inset
will lead to easier maintenance and more clearly defined interfaces.
Of course, it's arguable that we might be breaking things up to far then
but our existing code has to have a very smart Paragraph instead of
several smaller not-so-smart fragments.
> > [...] This idea came from
> > the observation that the current Paragraph implementation has a huge
> > amount of info in its structure. Most of which is often shared with its
> > neighbouring paragraphs. The additional benefit of the InsetLayout
> > approach is that it would make stuff like Larry's (or was it Richard's?)
> > need for clusters of paragraphs a bit easier to force from within LyX
> > (without support from the layout styles).
>
> I agree with that. Some properties in the basic container (paragraph)
> should be moved to the glyph (inset) as discussed at the begining of this
> post.
Awaiting further comment,
Allan. (ARRae)
