Richard Heck <[EMAIL PROTECTED]> writes:
> But of course I can change all the inset names to uppercase, if you'd
> prefer. Let me know which. One or the other should be done.
I prefer lowercase personally. I think the capitalized version is
intended to look goo in the GUI.
> Note that, since the various insets' write() routines use name(), we
> can get the right string written by just changing how name() is
> defined, thus:
> docstring name() const { string const n =
> Inset::untranslate(lyxCode()); return from_ascii(n); }
I would be a good idea to change name() to return a std::string,
actually.
> where Inset::untranslate() should really be called codeToString(), or
> something of the sort. This then never has to be overridden. It could
> even be static, and probably should.
Yes.
>> Is this what is used by the factory?
> Yes---what it should return is what is used by the factory. So you could do:
> if (insetType == InsetBibitem::name())
> etc
> if name() were static. I was thinking, however, that it would be
> better to do:
> Inset::Code insetCode = Inset::translate(insetType);
> if (insetCode == InsetBibitem::lyxCode())
> etc
Yes. A code allows to use switches, which are handy to find missing
entries.
>> Note that InsetCommand could easily
>> make use of the InsetLayout machinery for the purpose of on-screen
>> display.
>>
> Sure---though I don't understand that stuff at this point.
For example, a table of contents inset could be styled to use a large
bold font to mimick the header of the table of contents in the real
document (I am not advocating doing that in particular...).
JMarc
