Consistent node border highlighting in the model

[GoogleCodeExporter]

The node border color is changed to red when the node's log lines are 
displayed. To be consistent, the nodes' border color should be made blue when 
the paths through those nodes are listed.

The blue bgcolor of the nodes should only be used to signify that the nodes are 
part of the currently selected shift+click node set.

Here are a few scenarios that must be supposed by this change.

Scenario 1:
1. User selects nodes using shift+click, and the nodes' bgcolor is made blue.
2. User clicks on "View Paths" and the selected nodes' bgcolor is made pink, 
while their borders are made blue.

Scenario 2:
1. User single clicks on a node.
2. The clicked node's bgcolor remains pink, while the node's border turns red.
3. User shift+clicks on the same node, and the node's bgcolor is made blue
4. User clicks on "View Paths" and the selected node's bgcolor is made pink, 
while the border is changed from red to blue.

Original issue reported on code.google.com by bestchai on 25 Jan 2012 at 4:15

[GoogleCodeExporter]

Taking owernship.

Original comment by kevin.a....@gmail.com on 29 Jan 2012 at 8:14

[GoogleCodeExporter]

I'm having troubles figuring how ModelTab.java and graphhandler.js speak to 
each other. When the "View Paths" button is clicked in ModelTab.java, how do I 
make graphhandler.js aware of this so that I can change the bg/border colors?

Original comment by kevin.a....@gmail.com on 29 Jan 2012 at 9:38

[GoogleCodeExporter]

The communication pattern between ModelTab.java and graphhandler.js has been 
primarily one-way -- graphhandler.js events trigger method calls in ModelTab 
(e.g., like when a node is clicked). Window resize is a good example of going 
in the other direction -- ModelGraphic.java is the Java/JS interface and 
contains a resizeGraph() JSNI method, which is used for re-rendering the 
graphic.

I think the way to approach this issue is to create new JSNI methods in 
ModelGraphic that can update a border for some arbitrary graphic node to an 
arbitrary color, all in JS. Then call this method from ModelTab with 
appropriate arguments.

Original comment by bestchai on 29 Jan 2012 at 5:39

• Changed state: Started

[GoogleCodeExporter]

For scenario 2, I think for a single click on a node, the bgcolor should be 
blue along with a red border. It doesn't make sense to make the bgcolor pink 
because that node is technically part of the shift-click node set.

Original comment by kevin.a....@gmail.com on 30 Jan 2012 at 7:44

[GoogleCodeExporter]

I think what I meant to say is that we should change the single click behavior 
to not add the clicked node to the shift-click node set. Which is why the 
node's bgcolor shouldn't be blue. I would like for the single click to be 
entirely independent of the shift-click, as these are completely orthogonal 
operations.

Original comment by bestchai on 30 Jan 2012 at 8:16

[GoogleCodeExporter]

Solution in revision 6a0a829b9ecb, please review.

Original comment by kevin.a....@gmail.com on 30 Jan 2012 at 9:23

[GoogleCodeExporter]

One small bug with this solution - the red border does does not disappear if 
the single click node is not included in the shift-click set, and view paths is 
clicked.

As a result, you get something that looks like the attached model, with both 
red and blue border nodes. There should only be one kind of border color shown 
at any one time.

Original comment by bestchai on 30 Jan 2012 at 5:25

Attachments:

• model-border-blue-red.jpg

[GoogleCodeExporter]

Fixed bug in revision de7bade5a3e5, please review.

Original comment by kevin.a....@gmail.com on 30 Jan 2012 at 11:21

[GoogleCodeExporter]

Ok, the red border is no longer there when paths are shown, but the blue border 
is now also gone for the node that is both clicked and in the shift-click set.

That is, if a node is clicked, and shift-clicked. If view-paths is then 
clicked, the node's border should be blue. Instead, the current code doesn't 
give it any border.

Original comment by bestchai on 31 Jan 2012 at 12:50

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Bug fix in revision 6e674e15175f, please review.

Original comment by kevin.a....@gmail.com on 31 Jan 2012 at 1:58

[GoogleCodeExporter]

Merged into default with revision 39d38d463cda

Original comment by bestchai on 31 Jan 2012 at 3:03

• Changed state: Fixed