What if TinkerCell could support two method of model construction: graphical (drawing) and text-based (scripting)
The resulting design is summarized by the picture to the right. Here are the major modifications:
- A new class, NetworkWindow, has been created. This class is an MDI widget that is used to create the subwindows in the main window. The NetworkWindow contains two important members: history stack and symbols table
- Each NetworkWindow can contain either a GraphicsScene or a TextEditor (new class).
- The GraphicsScene and the TextEditor use their parent NetworkWindow's history stack and symbols table.
- Just as GraphicsScene uses graphics items, TextEditor uses TextItem
- The MainWindow has three signals for indicating that items are inserted or removed. One is the old itemsInserted and itemsRemoved which is connected to GraphicsScene. The second is the same but for TextEditor. The third is generic to GraphicsScene or TextEditor: this signal just contains the handles that have been inserted. Therefore, plug-ins that only need to worry about the handles can listen to this last signal. These plug-ins would work whether the user is using text mode or graphics mode.
The TextEditor is a very simple class (contrary to GraphicsScene). TextEditor does NOT parse the text. The parsing MUST be done by a plug-in. The parser plug-in is expected to listen to the signals in TextEditor and respond by calling the insertItem and removeItem methods in TextEditor.
TextEditor also uses a special undo command that is a composite command. This composite command changes the text along with the other change that it is meant to do (e.g. data changed). The push() method in TextEditor automatically creates this new composite command from the given command.
Tools such as StoichiometryTool and other data-related tool not listen to the generic itemsInserted and itemsRemoved signals. This means that the tools would also work the same when user is using TextEditor or GraphicsScene -- convenient!