glue-viz/glue — pull request #488 by astrofrog (2014-10-30 16:11:25+00:00)
Title: Refactor how toolbar configuration for different widgets

I have been thinking about how to further generalize which tools appear on for which widgets, and here are the different options I've come up with so far:

1. For the PV slicer and spectrum tool I created a ToolRegistry and then made it so one could define which widget the tool applies to. When one wants to access the tool list, one can then optionally make sub-classes be recognized. I don't think this is going to be easy to manage once we start adding more tools there. The downside of this approach is that the definition of the default tools should really live in the widget itself, not in some completely different part of glue. The list of defaults might also get quite long as we add more widgets. Finally, the way the defaults are handled currently, one cannot *remove* tools from the registry for a given widget, only add them, so this is not ideal configuration.

2. A related but slightly different option is to create the tool registry but to add entries to it not as defaults but from the widget class files. This gets around the issues described above by making the tools be defined in the same place as the widget classes and also means that tools can be removed (since they aren't defined as ``default_members``

3. Another option is to do away with the tool registry completely and instead each widget class would have a property that returns which tools to use. One could then sub-class a widget and override this. This is actually what I do in the standalone PV slicer (https://github.com/astrofrog/custom-glue-app/blob/master/pv_slicer.py#L44) because it's not currently possible to remove defaults from a registry (see 1). The downside of 3 is that once cannot remote or add any tools to existing widgets in glue, but has to always sub-class.

4. A final option is to simply have a class-level attribute which is a list of tools to use. One can then easily modify this for all instances. In a way, this is a class-level registry.

I think that the only two realistic options are 2 and 4 because they are the only ones that allow one to remove tools from existing widgets. Solution 4 seems quite nice and wouldn't have the overhead of dealing with the registry, but there may be some downsides I'm not seeing.

@ChrisBeaumont - do you have any thoughts on this?