... | ... | @@ -15,13 +15,13 @@ 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..)
|
|
|
** We could add an Operator class in smtk/common, and make smtk/model/Operator a derived class of smtk/Common/Operator. (Yumin)
|
|
|
... We could add an Operator class in smtk/common, and make smtk/model/Operator a derived class of smtk/Common/Operator. (Yumin)
|
|
|
* 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?
|
|
|
** One limitation with one attribute system for operators in a session is that we can't override an operator's spec with a new one, however an operator with its own attribute system seems to be overkill. (Yumin)
|
|
|
... One limitation with one attribute system for operators in a session is that we can't override an operator's spec with a new one, however an operator with its own attribute system seems to be overkill. (Yumin)
|
|
|
* 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?)?
|
|
|
** By default we are using instanced view, and for some polygon operators (create edge, edit edge, split edge), we already are using customized view layout. (Yumin)
|
|
|
... By default we are using instanced view, and for some polygon operators (create edge, edit edge, split edge), we already are using customized view layout. (Yumin)
|
|
|
* 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
|
... | ... | @@ -29,7 +29,7 @@ Proposed Design |
|
|
* Running
|
|
|
* Completed
|
|
|
* Error (?)
|
|
|
**Combining Rob's comment: Not Ready, Queued, Running, Paused(Waiting), Completed. (Yumin)
|
|
|
... Combining Rob's comment: Not Ready, Queued, Running, Paused(Waiting), Completed. (Yumin)
|
|
|
* 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
|
... | ... | @@ -37,14 +37,14 @@ Proposed Design |
|
|
* 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
|
|
|
** Operators should able to generate a reproducible state for Undo/Redo from applications. (Yumin)
|
|
|
* Operators should able to generate a reproducible state for Undo/Redo from applications. (Yumin)
|
|
|
|
|
|
### 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
|
|
|
** We should be able to cancel operations, and define priorities of operations. (Yumin)
|
|
|
* We should be able to cancel operations, and define priorities of operations. (Yumin)
|
|
|
|
|
|
|
|
|
|
... | ... | |