Kepler

The reason you cannot create a kar file from an instantiated composite is that the changes to the moml are not saved in the current workflow which makes it impossible to get a handle on the composite's class file (.xml file). Another issue is that if you drag a composite instance to the canvas, then change it, ptii will want you to overwrite the composite's class file. This even happens for TypedCompositeActor.xml. If a user were to do that, all of the composites would change. Unless this behavior is changed, I do not think we can allow users to drag Composite instances.

Unfortunately, that fact also causes the problem in number 2. I'm not sure why you can't create a class from a composite that has linked ports. That seems silly.

All of these problems stem from the fact that ptii handles composites much differently than it handles atomics. Unless we can somehow manage to merge the two concepts, I don't think 1 and 2 can be resolved.

I will work on re-creating #3. This may take some debugging though, since I'm not sure what the exact steps were to cause this error.

Currently one can create a kar from a composite if the composite was originally created by dragging from the actor tree. However, there is still a problem with selecting a set of actors and then using a menu command to create a composite containing those actors. That menu option has been removed, although it is very useful and we would like to fix it.

Because we can just remove the menu item, changing from 'blocker' to 'critical'

Creating a kar file from a composite now works as long as the composite was built from an empty Composite actor and not from the menu where selected actors are automatically put into the composite. [In fact, the menu item for this has been removed.]

I am thus marking this bug as fixed and another bug has been added to get the menu item for building a composite working.
(Dan Higgins)

Original Bugzilla ID was 2412