Consider using properties to specify settings for visualizations

[jrtom]

Proposed by @tomnelson and discussed in #163; here are some of the relevant bits:

[The idea would be to] put all visualization related property settings in one place, something like VisualizationViewUI.java, which would allow a user to provide a jung.properties file with contents something like this:

jung.nodeColor=0x00FFF0
jung.pickedNodeColor=0x0000FF
jung.defaultEdgeShape=CUBIC_CURVE
jung.spatialSupport=GRID
jung.nodeLabelPosition=SW
jung.nodeShape=SQUARE
jung.nodeSize=12
jung.pickedEdgeColor=0x005555

VisualizationViewerUI would set any user-specified properties and fall back on default values for all of them.

Programmatic settings could still be achieved by doing something like this:

System.setProperty(PICKED_NODE_COLOR, "0x110000")

or

System.setProperty(PICKED_NODE_COLOR, Color.red.getRGB().toString());

instead of

vv.getRenderContext().setVertexFillPaintTransformer(
    new PickableVertexPaintTransformer(vv.getPickedVertexState(), Color.red, Color.yellow)

Issues to be resolved would include:

1. Is this something we want to do? Arguably most users are fine with picking their properties once, and with rebuilding their code if they change them (since I don't think that anyone has ever asked for this capability).
   Put more clearly: what specific problem would we be trying to solve by providing this kind of capability, and what fraction of our users would we expect it to help?
2. Are we talking about a way of overriding defaults at program launch time, or would we expect changes in the properties file to be picked up on the fly?
3. What properties would be specifiable in this way? Node and edge shape/color/stroke? Layout algorithms? Dimensions? More?
4. Are there any existing conventions (specifically as regards managing common types such as Color, Shape, and Stroke) that we would want to incorporate?
5. Where and how would we want to specify default values? (Right now it's basically in the code in PluggableRendererContext, but if we want to enable a big flat file that sets a bunch of properties, it might be helpful for users to be able to easily check for
6. Would we want to namespace any of this more than with just a "jung" prefix?
7. How would this integrate with our existing programmatic mechanisms? Presumably we would still want to have a way of programmatically specifying all the things that can be currently specified in this way.
   • Is this something that could, or should, be built on top of JUNG without changing the existing code? (Does it even need to be part of JUNG per se?)
8. How would we handle bad property specifications? Ignore them and use the default? Log a warning? Throw?

If we want to explore this, I would really, really like to see a design doc that addresses these issues before I saw code.