Community
Participate
Working Groups
To activate the label editor on a node or connection, you need to first make sure that the label has focus, then wait a bit and click on it again. Starting from non-focus state, it is difficult to activate the editor. If you click too fast, it gets registered as double-click. Plus you have to constantly do mental "has focus" check and alternate between "click" and "click+wait+click". To resolve this usability issue and to make this behavior consistent with how table cell editors are activated in Sapphire Form UI, the double-click action should be used. The double-click action should activate editing regardless of focus state. The double-click on a node outside a label can still activate a separate action under developer's control.
This proposed change is a little iffy imo. The click-wait-click approach, as you describe it, has its drawbacks, but is hardly novel convention. Windows Explorer nodes have worked this way for years, as have various graph-based tools. Making it consistent with putting a table cell into edit mode is probably not the right point of comparison. The contexts are fairly different. And re: having dbl-click on label vs the rest of the node do different things, I'd be concerned about the longstanding convention of treating the label like an extension of the node when it comes to double click. I'm not suggesting this isn't something to explore, but I think this solution has potential problems. I, for one, wouldn't think to dbl-click a node label to edit it - so if this were the only approach, it'll probably have discoverability issues for some users unless we continue to support the existing behavior as well. Another possible approach (ironically also taken from table editing) is to just begin typing once the node has focus, placing the node in edit mode an overwriting the current content. It's not always what you'd want, but works well in the case of naming newly created nodes. Another common approach for the newly created node is to put the node label in edit mode on creation. That also facilitates the very common scenario. Finally, I don't suggest this as a solution to the click-wait-click issue at the genesis of the bug, but F2 is an alternative for making nodes editable that we should probably support here. (I notice it's working for link labels, but not node labels.)
> Making it consistent with putting a table cell into edit mode is probably not > the right point of comparison. The contexts are fairly different. Users are going to utilize the diagram UI side-by-side with form UI in properties view and in the form page of the editor. The behaviors and gestures should be consistent. The bar for justifying inconsistency is pretty high in my mind. > And re: having dbl-click on label vs the rest of the node do different > things, I'd be concerned about the longstanding convention of treating the > label like in extension of the node when it comes to double click. Both approaches are susceptible to accidental activation. In click-wait-click approach, if the node is already selected, one can trigger edit mode unintentionally simply clicking on the node again (maybe in thought, maybe trying to move it). I isn't clear to me that either approach is better/worse here. > Another possible approach (ironically also taken from table editing) is to > just begin typing once the node has focus, placing the node in edit mode an > overwriting the current content. It's not always what you'd want, but works > well in the case of naming newly created nodes. Hmm... I am not sure. Typical default behavior when typing with table in focus is to search (selection is moved) rather than edit. > Another common approach for the newly created node is to put the node label > in edit mode on creation. That also facilitates the very common scenario. That is a good enhancement, but doesn't address this issue. > Finally, I don't suggest this as a solution to the click-wait-click issue at > the genesis of the bug, but F2 is an alternative for making nodes editable > that we should probably support here. (I notice it's working for link > labels, but not node labels.) Is there precedent for using F2 for this? In form UI, we use ENTER.
Thinking some more on comparison of our diagram editing feature and Windows Explorer... One important characteristic that we must look at is relative frequency of actions. In Windows Explorer case, the open/run action is far more frequent than rename action. In our diagrams, the rename action is far more frequent than the open action. In fact, on connection labels, we have no usecase for open action at all. In many diagrams, there will be no usecase for open action on nodes either. Another important aspect that undoubtedly influenced Windows Explorer choice of gestures is that Windows Explorer can switch between icon and table displays. When switching between those two modes, the gestures for open and rename must remain the same. While in icon mode, double-click could be differently interpreted based on the location, there was no possibility to do that in the table view. I have originally thought that we have no parallels to "open" action in the Forms UI, but we do. We call it the jump action there and it is activated by a ctrl-click or ctrl-alt-shift-J. This works in conjunction with visual affordance of a hyperlink when you ctrl-hover. So given all of those considerations, here is my current proposal... 1. Double-click on node or connection label activates edit mode regardless of selection state. 2. Double-click on a node outside a label boundary activates the jump action if one is available. 3. Ctrl-click anywhere on the node (including the label) activates the jump action. 4. Ctrl-hover over the node visually shows whether jump action is available (perhaps using a certain border color).
>>Is there precedent for using F2 for this? In form UI, we use ENTER. Yes, it's actually a very widely supported (if little known) convention that probably dates back to mainframes. I'm pretty sure it was in Windows 1.0 and the MS Office products, it's in Eclipse (although Project Explorer doesn't do the typical inline edit), and more importantly it's in GEF/Graphiti - select a link label and hit F2. Just isn't supported for node labels.
There is a Graphiti bug related to activating node label editing when the node has focus using F2: https://bugs.eclipse.org/bugs/show_bug.cgi?id=333985
I've taken a stab at this controversial single click, double click issue: 1. Double clicking on node or connection labels will invoke direct editing of the labels. Double clicking on other parts of the node will invoke node default action. 2. Single click on node/connection label when the node or connection label has focus also activate direct editing of the labels. 3. When a new node or new connection is created, its label is placed in edit mode. 4. F2 is still a viable option to place the node/connection label in edit mode. We need the fix for Graphiti bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=333985 If our customers have strong opinions/objects on this approach, we should revisit it.
Verified #1. #2 also works, but is tracked separately. This is a definite improvement. Please open a separate bug for 0.4 release to disable click-wait-click editing activation. We can do that as part of removing Graphiti. I have noticed the following related problems as part of verifying this fix: 1. When connection label editing is activated, the text box exceeds the bounds of the orange connection label selection outline. 2. If you activate edit mode on node label, then click somewhere else on the node to de-activate edit mode and then quickly move mouse pointer over the node label, the edit mode is activated again. One or both of these maybe Graphiti issues. Please add links in this bug if you end up opening Graphiti bugs.
(In reply to comment #7) > Verified #1. #2 also works, but is tracked separately. > > This is a definite improvement. > > Please open a separate bug for 0.4 release to disable click-wait-click editing > activation. We can do that as part of removing Graphiti. > https://bugs.eclipse.org/bugs/show_bug.cgi?id=348640 > I have noticed the following related problems as part of verifying this fix: > > 1. When connection label editing is activated, the text box exceeds the bounds > of the orange connection label selection outline. > Graphiti issue tracked by https://bugs.eclipse.org/bugs/show_bug.cgi?id=348637 > 2. If you activate edit mode on node label, then click somewhere else on the > node to de-activate edit mode and then quickly move mouse pointer over the node > label, the edit mode is activated again. > Again Graphiti issued tracked by https://bugs.eclipse.org/bugs/show_bug.cgi?id=348634 > One or both of these maybe Graphiti issues. Please add links in this bug if you > end up opening Graphiti bugs.
