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, 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 an InsetText, an InsetMath or an
InsetGraphics for example.
By implementing this virtual method I reckon that we will save some
code. For example:
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<InsetTabular&>(inset());
return tabular.cell(idx()).get();
}
return &inset();
}
Would become:
Inset * DocIterator::realInset() const
{
return *inset().cell(idx());
}
This is good in fact. What I don't like is to blur the difference between
insets and cells.
OK but see below.
And this would work in texted, tabular and mathed indiferently. But then
the need for this method would be void I think.
Inset::getText() should go as well as one could cast the cell if needed.
Note that we have already something similar with
DocIterator::Text() (there's 1 to 1 correspondence Text <-> InsetText)
Yes, I know that.
I see that InsetMath already contains a cell() method which returns a
MathData. We should merge that with Inset::cell(); either by making
MathData a proper Inset or by returning the englobing InsetMathNest (I
am not sure there is one).
Again, maybe having a Cell class base for both MathData and InsetText is the
way to go.
I am perfectly fine with the idea of multiple inheritance but what would
you put in this base class? AFAIS, this would just be a container for an
Inset similar to what we have with MathAthom. I just don't see the benefit.
But this is just brushing the problem, IMHO. The real problem is
to find what code/data can be really shared.
Inset has a number of methods that are cell related. Some of them are
only for InsetTabular (getText) others are only for InsetMathNest/Grid.
The idea would be to merge those.
My knowledge about the mathed hierarchy is feeble so I can't help you
here...
AFAIU, creating this virtual method would help the long standing merging
of Inset and InsetMath. InsetMathGrid and InsetTabular could for example
share some code. A lot of methods in DocIterator could be merged also:
- cell() (of course)
- col() and row()
- prev and nextAtom()
- etc
For instance, one thing that we miss badly is unified Change Tracking (that
is to have CT for mathed).
Agreed. I think that by doing this Inset "unification" we could ease the
way toward that goal.
Abdel.
