|
|
# One the Road to CMB 5.0
|
|
|
|
|
|
## Adding Project Concept
|
|
|
* The current ad hoc approach of forcing the user to manage multiple files related to their use case is problematic
|
|
|
* Adding the concept of a project directory as the place of storing all of the files (smtk models, attribute systems, meshes, etc..) would simplify the user's task of project management
|
|
|
* The suggested suffix would be .cmbproj and .smtkproj
|
|
|
* An smtk project would just contain resource related information (models, meshes, attributes) while the cmb project would be a superset including workflow related information including application state
|
|
|
* All modifiable files would be located in that directory
|
|
|
* Files that exist outside of the that directory can be used but are considered read only
|
|
|
* This would allow the reuse of pre-existing models (both native and smtk), meshes, etc..
|
|
|
* If the user wants to modify a "read-only" resource it will be relocated to the project directory
|
|
|
* The project would also contain the state of the project's workflow if needed
|
|
|
* The project would also hold the CMB Application State (views, loaded resources, plugins)
|
|
|
* Save would by default save the entire project (modified attribute systems, models, meshes, etc..)
|
|
|
* Should in the future provide the ability to save parts of the project during the session
|
|
|
* Similarly it is the Project that gets loaded into the application
|
|
|
* All of the resources contained in the project would be displayed as well as indicating if the resource is loaded into memory
|
|
|
* Provide an option to create a self-contained project with no external dependences including python export scripts
|
|
|
|
|
|
|
|
|
### Project Template
|
|
|
Similarly to attribute templates, a project template provides a description for a type of workflow and would contain the following:
|
|
|
|
|
|
* What plugins are needed for this type of project
|
|
|
* What workflow is the project going to use? If none is specifying then the following information would be specified
|
|
|
* The types of models will the project be using?
|
|
|
* Possibly the dimension of the model
|
|
|
* The operations will project be using as well as the names/icons that should be used
|
|
|
* The attribute template if any is the project should use?
|
|
|
* When a new model is created an attribute system would automatically be created
|
|
|
* The default layout of the ModelBuilding GUI
|
|
|
* Naming conventions for resources and resource components
|
|
|
* Names that should be used to refer to things like models and model entities
|
|
|
* Types of mesh workers
|
|
|
* Post-processing pipelines
|
|
|
|
|
|
|
|
|
## Current Work
|
|
|
### Resources (See [https://gitlab.kitware.com/cmb/smtk/wikis/enhancement-to-resources-in-smtk-2.0])
|
|
|
### Workflows (See https://gitlab.kitware.com/cmb/cmb/wikis/cmb-architecture-and-workflow-processing)
|
|
|
### Implementing Projects
|
|
|
* Need to Restructure Resource Class and create Resource Manager
|
|
|
* Have ability to assign readers and writers to the Resource Manager based on the type of resources
|
|
|
* Need to have attribute systems be under a model (similar to the way meshes are)
|
|
|
### Multiple Views
|
|
|
* Need to Restructure ParaView Representations for SMTK Models |
|
|
\ No newline at end of file |