On Wednesday 15 August 2007 16:59:12 Abdelrazak Younes wrote:
> > Of course, once one think about that it soon goes to "what we need is
> > a layout manager!", which sounds like a haunting task. However, it
> > would make sense to rip parts of the tabular or matharray code to
> > obtain this featur
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
I am thinking of table cells that contains only graphics (and
optionally caption (see below). The graphics size would be
automatically adjusted upon the cell size. This would be interesting
for example when you have a tab
On Wed, 15 Aug 2007, Andre Poenitz wrote:
I am happy we found someone that can tell right from wrong.
Ah André found his mail again :)
And I still cannot understand his sense of humor. Was it humor actually?
Of course not.
I am renowned for having absolutely no sense of humour. Germans ar
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> I am thinking of table cells that contains only graphics (and
> optionally caption (see below). The graphics size would be
> automatically adjusted upon the cell size. This would be interesting
> for example when you have a table which header is only
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Yes, I understood what you meant, sorry. My point is that it might be
practical here because tabular uses only InsetText. I am not sure this
is feasible but maybe we can make InsetTabular independent of
InsetText; this wa
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> Yes, I understood what you meant, sorry. My point is that it might be
> practical here because tabular uses only InsetText. I am not sure this
> is feasible but maybe we can make InsetTabular independent of
> InsetText; this way a cell could contain
Alfredo Braunstein wrote:
Abdelrazak Younes wrote:
It is inconsistent only if you think about InsetText as an inset.
Which it is.
Yes, it derives from Inset. What I mean is, it's not an inset in the sense
that they play a different role for DocIterators.
Yes, I understood what you meant,
On Tue, Aug 14, 2007 at 10:00:21PM +0200, Abdelrazak Younes wrote:
> Jean-Marc Lasgouttes wrote:
> >Andre Poenitz <[EMAIL PROTECTED]> writes:
> >
> >>I am happy we found someone that can tell right from wrong.
> >
> >Ah André found his mail again :)
>
> And I still cannot understand his sense of h
Abdelrazak Younes wrote:
>> It is inconsistent only if you think about InsetText as an inset.
>
> Which it is.
Yes, it derives from Inset. What I mean is, it's not an inset in the sense
that they play a different role for DocIterators.
> By implementing this virtual method I reckon that we wil
On Tue, Aug 14, 2007 at 09:46:51PM +0200, Jean-Marc Lasgouttes wrote:
> Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>
> > There should be another CursorSlice inside the cell pointing to the
> > InsetText isn't it?
> >
> > inset -> InsetText
> > pit -> paragraph inside this text
> > pos -> positi
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> Please read again my proposal instead of dismissing it this way. My
> proposal is exactly what you are saying: offer a way to add other
> multi
> celled insets.
It works now. Except of course for the hardcoded TABULAR_CODE testing
that is easy to re
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>> We _do_not_ introduce new uses of Inset::xxx_CODE.
>
> Are you reading? This is the old code! I am actually proposing to
> remove this use of Inset::xxx_CODE.
Sorry. I got it wrong. Implementing cell() is indeed a good idea. This
should also imply,
Jean-Marc Lasgouttes wrote:
Andre Poenitz <[EMAIL PROTECTED]> writes:
I am happy we found someone that can tell right from wrong.
Ah André found his mail again :)
And I still cannot understand his sense of humor. Was it humor actually?
Abdel.
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
There should be another CursorSlice inside the cell pointing to the
InsetText isn't it?
inset -> InsetText
pit -> paragraph inside this text
pos -> position inside the paragraph
What is wrong with the fact that all ins
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Inset * DocIterator::realInset() const
{
BOOST_ASSERT(inTexted());
// if we are in a tabular, we need the cell
if (inset().lyxCode() == Inset::TABULAR_CODE) {
InsetTabular & tabular
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
There should be another CursorSlice inside the cell pointing to the
InsetText isn't it?
inset -> InsetText
pit -> paragraph inside this text
pos -> position inside the paragraph
What is wrong with the fact that all ins
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> Inset * DocIterator::realInset() const
> {
> BOOST_ASSERT(inTexted());
> // if we are in a tabular, we need the cell
> if (inset().lyxCode() == Inset::TABULAR_CODE) {
> InsetTabular & tabular = static_cast(inset());
>
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> There should be another CursorSlice inside the cell pointing to the
> InsetText isn't it?
>
> inset -> InsetText
> pit -> paragraph inside this text
> pos -> position inside the paragraph
What is wrong with the fact that all inset are multicelled, e
Andre Poenitz <[EMAIL PROTECTED]> writes:
> I am happy we found someone that can tell right from wrong.
Ah André found his mail again :)
JMarc
On Tue, Aug 14, 2007 at 04:36:14PM +0200, Abdelrazak Younes wrote:
> >Yes, they have meaning in tabulars (the only multi-text insets we have),
> >
> >inset -> tabular
> >idx -> tabular cell
> >pit -> paragraph inside this cell
> >pos -> position inside the paragraph
>
> OK but I don't think this i
Alfredo Braunstein wrote:
Abdelrazak Younes wrote:
Alfredo Braunstein wrote:
[*] in other words, if you iterate with DocIterator, the inset * member
[of
CUrsorSlice will never point to a tabular owned insettext but to the
tabular inset.
I didn't know that, thanks. But this is bad and inconsi
Abdelrazak Younes wrote:
> Alfredo Braunstein wrote:
>
>> [*] in other words, if you iterate with DocIterator, the inset * member
>> [of
>> CUrsorSlice will never point to a tabular owned insettext but to the
>> tabular inset.
>
> I didn't know that, thanks. But this is bad and inconsistent IMHO
Alfredo Braunstein wrote:
[*] in other words, if you iterate with DocIterator, the inset * member of
CUrsorSlice will never point to a tabular owned insettext but to the
tabular inset.
I didn't know that, thanks. But this is bad and inconsistent IMHO. We
should change that and implement a new
Abdelrazak Younes wrote:
> Alfredo Braunstein wrote:
>> Abdelrazak Younes wrote:
>>
Yes, they have meaning in tabulars (the only multi-text insets we
have),
inset -> tabular
idx -> tabular cell
pit -> paragraph inside this cell
pos -> position inside the paragra
Alfredo Braunstein wrote:
Abdelrazak Younes wrote:
Yes, they have meaning in tabulars (the only multi-text insets we have),
inset -> tabular
idx -> tabular cell
pit -> paragraph inside this cell
pos -> position inside the paragraph
OK but I don't think this is a valid use of pit and pos in th
Abdelrazak Younes wrote:
>> Yes, they have meaning in tabulars (the only multi-text insets we have),
>>
>> inset -> tabular
>> idx -> tabular cell
>> pit -> paragraph inside this cell
>> pos -> position inside the paragraph
>
> OK but I don't think this is a valid use of pit and pos in this case
Alfredo Braunstein wrote:
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Alfredo Braunstein wrote:
Abdelrazak Younes wrote:
Either Alfredo or JMarc I guess...
Pretty sure it's not mine... :-)
It's JMArc then :-)
Here is a fix. What is the purpose of this DocIterator::forwardIdx()?
If
Abdelrazak Younes wrote:
> Abdelrazak Younes wrote:
>> Alfredo Braunstein wrote:
>>> Abdelrazak Younes wrote:
>>>
Either Alfredo or JMarc I guess...
>>>
>>> Pretty sure it's not mine... :-)
>>
>> It's JMArc then :-)
>>
>> Here is a fix. What is the purpose of this DocIterator::forwardIdx()?
Abdelrazak Younes wrote:
Alfredo Braunstein wrote:
Abdelrazak Younes wrote:
Either Alfredo or JMarc I guess...
Pretty sure it's not mine... :-)
It's JMArc then :-)
Here is a fix. What is the purpose of this DocIterator::forwardIdx()?
It was introduced by Georg to fix bug 1973 apparently
Abdelrazak Younes wrote:
Alfredo Braunstein wrote:
Abdelrazak Younes wrote:
Either Alfredo or JMarc I guess...
Pretty sure it's not mine... :-)
It's JMArc then :-)
Here is a fix. What is the purpose of this DocIterator::forwardIdx()?
If we are within a cell, pit_ and pos_ are not importan
Alfredo Braunstein wrote:
Abdelrazak Younes wrote:
Either Alfredo or JMarc I guess...
Pretty sure it's not mine... :-)
It's JMArc then :-)
Here is a fix. What is the purpose of this DocIterator::forwardIdx()?
If we are within a cell, pit_ and pos_ are not important. I think we
should get
Abdelrazak Younes wrote:
> Either Alfredo or JMarc I guess...
Pretty sure it's not mine... :-)
A/
> lyx-qt4.exe!boost::assertion_failed(const char * expr=0x00f64d04,
> const char * function=0x00f64cd0, const char * file=0x00f64cb0, long
> line=378) Line 57C++
> lyx-qt4.exe!lyx::DocIter
32 matches
Mail list logo
