23/12/2013 13:03, Scott Kostyshak:
On Mon, Dec 23, 2013 at 6:39 AM, Jean-Marc Lasgouttes
<lasgout...@lyx.org> wrote:
23/12/2013 12:26, Scott Kostyshak:
Also, this will require a patient work of renaming because several insets use
different names for the same concepts.
Example? So for these they should have the same type but different name?
Sorry I have not been very clear in my use of "type" and "name". The
"name" would be the inset name after \begin_inset, for example Branch,
and the type could be "foo" for branch "foo". Actually this naming
scheme is proably not the best possible choice (intuitively you swapped
the meanings, which means that it was not clear).
In my sentence above, "names" should be taken as just a word, not a
referrence to this "name" entity. Actually, after checking, I think that
my comment is misleading. There several type or type_ members, but some
of them are std::string, and others are enums.
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?
Perhaps I'm mixing ideas, but I'm referring to:
src/insets/InsetBranch.h: docstring layoutName() const {
return from_ascii("Branch:") + branch(); }
This would be name="Branch", type=branch()
src/insets/InsetFlex.h: docstring layoutName() const { return
from_utf8("Flex:" + name_); }
name="Flex", type=name_ (feels strange, isn't it?)
but according to your implementation below these could just be added
on in layoutName (when I mentioned this I was thinking of a data
member and having layoutName generic).
The layoutname is the concacenation of these things. It could even be
longer than 2 things. The code to find inset layouts for tries the full
name, and then removes the elements from right to left until a
definition is found. Therefore, if Branch:foo is not a known style, then
Branch will be used instead. It is like a proor-man CSS.
JMarc
