|
|
New Operator Design
|
|
|
===
|
|
|
Current Design
|
|
|
---
|
|
|
|
|
|
* The current operator design in SMTK/CMB is focused on model sessions and meshing procedures.
|
|
|
* The simplest way to add new operations is to either extend an existing Session or create/derive a new Session class.
|
|
|
* Meshing (and Exporting) operations are treated somewhat specially - Meshing operations are relegated to a special panel or as a something under the file menu (export simulation).
|
|
|
* No way to process an operation asynchronously or get ongoing status back
|
|
|
* Operations are modeled using SMTK's attributes and tend to need their own attribute system
|
|
|
* In client/server applications (like CMB) attribute definitions of the operators (and the resulting instances) are sent between the client and server
|
|
|
* There is no way to restrict which operations are needed for a specific task or indicate how they should be displayed.
|
|
|
|
|
|
Proposed Design
|
|
|
---
|
|
|
### Generalizing Operator
|
|
|
* The base class Operator should be moved out of smtk/model since operators need not only refer to models (export operators, meshing operators, etc..)
|
|
|
* Currently the operator assumes that it is defined by a single attribute definition - Is this sufficient or should it be defined by its own attribute system?
|
|
|
* Should Sessions know about Operators or should it be the other way around?
|
|
|
* If Operators where outside of Sessions, would it make the Sessions simpler/more manageable ?
|
|
|
* Should Operators provide their own View Layout (maybe a default one?)?
|
|
|
* You may want an operator to look differently based on the Task at hand.
|
|
|
* Operator's State should be one of the following:
|
|
|
* Not Ready to Run
|
|
|
* Ready to Run
|
|
|
* Running
|
|
|
* Completed
|
|
|
* Error (?)
|
|
|
* Operators produce status (is this straight text or a Logger?)
|
|
|
* Operators can be synchronous or asynchronous
|
|
|
* Operators can "lock" the resources (models, meshes, attribute systems) and resource components (mesh Sets, model entities, attributes) they are referring to
|
|
|
* If the resource is not available due to locking then the operator must wait
|
|
|
* The lock can indicate if reading is permitted
|
|
|
* Resources can be unlocked prior to operator completion (for example a meshing operator may unlock the model was it has been translated into the format needed by the mesher.
|
|
|
* Should be able to create Python "glue" operators that call wrapped C++ functions
|
|
|
|
|
|
### Operator Manager
|
|
|
|
|
|
* This singleton is responsible for the execution of Operators as well as providing status back from asynchronous Operators.
|
|
|
* Operators would be registered with the manager
|
|
|
* This manager would be able to indicate the current status of defined operations |