Bug #5144


renaming an actor does not persist in saved kar files

Added by Matt Jones about 13 years ago. Updated almost 13 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


When one renames an actor on the canvas, and then selects that actor and chooses 'Save KAR...' in the context menu, a new KAR file is saved, but the actor in that KAR file contains the original name of the actor, rather than the new name.

To reproduce:

1) Drag 'Display' (or any other actor) onto the canvas
2) Select the actor, right click, and select 'Customize Name' from the menu
3) Change the name to 'MyDisplay' or another name, and click 'Commit'
4) Right click on the actor again and select 'Save Archive (KAR)...'
5) Type a name for the kar (probably 'MyDisplay.kar') and click 'Save'
6a) In the component tab, search for 'Display', and navigate to the newly saved kar file, click on the arrow to expand the KAR contents, which will show the original name of the actor (Display)
6b) Drag the new actor to the canvas, which will show the original name of the actor (Display)

Expected behavior:
For 6a, and 6b, the name shown should be the new name of the actor (e.g., 'MyDisplay')

This is a synopsis of an issue reported by Chris Weed on kepler-users.

Related issues

Blocked by Kepler - Bug #5149: kar file saving problems.NewChad Berkley08/16/2010

Actions #1

Updated by David Welker almost 13 years ago

I have looked into this a little bit now, and have found that if you change the "Title" in addition to Name, then the name change works, fixing both problems 6a and 6b noted below.

I am just diving into this area. But it seems strange to me that actors have not only "names," but also "titles" and "display names." Perhaps someone knows about the purpose of these distinctions.

Actions #2

Updated by David Welker almost 13 years ago

I have made major progress in diagnosing this bug. Basically, the issue is not whether you change the "title" (which is a property unique to Display actors) but whether you change any property on the actor besides the name.

If you change a property besides the name, then a new LSID is generated and used for the entity. This causes the name you give to the actor to persist. In contrast, if you the only thing you change on the actor itself is the name, then the LSID for the Display actor (or whatever other actor you are using) is used instead of a new one being generated. For this reason, the name of the Display actor rather than your changes show up in the KAR file.

The way to fix this bug is as follows. A change to the name of the actor needs to be treated just like a change to the value of another property when "Configure Actor" is selected when you right-click on an actor.

I have started to look through the LSID code to fix this bug, but I have determined it is complicated enough that Aaron probably should be the one to fix this so that any changes I make do not cause unexpected side-effects elsewhere. However, if Aaron is not available, I can fix this bug. For now, I am assigning the bug to Aaron on the assumption that he is available for this task.

Actions #3

Updated by Aaron Aaron almost 13 years ago

This was an issue because NamedObjId was not handling the MoMLChangeRequest produced by the RenameConfigurer in ptolemy. In revision 26448 of the kepler trunk I have added the change to the NamedObjId. It depends on a change to the ptolemy trunk (revision 59945). Because Kepler is not being built from the ptolemy trunk I have also added that change as an override in the Kepler core module. should be deleted next time the revision.txt file in the ptolemy kepler module is updated beyond revision 59945.

This change has a side effect of doubly rolling the revision on the workflow, which is philosophically ok but perhaps annoying for the user. I will leave this bug open for now in the hope there is time to track down why the top level container is having its lsid revision rolled twice on a component name change through the ChangeRequest chain produced by the RenameConfigurer.

Actions #4

Updated by Aaron Aaron almost 13 years ago

Turns out the doubly rolling of the revision on the workflow was not a side affect of this change. It always happens when the referral list for the lsid is updated in addition to the lsid itself, which is not a big deal.

To observe this behavior:
1.) drag an actor to the canvas that has an lsid with an authority and/or namespace that is different than the authority/namespace that is assigned to your kepler instance (for example, any of the default actors such as Display)
2.) Right click on the actor and "View LSID"
3.) Note the lsid
4.) Right click on the canvas and "View LSID"
5.) Note the lsid revision
6.) Customize the name of your actor
7.) Refresh the LSID Viewer for the canvas
8.) Notice the revision has rolled twice
9.) Refresh the LSID Viewer for the actor
10.) Notice a new LSID with a new authority and namespace has been assigned and the old one has been added to the "Derived From" list
11.) Now customize the name again
12.) Refresh the LSID Viewer for the canvas
13.) Notice the revision has only rolled once this time

There's nothing intrinsically wrong with this behavior, if we want to change it in the future we can open a new bug for it. Closing this bug.

Actions #5

Updated by Derik Barseghian almost 13 years ago

I updated ptolemy yesterday to r59948. I've deleted your override in r26481.

Actions #6

Updated by Redmine Admin over 10 years ago

Original Bugzilla ID was 5144


Also available in: Atom PDF