> >Could you describe what an iterator is and
> >is "editing interface" self evident?
>
> I suggest you to see our online references in www.devel.lyx.org.
Yes, and in addition to that, have a look at the C++ STL library.
This is the library that in practice introduced the notion of
itera
On Wed, 24 Mar 1999, Bruce M Beach wrote:
>Could you describe what an iterator is and
>is "editing interface" self evident?
I suggest you to see our online references in www.devel.lyx.org.
Alejandro
On Wed, 24 Mar 1999, Asger Alstrup Nielsen wrote:
> ...based on iterators. I plan to redo that design with a strong STL
> compliant iterator interface, and I feel that would serve as the
> best fundation of the editing interface.
> Asger
>
Could you describe what an iterator is and
is "
> AAN> If we wanted to ensure maximum reuse, we would have a list of
> AAN> all instantiated ParaParams, and whenever one is change, search
> AAN> this list to find a match.
>
> AAN> However, that would probably not reduce total memory use,
> AAN> because of the memory requirements of t
>> Jean-Marc Lasgouttes writes:
JL> Could you give me an example where \par is needed? It seems to
JL> me that it is exactly equivalent to \n\n. Using one or another
JL> is just a matter of taste IMO (and it seems our taste differs
JL> regarding this :)
In the body of the docuemtn \n\n
>> Asger Alstrup Nielsen writes:
AAN> If we wanted to ensure maximum reuse, we would have a list of
AAN> all instantiated ParaParams, and whenever one is change, search
AAN> this list to find a match.
AAN> However, that would probably not reduce total memory use,
AAN> because of the m
On Wed, 24 Mar 1999, Asger Alstrup Nielsen wrote:
[...lots more clarifications...]
> > 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
> > w
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>>> Jean-Marc Lasgouttes writes:
JL> The code in breakLine ensures that we will *never* have extra
JL> paragraph breaks. And this code is needed whether or not you use
JL> \par for paragraph break. In fact, I cannot think of an examp
On Wed, 24 Mar 1999, Asger Alstrup Nielsen wrote:
[lots of useful clarifications and corrections...]
Thanks, its starting to make better sense now. I thought I was confused
somewhere along the line.
Allan. (ARRae)
> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:
>> Hanging indents do live in a rectangle, not in a strangely shaped
>> region.
Allan> Yes, but that rectangle has a chunk out of the top corner which
Allan> gives you the smaller top rectangle.
As far as I know, a paragraph with hanging i
> 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.
Yes, that's right.
> Asger's InsetParbox is more
> 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
> The editing mechanism is so complex that it's recomended that all text
> insets share it, so InsetParbox might be derived from InsetText anyway.
I think we should expose the editing mechanism right in the Inset * base class.
All Insets should have an iterator interface, and this interface expo
> I'm in agreeance with JMarc on this point. A footnote should look like a
> footnote. Just like it does now. We can of course still improve on
> the current situation but I don't think this does.
Ok, I give in. (Although I still think that for footnotes that can be
contained in one paragraph
On Tue, 23 Mar 1999, Alejandro Aguilar Sierra wrote:
> On Tue, 23 Mar 1999, Asger Alstrup Nielsen wrote:
[...words, words and more words...]>
> 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.
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
On Tue, 23 Mar 1999, Alejandro Aguilar Sierra wrote:
> 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. Even a single
On 24 Mar 1999, Lars Gullik Bjønnes wrote:
> Eh? You seem to put more into my mail than I intended.
> regardless of inset model InsetText->InsetCollapsable->InsetFoot seem
> not to have the correct naming.
Which naming would be the correct? Your reply confirm the bad intention I
suspected form y
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.
> class
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
structur
On Tue, 23 Mar 1999, Alejandro Aguilar Sierra wrote:
> On Wed, 24 Mar 1999, Allan Rae wrote:
>
> > Here's another question for you:
> > Will minipages be a variant of an InsetParbox? or just a bool in the
> > InsetParbox structure? or have I forgotten something?
>
> it would be a variant, in y
>> Alejandro Aguilar Sierra writes:
AAS> On 24 Mar 1999, Lars Gullik Bjønnes wrote:
>> That InsetText holds a lot more than text and should IMO be
>> renamed. It is actually a lot closer to how I imagine the
>> InsetParagraph should be.
AAS> That's why we are discussing about a new t
On 24 Mar 1999, Lars Gullik Bjønnes wrote:
> That InsetText holds a lot more than text and should IMO be renamed.
> It is actually a lot closer to how I imagine the InsetParagraph should
> be.
That's why we are discussing about a new text inset model. We are on the
way but still far from it. I'm
>> Alejandro Aguilar Sierra writes:
AAS> On Wed, 24 Mar 1999, Allan Rae wrote:
>> Here's another question for you: Will minipages be a variant of
>> an InsetParbox? or just a bool in the InsetParbox structure? or
>> have I forgotten something?
AAS> it would be a variant, in your lang
On Wed, 24 Mar 1999, Allan Rae wrote:
> Here's another question for you:
> Will minipages be a variant of an InsetParbox? or just a bool in the
> InsetParbox structure? or have I forgotten something?
it would be a variant, in your language. A derived class from InsetText in
mine, as Jurgen and
On Tue, 23 Mar 1999, Jean-Marc Lasgouttes wrote:
> > "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes:
[...]
> Asger> -- This is a demonstration[foot|and what a demonstration it is.
> Asger> Hopefully, it will demonstrate that a Parbox need not be
> Asger> rectangular.] of the ne
On Mon, 22 Mar 1999, Alejandro Aguilar Sierra wrote:
>A paragraph should be as fluid as water inside either the workarea, a table
> cell or a math text inset.
Yes but isn't this how a paragraph would work as an inset anyway?
If a paragraph is a collection of objects (i.e) words,letters
EP
>> Jean-Marc Lasgouttes writes:
JL> The code in breakLine ensures that we will *never* have extra
JL> paragraph breaks. And this code is needed whether or not you use
JL> \par for paragraph break. In fact, I cannot think of an example
JL> where \par makes a difference.
Inside command de
> "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes:
Asger> I have an evil plan to use these InsetParboxes to allow more
Asger> sophisticated geometry: For instance, footnotes will either
Asger> derive from InsetParbox, or contain one, and then draw itself
Asger> intelligently ins
> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:
Allan> * Relying upon '\n's to denote a paragraph is awkward and
Allan> error prone as demonstrated by our existing code. The
Allan> alternative: * {A LaTeX paragraph.\par} * A typical
Allan> [SG|X|HT]ML paragraph.
In the LaTeX case, the so
> Asger> We have an inset that can contain a list of paragraphs. This
>
> Why not us the LaTeX terminology and call it a InsetParbox? A \parbox
> is exactly what you describe, if I understood correctly. For example,
> does your InsetFlow live in a rectangle?
In broad terms, yes it does live in
> "Asger" == Asger Alstrup Nielsen <[EMAIL PROTECTED]> writes:
Asger> Here's my idea of the inset design at the moment. I hope this
Asger> will settle the discussion between Alejandro and Allan, which
Asger> mostly is a discussion about words.
I mostly agree with what Asger writes. A few re
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.
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
On Tue, 23 Mar 1999, Allan Rae wrote:
> > 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
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
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
On Mon, 22 Mar 1999, Alejandro Aguilar Sierra wrote:
[...]
> > > At the moment, the big discussion is turning around whether paragraphs should
> > > be insets or not. We have not really decided yet.
>
> As an authority on both LyX and Mathed insets, my opinion is NO. A
> paragraph should be as
On Mon, 22 Mar 1999, Bruce M Beach wrote:
> This seems like a very good idea. Does It make sense that
> a inset could be encapsulated within another inset?
Currently (1.0) normal LyX insets can't, but math insets can. A fraction
inside a sqrt is an example of an inset inside another inset.
On Mon, 22 Mar 1999, Asger Alstrup Nielsen wrote:
> > I wonder if somebody could define what an inset is
> > and give me typical examples of inset.
>
> In LyX, an inset is mostly a developers term. This term covers a bunch of the
> user interface elements that the users see. Some of the insets
Of course, I forgot the exact definition of an inset in LyX:
An inset is any class derived from the Inset base class.
Greets,
Asger
> I wonder if somebody could define what an inset is
> and give me typical examples of inset.
In LyX, an inset is mostly a developers term. This term covers a bunch of the
user interface elements that the users see. Some of the insets are very
visible, and easily spotted as insets. In particul
41 matches
Mail list logo
