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.
reproducible with 061113_2 may the issue was filed, but I can't find it now. edit control(in drop down), apply design pattern wizard(in participant selection drop-downs) use TopLevelPackage::...::MiddleLevelPackage::..::DeepestPackage::ClassName classifier specification Representing Classifier property for Actors/Lifelines on sequence diagram use inconsistent and hard to use specification: ClassName : TopLevelPackage::OtherPackages it takes a lot of time for me to figure out expected way and enter java.lang.String which wasn't in project before.
This is by design because in UML the namespace seperator is "::" not "." like Java. I plan to make this an enhancemnet unless I hear a good reason.
the issue is not about '::' instead of '.' but about strange namespace order in property and usage of ':'. When I first tried to use the property I tried to put 'pacakge::className' here and failed, it takes quite a long time to figure out expected order, and moreover number of spaces are important in the property (between separators).
ok I see your point. The reason why we formated data in the property the way we did was for usability. We want to be able to sort the items by the name of class, not the package. Also, we want the user to be able to see the name of the class, then find the one in the correct package. When we showed the entire package name it was hard to find the correct class in the drop down list. Now having said all of that, it does not mean that we should expect the import in the same form as is displayed in the editor. It would make more sense to allow the user to enter the fully qualified name with out requiring the <Class Name> : < Package Name > syntax. I only stated the above because I do not want anyone to just say "Lets change how the informaiton is formated in the combobox".
low use case not currently impacting our installed user base.
Planned for drawing area upgrade after NB 6.0.
Should not use resolved/later status.
Targeted in the drawing area redesign.
REstoring the original priority and using the NB 6.0 waiver process.
Diagram area bugs waived for 6.0 will also be waived for 6.1.
not drawing are issue
but also seems to be not a P2
*** Issue 80478 has been marked as a duplicate of this issue. ***