On Mon, Dec 23, 2013 at 7:59 AM, Jean-Marc Lasgouttes <[email protected]> wrote: > 23/12/2013 13:03, Scott Kostyshak: > >> On Mon, Dec 23, 2013 at 6:39 AM, Jean-Marc Lasgouttes >> <[email protected]> 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 >
I understand much better now. Thanks for the detailed explanation. I will add this to my TODO list. Scott On Mon, Dec 23, 2013 at 7:59 AM, Jean-Marc Lasgouttes <[email protected]> wrote: > 23/12/2013 13:03, Scott Kostyshak: > >> On Mon, Dec 23, 2013 at 6:39 AM, Jean-Marc Lasgouttes >> <[email protected]> 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 >
