23/12/2013 12:26, Scott Kostyshak:
Sounds better indeed.
Also, in an hypothetical xml format, it would make sense to have
<inset name="Note" type="sticky" ...>
and to be able to handle this in a genric way.
So this would be a new class/typedef?
Inset would get a new data member?
I'd assume that we want to implement that as a couple of virtual
function at Inset level but that, at some place in the inset hierarchy,
we may want to have a member function that contain the type. I do not
know, actually. Also, this will require a patient work of renaming
because several insets use different names for the same concepts.
Adding new data members to Inset is a bad idea in general, since this
class is used all over the place in mathed. This would therefore use
lots of memory.
In addition to type and subtype, we could allow for a "instance label"
to accommodate insets whose layoutName depends on something else
(InsetFlex and InsetBranch)?
Could you give me an example?
Do you propose to have layoutName still return a docstring, but in a
generic way (i.e. it would not be virtual)? Or do you propose to have
it return the new data member and how it is used is up to the caller?
We could probable have
virtual doctring name()
virtual docstring type()
virtual docstring layoutName()
There would be a generic implementation of layoutName that could be
overridden.
And then inset-forall could work on all insets in a certain type
(without regard to sub-type)?
Doesn't it already?
As you can see by the number of question marks, I'm interested but not
sure about the details.
I am not either...
JMarc
