Ticket #638 (closed Defect: wontfix)
After renaming a topicmap, it does not get updated in drop-down menu or in Topicmap Panel
| Reported by: | carolina | Owned by: | |
|---|---|---|---|
| Priority: | Minor | Milestone: | |
| Component: | DeepaMehta Standard Distribution | Version: | 4.2 |
| Keywords: | Cc: | ||
| Complexity: | 3 | Area: | |
| Module: |
Description
When renaming a Topicmap, the name does not get updated in the Topicmap Type in the Topicmap Panel (although in the Detail Panel appears the new name) nor in the Toolbar drop-down menu
Attachments
Change History
comment:1 Changed 11 years ago by jri
To rename a topicmap make sure to edit the Topicmap topic. The toolbar's Topicmap menu is updated properly then. Also the change is properly propagated downwards to the topicmap's Name topic then.
I guess you edited the topicmap's "Name" child topic directly. In this case the change is neither propagated to the parent nor reflected in the GUI. While this might be considered a bug this is not the way a topicmap rename is supposed to be performed.
In general editing any child topic directly is not supported by DM. For example editing a Note's Text topic does not affect the Note. Edit the parent topic = the Note topic instead, and all works fine. Yes, this could be regarded an error in general. However I see it rather as a GUI design problem. The user should possibly not be able to edit any child topic directly. Implementing proper propagation of all the resulting changes would be too laborious from my view while providing no benefit for the user at all.
The user is supposed to edit the parent topic = the composite. The GUI should prohibit the user to edit child's directly, while the prohibition rule is not 100% clear to me. It's an open problem.
comment:2 follow-up: ↓ 3 Changed 11 years ago by carolina
Ok, thanks. Yes, the mistake was due to editing the topicmap's "Name" directly. This happened because, while being in the Topicmap topic, when double-clicking on "Name" in the Detail Panel(expecting it to be editable), it changes to topicpmap's "Name" details. Then, since clicking on the "Name" has no result, the user "looks for" the edit button, clicks on it, does the change and expects, that the change will also take place on the parent Topicmap topic.
As a first thought, I would say is ok that the user can edit the childs. The confusing part is that changing the child,in the case of composition associations, does not modify the parent topic.
But I agree, is a GUI design problem not a bug, so a suggestion would be to add to the trac tickets, the "GUI design problem" as a ticket type ;)
comment:3 in reply to: ↑ 2 Changed 11 years ago by jri
Replying to carolina:
Ok, thanks. Yes, the mistake was due to editing the topicmap's "Name" directly. This happened because, while being in the Topicmap topic, when double-clicking on "Name" in the Detail Panel(expecting it to be editable), it changes to topicpmap's "Name" details. Then, since clicking on the "Name" has no result, the user "looks for" the edit button, clicks on it, does the change and expects, that the change will also take place on the parent Topicmap topic.
Yes, your doing is completely reasonable! I'm aware DM has a big usability problem here. A lot of users do fall in this trap.
I see 2 TODOs here:
1) enable click-to-edit as this is what users expect nowadays. Don't require them to look for an Edit button (which, being located at the page bottom, is far too away). JuergeN addressed this issue too in #416.
2) redesign the "reveal child topic" gesture to not let users do so accidentally. In most of the cases users want edit the clicked info in-place and NOT to reveal the child topic. You addressed that in #624.
Thank you very much for reporting!
