Clashing macros!

[jimfinnis]

Macro definitions are global to the entire application, because they exist as custom XFormType objects. This is OK, and potentially useful, except for one thing. What happens if we open a file containing a macro "foo", and then open a different file (perhaps in a different window, perhaps in the same one) also containing a macro "foo"?

At the moment, the system throws an exception - "xform type name already in use." It's trying to add the new macro definition when one already exists. Not sure what the semantics should be here.

Options:

• Make macros local to graphs. Messy, because a lot relies on the simplicity of registering them like any type object.
• Find some way of resolving the conflict.
  • Would possibly involve comparing them? Comparing a graph of objects like this is pretty grim and prone to error. Unless we compare the serialised versions.. even then we'd have to make sure we could compare the numpy arrays.
  • Just use the new version but flag you're doing it. That's nasty too.
  • In either case, we'd have replace all to regenerate all the instances in the existing graphs. We'd have to do this by scanning for the old prototype, replacing with the new prototype and calling changed on that graph, or by replacing the old prototype's graph with that for the new prototype (and again calling changed() on all graphs).

[jimfinnis]

OK, I'm actually going to make macros local to graphs. The other solutions are prone to user error. That means:

Macros now belong to graphs, so

• graphs need their own dict of types
• palettes need a link to the graph to permit repopulation with the right types

Things to consider

• what happens when you cut a macro instance from a graph and paste it into another one?
• on a similar note, how do we transfer macros from one graph to another?

[jimfinnis]

Dammit, what happens with macros embedded in macros? I think I'm going to have to go back to the original plan (macros are global). Otherwise, macros-as-graphs would have to own other macro prototypes, and that seems wrong, particularly when there might be a macro used inside several other macros. Each would have to hold a copy, only it wouldn't be a copy, it would be entirely separate - and that would cause confusion.

[jimfinnis]

Scratch that. Macros are NOT global. I'm now using a new Document class to keep the main graph, the graph's macros, and the settings. It seems to work, and it should be easy enough to write code to import macros from one Document into another. That's not done, but I will now close this bug.