Config file format

[tbekolay]

Currently, the information that Nengo GUI uses to position netgraph items and construct plots is stored in a .py.cfg file, which is actually a Python file that ends up being executed as part of loading up a Python script.

I am partly speculating and partly going off of memory, but I believe that this file format was chosen because:

1. We can parse and evaluate it easily using Python's exec.

2. It leverages the existing config system used in Nengo core. In particular, it might be the case that other visualizers (not Nengo GUI) might benefit from knowing the position and size of Nengo objects for their visualizations.

There are a few downsides to this file format:

1. While it's easy to parse in Python, it's not easy in other languages (notably TypeScript / JavaScript, which might want to parse this file one day).

2. It's not particularly compact:

   _viz_1 = nengo_gui.components.Value(a)
   _viz_config[_viz_1].synapse = 0.01
   _viz_config[_viz_1].max_value = 1
   _viz_config[_viz_1].min_value = -1
   _viz_config[_viz_1].legend_labels = [u'label_0']
   _viz_config[_viz_1].height = 0.15631105900742479
   _viz_config[_viz_1].label_visible = True
   _viz_config[_viz_1].width = 0.11242270938729623
   _viz_config[_viz_1].show_legend = False
   _viz_config[_viz_1].y = 1.076554956024495
   _viz_config[_viz_1].x = 0.7566623456266636

   _viz_config[_viz_1] is repeated 10 times because of the way the config system is designed.

3. The config system is not the easiest part of Nengo to understand, nor has not been optimized to be modified very rapidly (as is done whenever an object in the GUI moves or is resized).

---

With the refactoring going on in #806, it is pretty much necessary to make some modifications to the .py.cfg files. To this point I have been trying to keep them similar, but in order to simplify the backend code, there will have to be at least some changes to these files. Because of that, I have written a quick script to parse these files and generate a file that will work after the refactoring. Since the GUI has not yet seen a 1.0 release, it seems like making changes to these files should be acceptable, especially since it can be done behind the scenes without the user having to know that these files have changed at all.

It would simplify the backend code even further if we were not bound to the .py.cfg file format. Specifically, I propose that we use JSON files to specify the GUI configuration associated with a Python file. There are several benefits to this:

1. JSON is widely used with many well optimized libraries in many languages (JavaScript and TypeScript will read them trivially, and Python has a JSON module in the standard library that we already make use of in the GUI).

2. The representation is relatively compact -- definitely not minimalist (it's still easily human readable) but it doesn't have unnecessary repetition. The above example in JSON would be something like:

   _viz_1: {
       "component_type": "Value",
       "object": "a",
       "synapse": 0.01,
       "max_value": 1,
       "min_value": -1,
       "legend_labels": ["label_0"],
       "height": 0.15631105900742479,
       "label_visible": true,
       "width": 0.11242270938729623,
       "show_legend": false,
       "y": 1.076554956024495,
       "x": 0.7566623456266636
   }

3. It simplifies the backend code and makes it much easier to test.

---

As previously mentioned, this can be done automatically without user intervention (though it would likely be good to rename the .py.cfg files to .json or .layout or something like that). Are there any other reasons not to make this change? If not, can I get the go-ahead before changing the backend code in #806?

[tbekolay]

Apologies, posted this originally with no comment. I've edited the first post with content, please check it out and let me know what you think (tagging especially @tcstewar, @celiasmith and @Seanny123).

[tbekolay]

3 👍s on the main comment so far, so I'm going to move forward with it. If there are any major concerns please reopen this issue and voice them as soon as possible.