| Summary: | Classes in sub-packages are moved to top level packages on edit | ||
|---|---|---|---|
| Product: | [Applications] umbrello | Reporter: | Ferenc Veres <lion> |
| Component: | general | Assignee: | Umbrello Development Group <umbrello-devel> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | 2.bugs.kde.org, ehjuerrens, txwikinger |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 4.8.1 | |
| Sentry Crash Report: | |||
| Attachments: |
autom. created crash file (created by Kcrash)
Solution for package name hierarchy |
||
With some more trace I found that the routines handle package name with "::" separator in UMLDoc::findUMLObject. Thus, if I edit the Package in the properties dialog box from SubPackage (as it is opened) to: TopPackage::SubPackage it leaves the class in the right package. Should that dropdown list be filled with full path of package names then? Sounds reasonable. Created attachment 30985 [details]
autom. created crash file (created by Kcrash)
I have the same problem using umbrello 2.1.3 via kde 4.1.3 using gnome. My problem is, that if the name is corrected manually and the properties dialog of the modified class is closed, the application crashes. See attached kcrash file. (In reply to comment #1) > With some more trace I found that the routines handle package name with "::" > separator in UMLDoc::findUMLObject. Thus, if I edit the Package in the > properties dialog box from > > SubPackage > > (as it is opened) to: > > TopPackage::SubPackage > > it leaves the class in the right package. > > Should that dropdown list be filled with full path of package names then? > Sounds reasonable. I agree that the property of the dialog box should contain the full namespace (i.e. TopPackage[::SubPackage]* Also, the same problem occurs in the following scenario, when a class is inside a package that is inside a folder. When saving the properties, the class is moved into a new package with the same name at the root of the diagram. This problem is still present in: * Umbrello 2.1.3 / KDE 4.1.3 * Umbrello 2.1.3 compiled from kdesdk-4.2.2 as per http://uml.sourceforge.net/install.php; base KDE system still 4.1.3 * Umbrello 2.1.3 compiled from kdesdk-4.3.0 etc as above * Umbrello 2.1.3 compiled from kdesdk-svn-1010219.tar.bz2 (Umbrello has certainly changed over all those KDE versions - is there any particular reason it is still called 2.1.3???) I can also confirm that the crash described by EHJ can still occur in Umbrello from kdedsk-4.3.0 / kde 4.1.3 (environemnt as described in my comment #5). Simplest way to reproduce 1- New model 2- Add package a and b and class Class1 such that Class1 is inside b, and b inside a (a::b::Class1) 3- Open properties of Class1 and 'apply' ---> Class1 is now b::Class1 (the top-level 'b' package is created automagically; a::b continues to exist). 4- Open properties of Class1 and manually set package name to a::b, apply. --> Class1 is now a::b::Class1 again 5- Open properties of Class1 and 'apply' --> Class1 is b::Class1 again. 6- Open properties of Class1 and manually set package name to a::b, apply. --> Crash, SIGSEGV. I guess dubious connection data appears at some point - possibly as early as (3) - the reference from Class1 to the 'b' that is inside 'a' is retained, and by the time (6) comes around this has escalated to a crashworthy problem. If running in a console, Umbrello already prints 'umbrello(18336): "class1" : Object is already in target package' at (3). Probably this should be bumped up to a 'crash' bug? Created attachment 47642 [details]
Solution for package name hierarchy
I have attached a simple solution, where instead of the package name the whole path will be used in the text field. I.e., when you touch the Apply of OK button the hierarchy is not more destroyed.
SVN commit 1279523 by okellogg: Apply attachment 47642 [details] by Egbert Voigt : > I have attached a simple solution, where instead of the package name > the whole path will be used in the text field. I.e., when you touch the > Apply of OK button the hierarchy is not more destroyed. M +1 -0 ChangeLog M +3 -2 umbrello/dialogs/classgenpage.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1279523 set version-fixed-in from 4.8.1 changelog |
Version: 2.1.2 (using Devel) Compiler: gcc OS: Linux Installed from: Compiled sources To reproduce: 1. New document, new class diagram 2. On model view: New package: "TopPackage" 3. On model view, TopPackage, New Package: "SubPackage" 4. On SubPackage, New class: "TestClass" (now you have the following hierarchy: TopPackage / SubPackage / TestClass") 5. Open properties dialog of "TestClass" 6. Press "OK" Current result: TestClasss is moved to root, creating a new package for it called "SubPackage". Structure becomes: / TopPackage / SubPackage (empty) / SubPackage / TestClas Expected result: TestClass stays where I wrote "empty", in original location. Debug info: I followed the code to dialogs/classgenpage.cpp:422: if ( !packageName.isEmpty()) { if ( ( newPackage = m_pUmldoc->findUMLObject(packageName, Uml::ot_Package) ) == NULL ) { newPackage = Import_Utils::createUMLObject(Uml::ot_Package, packageName); } } else { newPackage = m_pUmldoc->getRootFolder( Uml::mt_Logical ); } For me this always go to the newPackage = Import_Utils::createUMLObject() branch because UMLDoc::findUMLObject calls UMLPackage.findObject(const QString &name) and that loops on things like "bool", "double" and other basic types instead my package names. I did not even see "TopPackage" there on the loop. Additionally, since "QString name" is passed "SubPackage", I am not sure how it will correctly identify it, since there is no path for the package. Are tree hierarchical packages supported at all?