Community
Participate
Working Groups
In the default node presentation (such as the map sample), if you enter a short node label, there looks to be a lot of room in the node on left and right of the label. However, double-clicking in that area activates the edit mode. I would expect it to activate the default node action. Activation of the edit mode should be constrained to the actual bounds of the text (even if the text box that is later shown stretches across the entire node).
Targeting to 0.3 for evaluation. If this is going to be difficult due to Graphiti, I am fine with deferring to 0.4 release.
Bulk deferral of diagram-related items to the 0.5 release.
This is still relevant post GEF migration. Ling, maybe you can take a look at this one?
The edit box was extending beyond the node boundary and when editing the text was right aligned instead of center aligned. These fixes were checked in. The current behavior seems correct. When the text editing is inside a boundary - the cell editing is expanded to the boundary. This is the behavior in the GEF sample and in graphiti.
Verified that the text is centered aligned and the cell editor doesn't extend the node boundary when direct edit is activated. The activation area size is consistent with Graphiti and GEF samples. Closing.
Sorry, but this isn't how I'd like this to work regardless of what is customary for Graphiti and GEF. Since double-click on a node is either edit mode activation or the default node action (whatever that might be), we need to carefully constrain the boundary box of edit mode activation to the actual text. Extending activation area to node boundaries takes too much area away from default node action activation. Also, if I activate direct edit mode in one of the sample editors, the text box extends slightly beyond node boundary. For presentation aesthetics, I would like to see the text box constrainted to be let's say two pixels inset from the dark blue border.
(In reply to comment #6) > Sorry, but this isn't how I'd like this to work regardless of what is customary > for Graphiti and GEF. Since double-click on a node is either edit mode > activation or the default node action (whatever that might be), we need to > carefully constrain the boundary box of edit mode activation to the actual > text. Extending activation area to node boundaries takes too much area away > from default node action activation. In Diagram Node's definition, developers can specify the label size. This is mainly for cases where diagram node's presentation is an image plus label placed vertically but it's desired to give label extra width to allow long labels. In this case, when calculating the node size, we use the label width as the node width. But you can still argue for such case if the label is short, we should use what's occupied by the text rather than what's specified by the label width for the direct edit activation area.
I've checked in the fix for the direct edit activation area size. It now uses what's occupied by the text rather than the space reserved for the label.
> I've checked in the fix for the direct edit activation area size. It now uses > what's occupied by the text rather than the space reserved for the label. I've verified this portion of the fix. Working well now. Thanks. The issue with size of the direct edit text box is still there.
Direct edit text box is now the size of the text.
Better, but there is still one thing that I'd like to see corrected. If I type into the text field, the size of the field expands until it reaches node width. That's fine, but it looks like max size calculation isn't quite correct. The right edge of the text field reaches a pixel or two past the node border. For best presentation, neither left nor right edge should ever touch node border. There should be a visible margin between text field border and node border. Let's set that margin at 2 pixels for now.
Added buffer.
This is still not working well. The behavior is inconsistent. Sometimes left edge touches. Sometimes right edge touches. Sometimes right edge exceeds.
checked in new cell editor location calculation. Weird behavior happens only when a scroll bar is present.
Works fine now. Verified. Closing.
