Conversation
change group to coregroup in layoutspec add a new class for arrows in category
| arrowIcon = require("../resources/ui/indent-arrow-down-wo-lines.svg"); | ||
| } | ||
|
|
||
| return <img className={"CategoryArrow"} src={arrowIcon} onError={this.onImageLoadFail} />; |
There was a problem hiding this comment.
for arrow alignment on category
| this.setState({ expanded: !currentlyExpanded }); | ||
|
|
||
| //auto expand the coregroup elements | ||
| if(this.props.data.itemType === "category" ) { |
There was a problem hiding this comment.
does this work for nested categories?
There was a problem hiding this comment.
No. this is only for the top level categories.
There was a problem hiding this comment.
@mjkkirschner Only needed for top level categories.
| "text": "Color", | ||
| "iconUrl": "", | ||
| "elementType": "group", | ||
| "elementType": "class", |
There was a problem hiding this comment.
so when does class get used? When should it be used opposed to group? Can you add these types to the documentation files? / wiki?
Do we ever generate classes or coreGroups when importing some other library which is not defined in the layout spec?
There was a problem hiding this comment.
@ramramps also, so you will need to update the layoutspec in revit and dynamo as a consequence of this PR as well to get the same behavior right?
There was a problem hiding this comment.
First, I understand this work is being done to accomplish the particular design requirements.
I think it would be useful for someone to enumerate the rules that are now encoded in this repo.
I could be wrong, but they seem pretty complicated to me.
I will take a shot:
- Top Level categories display Icons
- groups or classes do not display icons
- Nested categories do not expand when their parent categories are clicked on.
- Top Level categories expand their child groups when clicked on.
- other stuff?
I do not think we will be able to maintain this matrix of interactions without properly documenting it and the new classes/ groups, etc...
This is not a criticism of the implementation here. I am fine with this approach, but would be happier if we did not need to introduce new types to accomplish this, just apply the minimal logic required to existing types throughout the library with no special logic for items in the layout spec - remember we'll need another giant layout spec for TS.
at a minimum let us please document these rules thoroughly.
There was a problem hiding this comment.
@mjkkirschner Thanks for the comments.
- Dynamo and Revit layoutspec needs a change.
- This is definitely to get that particular design. This was easy in WPF. But in librarie.js, everything is dependent on
elementType. I don't have a choice other than adding a new one. - Auto expand - as per the task, it is only for top level. Per my understanding from layoutspec, this is the order after the change
section-category-coregroup-group-none. All the nested category getsgroupby default. - Before the change, the order is
section-category-group-none. So, there is no clear distinction between the top level and nested categories. Well, we can leave it this way too. Without introducing this new type, everything isgroupand no way to get this design based on other data. The other approach is to use a config file and white list the top level element. - I am afraid that if layoutspec is auto generated, then achieving this design will get complicated and requires careful look of how it is made today.
6.I will add a wiki page with rules per my understanding.
Also, I will rename coregroup to groups. So, the top level has groups of group.
There was a problem hiding this comment.
@ramramps thanks for the detailed response - have you added the wiki page yet (6) on your list?
There was a problem hiding this comment.
not yet. the rules are simplified now. no big change required in layoutspec. I will start the wiki , and let @Racel add the rules. She knows better than me.
|
@ramramps looks good implementation wise - some questions about other approaches not requiring new types, but LGTM if you have thought about that already. |
|
@mjkkirschner @Racel After giving it another shot, there is another way to achieve it. @Racel Let me know where and when to update |
| child.childElements.forEach((grp: LayoutElement) => { | ||
| if(grp.elementType != "class") { | ||
| grp.elementType = "coregroup"; | ||
| } |
There was a problem hiding this comment.
I could have used underscore, but I find this way more explicit for someone to understand what we are doing (underscore does this implicit).
There was a problem hiding this comment.
cool - looks good, can you add just a bit more description to the summary of the behavior - something like: changes categories topLevel children itemType from groups to coreGroups.... or something like that.
| }, 500); | ||
| }); | ||
|
|
||
| it("coregroup items should auto expand", function () { |
There was a problem hiding this comment.
this test covers the major part.
| onError={[Function]} | ||
| src="test-file-stub" | ||
| /> | ||
| <img |
There was a problem hiding this comment.
so I think you might need to update the tests file after you merge with master as I think this will undo what Keith added.
There was a problem hiding this comment.
ah..I think I discarded that change. Will check the master file.
|
|
||
| export function search(text: string, item: ItemData) { | ||
| if (item.itemType !== "group") { | ||
| if (item.itemType !== "group" && item.itemType !== "coregroup") { |
There was a problem hiding this comment.
should we also ignore class during search?
There was a problem hiding this comment.
I don't think so. the idea is to change to class and use the search
|
@ramramps thanks for taking another look at this - just a few more comments. Then LGTM. |
|
@Racel https://wiki.autodesk.com/display/GEN/Rule+book |
|
@Racel @mjkkirschner Let me know whether I can merge this code. |
|
LGTM. Lets merge and see how it goes... |
|
@ramramps - Before you merge, can you remove the arrow from the very top level category? I think it is too much... |
|
@ramramps We will just merge this one and create different defect for UI improment. Thanks |
| this.props.data.itemType !== "section" && | ||
| this.props.data.itemType !== "coregroup" && | ||
| this.props.data.itemType !== "class" && | ||
| this.props.data.itemType == "none") { |
There was a problem hiding this comment.
should be this.props.data.itemType !== "none"
| @@ -0,0 +1,38 @@ | |||
| <?xml version="1.0" encoding="iso-8859-1"?> | |||
There was a problem hiding this comment.
This icon does not seem referenced anywhere!
| @@ -0,0 +1,22 @@ | |||
| <?xml version="1.0" encoding="utf-8"?> | |||
There was a problem hiding this comment.
This icon does not seem referenced anywhere!
| this.props.data.itemType !== "section" && | ||
| this.props.data.itemType !== "coregroup" && | ||
| this.props.data.itemType !== "class" && | ||
| this.props.data.itemType == "none") { |
There was a problem hiding this comment.
This should be !== will address in a different PR
| <style type="text/css"> | ||
| .st0{fill:#808080;} | ||
| </style> | ||
| <title>indent-arrow-right</title> |
There was a problem hiding this comment.
You may want to update titles as well
This PR is for LibrarieJS UI Changes.
@mjkkirschner @alfarok @ColinDayOrg
FYI Changes are made after review from @Racel