Looking a bit closer at it I start to dislike it. It's exactly the
same kind of "horizontal" structure like the controllers that forces
us to consider things equally that aren't equal by nature.
There's are 400 lines of "general" read/write infrastructure plus three
extra static methods per inset that in the end achieve something pretty
similar to
void InsetMathSqrt::write(WriteStream & os) const
{
os << "\\sqrt{" << cell(0) << '}';
}
void Parser::parse1(InsetMathGrid & grid, unsigned flags,
const mode_type mode, const bool numbered)
{
[...]
else if (t.cs() == "sqrt") { [...]
cell->push_back(MathAtom(new InsetMathSqrt));
parse(cell->back().nucleus()->cell(0),
FLAG_ITEM, mode);
}
[...]
}
i.e. in each class derived from InsetCommand there is already more code
needed just to _interface_ the "nice general" code in InsetCommandParams
than an inset specific read/write implemention would take. This is
cancer that should not be allowed to grow any further.
What is, btw, LATEX_KV_REQUIRED and LATEX_KV_OPTIONAL good for?
LyX compiles fine without those?
Andre'
