This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Use the colour distinction in the Design View to distinguish between inherited and locally defined elements and attributes instead of the current distinction between complex types and elements (which is not being understood). For more information, see the usability study report: http://xdesign-tools.czech.sun.com/usability/jse/jse9-coke-endToEnd/report.html#AIColorsInheritedVsLocal
See URLs: Findings: http://xdesign-tools.czech.sun.com/usability/jse/jse9-coke-endToEnd/report.html#AIColorsInheritedVsLocal http://xdesign-tools.czech.sun.com/usability/jse/jse9-coke-endToEnd/report.html#Finding_DroppedToInherited UI Spec: http://xml.netbeans.org/specs/abe/abeVisualAppearance.html
Created attachment 33739 [details] DV showing a complex type and one element which has that type
I have added an image that shows a single element which is an instance of aType complex type. I think the recommendation here is to have the complexType and it's elements be the same color as the "a" element. The inhertied elements from the complexType would be displayed as they are now. There is an additional image which displays read-only, type is coming from another file. These elements and attributes are grey and also have the include badge. However, in this image notice that the subattribute element is displayed normally even though it is inherited. To summarize, here is what I think should be done: 1. Display complexTypes and their children using the same color (basically the coloring schema should be same between complexType and elements if children are inherited ...) 2. inherited attributes should be displayed in the inherited color (blue).
Created attachment 33740 [details] View with inheritance from other files
Partially fixed this bug. There is an NPE that has to be fixed so I am not integrating yet.
As I'm not sure that it follows the suggestions in the specifications, I wanted to play a bit with that. But I cannot see in the recent build. I have (Build 200609120000, Ent. Pack 20060914). Maybe you guys have a better build for me. ... oh now I can see the comment on 'not integrating yet'. When is it to come?
I implemented what Chris mentioned in this bug report that complextypes will same background color as elements. And also made a visual distinction for attrs inherited from complextypes. I have attached the image for PO. Could you please verify what you see with the attached image?
Created attachment 33979 [details] New implemented ABE view
Fixed on 9/14
I've checked, everything looks fine. Great job! Only a couple of comments: * If an attribute ref points to one in a different file, it should be gray, but it's not. * Also I can see that XSD import icon has been added to imported nodes. Perhaps it may get too overwhelming, maybe just one on the root referring node would be enough. I think that gray colour and tooltip provides enough information. * As we needed to pull multiplicity annotations out from the TAB object, let's make them also gray.
I'm reopening this to get the rest fixed (per comments in previous post). Also lowering the priority as the most significant part of this has been fixed already.
Already integrated. Pl check the latest build.
There is still something: * This has not been fixed yet: If an attribute ref points to one in a different file, it should be gray (the background color), but it's not. * I can see you the import icon have been removed. I thought we could leave one icon on the root referring node. Does it make sense?
* I can see you the import icon have been removed. I thought we could leave one icon on the root referring node. Does it make sense? >> This makes UI logic complex and I would not like to do this for this release. May be an REF for later. * This has not been fixed yet: If an attribute ref points to one in a different file, it should be gray (the background color), but it's not. >> I do not agree with the ref being shown as a read-only if it comes from a different file. Even though the referent comes from other file, the reference itself is defined locally to the file. User should be able to change all the properties (except name). The definition section will soon have way to change a reference to point to some other artifact. If we show grayed out that means that user will not be able to change that component there. So, I would suggest to let the references be shown as a shared UI rather graying out and making read-only.
I agree with both points mentioned by girish. The reference itself can be modified locally such as changing the cardinality but what is refers to cannot. The icon change will have to be done next time.
Ok, I agree. Thanks for clearing this out to me. Perhaps, we should do something more in this area (as the type of the referred attribute cannot be changed).
Verified.