rgheck <[EMAIL PROTECTED]> writes:
> We have that in quite a lot of places. At present, that's just how
> insets identify themselves.
Some of the places where these codes are used are mandatory (like the
factory).
> Of course, you can have some virtual method in Inset that does
> nothing, and then just call it for everything. But the kind of case
> that Pavel is worried about is, as you said, different.
I took a look at uses of _CODE and one of the first non-trivial uses I
found is:
int InsetPrintNomencl::docbook(odocstream & os, OutputParams const &) const
{
os << "<glossary>\n";
int newlines = 2;
for (InsetIterator it = inset_iterator_begin(buffer().inset()); it;) {
if (it->lyxCode() == NOMENCL_CODE) {
newlines += static_cast<InsetNomencl const &>(*it).docbo
okGlossary(os);
++it;
} else if(it->lyxCode() == NOTE_CODE &&
static_cast<InsetNote const &>(*it).params().type == I
nsetNoteParams::Note) {
// Don't output anything nested in note insets
size_t const depth = it.depth();
++it;
while (it.depth() > depth)
++it;
} else {
++it;
}
}
os << "</glossary>\n";
return newlines;
}
While it can be argued that testing NOMENCL_CODE makes sense, the test
for NOTE_CODE is plain stupid. There are other cases where code is not
output, like an inactive branch. And rather than adding a test for
BRANCH_CODE, it just looks like having a bool Inset::producesInput()
virtual method would help a lot.
JMarc
