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
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, and not inside some paragraph InsetList.
So for instance (random example), how
25 matches
Mail list logo
