Summary: | Implement an Umbrello (UML) plugin | ||
---|---|---|---|
Product: | [Applications] kdevelop | Reporter: | Steven T. Hatton <hattons> |
Component: | general | Assignee: | kdevelop-bugs-null |
Status: | RESOLVED LATER | ||
Severity: | wishlist | CC: | asutton, esigra, janne.karhunen, jr, norbert, opensource |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | openSUSE | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Steven T. Hatton
2003-04-07 11:36:30 UTC
I think umbrello does want you want. You don't need kdevelop for it. The way I see it you should: - Start by designing the functionality in UML - Use Umbrello's code generation feature to get code out of it - Use KDevelop to develop the application. If you did your job properly, there is no need to go back to UML. Some time ago i talked to the umbrello developers, wether they would make it a kpart so it can be easily integrated in kdevelop, but they said that would imply too much changes to their "core" so that this won't happen anytime soon. We have an equivalent beastie asking for us to integrate Umbrello with KDevelop http://bugs.kde.org/show_bug.cgi?id=64241 I'd like it to happen but it would be very difficult to do and Umbrello should remain useable as an independant application. The origional request is to be able to make diagrams with code which is written, and Umbrello can import C++ code quite succesfully (hopefully at some point we will steal KDevelop's other code parsers and can support more languages). Jonathan Riddell wrote: > hopefully at some point we will steal KDevelop's other code parsers and can > support more languages We have two competing proposals on Umbrello's future: 1. Replace Umbrello's document classes by the KDevelop CodeModel This is motivated by what Jonathan writes: If we want to reuse KDevelop's parsers then that ties us to the CodeModel. 2. Replace Umbrello's document classes by Andrew Sutton's OMF2 framework, http://www.sdml.info/projects/omf This is desirable for bringing Umbrello in line with UML 2.0. Option 1 is the way to go if we want to make Umbrello more "code centric" (e.g., roundtrip engineering) while option 2 is clearly the way to go for the model centric improvements. Actually there is also a third option: Put the OMF2 at the heart of Umbrello and make a bridge to the CodeModel, i.e. use the CodeModel only for the code import. (Might be difficult.) Roberto, what are your plans for KDevelop-4? Would you consider putting the OMF2 at its heart? *** This bug has been confirmed by popular vote. *** does it this bug a duplicate of #64241 ? or vice-versa? From bugs.kde.org/64241 Comment #5: > kdevelop already knows about my classes associations. I wish an > umbrello file could automatically be generated and updated from kdevelop. The "generated" part is straightforward but the "updated" is difficult. So if we can agree to leave away the update function then I'm willing to give it a stab. > does it this bug a duplicate of #64241 ? or vice-versa? If we go this way (see above) then I suggest renaming this wish to "Write classview as an Umbrello XMI file" and leaving #64241 for tighter (code level) integration. sounds good. the update would be a plus, but I guess that could be done as a separate step later. anyway, If the programmer does not expect to modify the UML much and only reorganize boxes for viewing.... deleting the xmi and regenerating it again would work fine for a time I'd guess. but eventually. changing a method name for example, should update the xmi, especially changing inheritence stuff. thanks for your willingness. *** Bug 64241 has been marked as a duplicate of this bug. *** *** Bug 79648 has been marked as a duplicate of this bug. *** Whats the status of this wish? Was it decided wether umbrello moves to using Kdevelop's "code-model" (DUChain in KDE4) or stays with its own model? Is there any plan on this for the KDE4 lifetime? |