On Thu, Aug 28, 2003 at 08:57:17AM +0200, Asger Kunuk Alstrup wrote:
> And Andre has prior art in Mathed which works just as well. (Andre is
> making a mistake to call it a cell, because normally a cell is an atomic
> thing. However, a ParBox is a composed thing, so that name is confusing
> things.
So, the discussion is whether there is a need for ParBox or not.
Lars said:
> Some data<->view stuff seems to be mixed here.
This is the key to the answer:
If you have ParBox, the view part will be simpler.
ParBox corresponds to a list of Paragraphs. This is a sane concept,
and is reflected in
On Wed, Aug 27, 2003 at 06:03:06PM +0200, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> > Ok.. so we have two layers for a Table.
> >
> > Now, what about a 'collapsable inset'.
> >
> > Should this be able to contain a simple MathFracInset or should this be
> > wrapped in some kind of cont
On Wed, Aug 27, 2003 at 06:03:06PM +0200, Alfredo Braunstein wrote:
> I wonder if the whole discussion is not about
Quite possibly.
> > Should this be able to contain a simple MathFracInset or should this be
> > wrapped in some kind of container. Like a InsetText^H^H^H Cell?
It would have exact
Andre Poenitz wrote:
> Ok.. so we have two layers for a Table.
>
> Now, what about a 'collapsable inset'.
>
> Should this be able to contain a simple MathFracInset or should this be
> wrapped in some kind of container. Like a InsetText^H^H^H Cell?
I wonder if the whole discussion is not about
On Wed, Aug 27, 2003 at 04:32:42PM +0100, John Levon wrote:
> On Wed, Aug 27, 2003 at 04:57:03PM +0200, Andre Poenitz wrote:
>
> > > Put it this way: if we have a containing something called X, I don't see
> > > a reason for anything else. Xes can be contained by, and contain Xes.
> >
> > A table
On Wed, Aug 27, 2003 at 04:57:03PM +0200, Andre Poenitz wrote:
> > Put it this way: if we have a containing something called X, I don't see
> > a reason for anything else. Xes can be contained by, and contain Xes.
>
> A table only contains 'CellInsets'. No 'MathAlphaInset', no
> 'InsetBibtex'.
C
On Wed, Aug 27, 2003 at 03:38:48PM +0100, John Levon wrote:
> > Would it make you happy if I used the term 'CellInset' instead of 'Cell'?
>
> Reading the rest of the thread it looks like mostly terminology
> problems...
I don't think so. Implementation-wise it might be such, but the
conceptual st
Asger Kunuk Alstrup <[EMAIL PROTECTED]> writes:
| On Wed, 27 Aug 2003, Andre Poenitz wrote:
>
>> What would be your basic chunk of data?
>>
>> "List of Insets"?
>>
>> What's wrong with giving this concept a name ("Cell")?
>
| I'm not sure if it helps, but a long time ago, we discussed how to do
|
On Wed, Aug 27, 2003 at 04:29:17PM +0200, Andre Poenitz wrote:
> Would it make you happy if I used the term 'CellInset' instead of 'Cell'?
Reading the rest of the thread it looks like mostly terminology
problems...
Put it this way: if we have a containing something called X, I don't see
a reason
On Wed, Aug 27, 2003 at 03:14:35PM +0100, John Levon wrote:
> On Wed, Aug 27, 2003 at 02:11:16PM +0200, Andre Poenitz wrote:
>
> > > Why insets cannot own insets?
> >
> > There is no need to.
>
> There is every need to. It is the only sane way to do things like
> removing all the manual/auto lab
On Wed, Aug 27, 2003 at 02:45:11PM +0200, Andre Poenitz wrote:
> What is your basic chunk of data that's used for cut&paste etc?
> A single Inset? Only copying whole paragraphs?
Of course not. Start and end position are marked by Inset+Data
iterators. To actually perform a cut, a Text Iterato
On Wed, Aug 27, 2003 at 02:11:16PM +0200, Andre Poenitz wrote:
> > Why insets cannot own insets?
>
> There is no need to.
There is every need to. It is the only sane way to do things like
removing all the manual/auto label stuff.
> [And I'd even argue that math tables are much easier to handle
On Wed, Aug 27, 2003 at 03:01:08PM +0200, Asger Kunuk Alstrup wrote:
> On Wed, 27 Aug 2003, Andre Poenitz wrote:
>
> > What would be your basic chunk of data?
> >
> > "List of Insets"?
> >
> > What's wrong with giving this concept a name ("Cell")?
>
> I'm not sure if it helps, but a long time ago
On Wednesday 27 August 2003 14:45, you wrote:
> *shrug*
>
> What would be your basic chunk of data?
>
> "List of Insets"?
>
> What's wrong with giving this concept a name ("Cell")?
>
> > >> Why insets cannot own insets?
> > >
> > > There is no need to.
> > >
> > >> Think about tables for instances.
On Wed, 27 Aug 2003, Andre Poenitz wrote:
> What would be your basic chunk of data?
>
> "List of Insets"?
>
> What's wrong with giving this concept a name ("Cell")?
I'm not sure if it helps, but a long time ago, we discussed how to do
this. At that point in time, we agreed that the following stru
On Wed, Aug 27, 2003 at 02:26:45PM +0200, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> > On Wed, Aug 27, 2003 at 01:54:55PM +0200, Alfredo Braunstein wrote:
> >> Andre Poenitz wrote:
> >>
> >> > Hm, I think ParIterator + InsetList::iterator should suffice.
> >> >
> >> > The problem with
Andre Poenitz wrote:
> On Wed, Aug 27, 2003 at 01:54:55PM +0200, Alfredo Braunstein wrote:
>> Andre Poenitz wrote:
>>
>> > Hm, I think ParIterator + InsetList::iterator should suffice.
>> >
>> > The problem with the InsetText hidden in InsetCollapsable is that this
>> > is not an inset, but some
On Wed, Aug 27, 2003 at 02:11:16PM +0200, Andre' Poenitz wrote:
> The mathed model is
>
> Inset has cells.("MathArray")
> A cell has insets.
>
> Nothing else. To expand that to the outside world this would be:
>
> Inset has cells.(ParagraphList)
> A cell has d
On Wed, Aug 27, 2003 at 01:54:55PM +0200, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> > Hm, I think ParIterator + InsetList::iterator should suffice.
> >
> > The problem with the InsetText hidden in InsetCollapsable is that this
> > is not an inset, but some implementation detail which s
On Wednesday 27 August 2003 12:54, Alfredo Braunstein wrote:
>
> IMO we should standarise the access of insets owned by insets, that's all.
IMHO the paragraph should be insets, and then have a unified scheme to
transverse the document. The restrictions for insets to be first order
citizens are
Andre Poenitz wrote:
> Hm, I think ParIterator + InsetList::iterator should suffice.
>
> The problem with the InsetText hidden in InsetCollapsable is that this
> is not an inset, but some implementation detail which should be
> completely invisible.
I do not agree. What is it that forces con
On Wed, Aug 27, 2003 at 01:32:11PM +0200, Andre' Poenitz wrote:
> On Wed, Aug 27, 2003 at 01:16:53PM +0200, Alfredo Braunstein wrote:
> > I repose the problem for clarification.
> >
> > paragraph_funcs::outerPar is buggy, because it cannot traverse all insets in
> > the document. The problem is th
On Wed, Aug 27, 2003 at 01:16:53PM +0200, Alfredo Braunstein wrote:
> I repose the problem for clarification.
>
> paragraph_funcs::outerPar is buggy, because it cannot traverse all insets in
> the document. The problem is that some insets (like collapsables) are
> direct members of other insets, a
24 matches
Mail list logo
