# SMTK/CMB Release To-Do
**URL:** https://discourse.kitware.com/t/smtk-cmb-release-to-do/166
**Category:** Software Process
**Created:** [October 10, 2018, 7:00pm UTC](https://discourse.kitware.com/t/smtk-cmb-release-to-do/166 "2018-10-10T19:00:43Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@dcthomp](https://discourse.kitware.com/u/dcthomp)
#### Post date: [October 10, 2018, 7:00pm UTC](https://discourse.kitware.com/t/smtk-cmb-release-to-do/166/1 "2018-10-10T19:00:43Z")
The following issues are things we plan to address for the upcoming SMTK 3/CMB 6 release.
- SMTK Dashboard [smtk#189](https://gitlab.kitware.com/cmb/smtk/issues/189)
- Non-running tutorials (fixed!)
- Broken SMTK tests
- Force create (fixed!)
- Open Paraview (deferred)
- Check Talos
- Kerbin
- Trenzalore
- CMB Dashboard [cmb#196](https://gitlab.kitware.com/cmb/cmb/issues/196)
- CMBTests --\> New CMB tests
- Packaging
- Assigned colors, update problem [smtk#190](https://gitlab.kitware.com/cmb/smtk/issues/190)
- Change name (fixed!)
- Assign colors – different selection [smtk#190](https://gitlab.kitware.com/cmb/smtk/issues/190)
- Use resource links for association; affects modelview widget, component item view [smtk#191](https://gitlab.kitware.com/cmb/smtk/issues/191)
- Simplify export logic [smtk#192](https://gitlab.kitware.com/cmb/smtk/issues/192)
- Component items widget color feedback [smtk#194](https://gitlab.kitware.com/cmb/smtk/issues/194)
- SMTK mesh should become a resource with components [smtk#179](https://gitlab.kitware.com/cmb/smtk/issues/179)
- SMTK conda (merge branch, nightly builds, updates) [smtk#193](https://gitlab.kitware.com/cmb/smtk/issues/193)
- Association operation (complete!) [smtk#175](https://gitlab.kitware.com/cmb/smtk/issues/175)
- Association visual feedback [smtk#176](https://gitlab.kitware.com/cmb/smtk/issues/176) [smtk#195](https://gitlab.kitware.com/cmb/smtk/issues/195)
- Apply button logic --\> operators (complete!) [smtk#172](https://gitlab.kitware.com/cmb/smtk/issues/172)
- Save/restore state [cmb#188](https://gitlab.kitware.com/cmb/cmb/issues/188), [cmb#197](https://gitlab.kitware.com/cmb/cmb/issues/197)
- Modified state visual feedback [smtk#197](https://gitlab.kitware.com/cmb/smtk/issues/197)
- Remote file browser [smtk#200](https://gitlab.kitware.com/cmb/smtk/issues/200)
- 3D widgets [smtk#196](https://gitlab.kitware.com/cmb/smtk/issues/196)
- Model centric view [smtk#198](https://gitlab.kitware.com/cmb/smtk/issues/198)
- Operation updates should affect 3-d render window [smtk#199](https://gitlab.kitware.com/cmb/smtk/issues/199)
- Model refresh doesn’t always appear to happen. (fixed!)
- Assign colors should work multiple times in a row with different selections but appears not to. (fixed)
- Model representation in 3D view has its colors reset instead of updating colors for color-by-entity mode.
- Resource links should be used to provide attribute UI with related model components [smtk#191](https://gitlab.kitware.com/cmb/smtk/issues/191)
---
### Author:  [@dcthomp](https://discourse.kitware.com/u/dcthomp)
#### Post date: [October 11, 2018, 12:49pm UTC](https://discourse.kitware.com/t/smtk-cmb-release-to-do/166/2 "2018-10-11T12:49:41Z")
These have been entered into the issue tracker and are marked against our release milestones:
- [cmb 6.0](https://gitlab.kitware.com/cmb/cmb/milestones/7)
- [smtk 3.0](https://gitlab.kitware.com/cmb/smtk/milestones/4)
---
### Author:  [@dcthomp](https://discourse.kitware.com/u/dcthomp)
#### Post date: [October 29, 2018, 12:16am UTC](https://discourse.kitware.com/t/smtk-cmb-release-to-do/166/3 "2018-10-29T00:16:17Z")
@Bob_Obara @tj.corona ,
One of the things that went away with the new operation subsystem is how some operations marked their results as “clean” vs “dirty”. This is what the modelbuilder app and the descriptive phrase system used to decide whether models needed to be saved or not. I have a feeling we will want to change how it is done but don’t know if it is important for the SMTK/CMB release.
Previously, operations such as “read” and “write” added a VoidItem named “cleanse entities” that indicated associated models (not resources) should be marked clean (as is true immediately after a read or write, but not after import/export or most other operations). Lacking that, the base operator class would mark the owning model as dirty. See doc/userguide/model/operators.rst line 103 for details. The docs should be updated based on what we decide; at a minimum, I expect we really want to mark resources not models as clean.
I’ve updated the descriptive phrase stuff to show clean/dirty markings and it will appear in a MR soon.
TJ has already added methods to mark resources this way, but the current use of these methods appears haphazard (polygon and the base model SessionIOJSON classes call it; nothing else does — including the attribute read/write operations). This is one of the reasons I prefer a default behavior for operations to mark their operands’ resources dirty.
1. Should I file an issue against SMTK 3.0? CMB 6.0? Something else?
2. Do you have feelings about something to automatically mark resources dirty/clean? At least some helper methods? Or a way to test operations to ensure they mark properly?
---
### Author:  [@tj.corona](https://discourse.kitware.com/u/tj.corona)
#### Post date: [October 29, 2018, 12:53pm UTC](https://discourse.kitware.com/t/smtk-cmb-release-to-do/166/4 "2018-10-29T12:53:36Z")
> Previously, operations such as “read” and “write” added a VoidItem named “cleanse entities” that indicated associated models (not resources) should be marked clean (as is true immediately after a read or write, but not after import/export or most other operations).
I really didn’t like the idea of “encoding” actions into operators’ attributes without those pieces being present in a base operator result description.
> Lacking that, the base operator class would mark the owning model as dirty.
I think this was better than the above method, but it still made use of run-time “properties” to describe information that is known at compile time (the Write operation knows at compile time that, upon success, its resource should be marked as clean).
> TJ has already added methods to mark resources this way, but the current use of these methods appears haphazard (polygon and the base model SessionIOJSON classes call it; nothing else does — including the attribute read/write operations).
Not sure if it was me who added these methods (I fixed the comment style of the methods to match the rest of the class), but I agree that their use has been haphazard. In fact, the implementation of all operation results involving resources (as opposed to components) has been haphazard to date (and I am largely to blame); their inclusion into operation results warrants a discussion.
> Do you have feelings about something to automatically mark resources dirty/clean? At least some helper methods? Or a way to test operations to ensure they mark properly?
Couldn’t we inspect the “created”, “modified” and “expunged” components and simply mark their resources as dirty? As for marking resources as clean, once we agree on a uniform way of marking resources (preferably using compiled API), it would likely be a single function call in a small subset of operations (the ones that write). Unless I am missing something, do we need additional code/helper methods to accomplish this?
---
### Author:  [@dcthomp](https://discourse.kitware.com/u/dcthomp)
#### Post date: [October 29, 2018, 1:07pm UTC](https://discourse.kitware.com/t/smtk-cmb-release-to-do/166/5 "2018-10-29T13:07:08Z")
> [@tj.corona](#):
>
> I really didn’t like the idea of “encoding” actions into operators’ attributes without those pieces being present in a base operator result description.
Agreed.
> [@tj.corona](#):
>
> I think this was better than the above method, but it still made use of run-time “properties” to describe information that is known at compile time (the Write operation knows at compile time that, upon success, its resource should be marked as clean).
I’m not sure that _every_ use case is known at compile time… for instance, an undo operation.
> [@tj.corona](#):
>
> Couldn’t we inspect the “created”, “modified” and “expunged” components and simply mark their resources as dirty?
Are expunged components guaranteed able to provide a pointer to their resource? Model entities can, but others?
---
### Author:  [@tj.corona](https://discourse.kitware.com/u/tj.corona)
#### Post date: [October 29, 2018, 1:31pm UTC](https://discourse.kitware.com/t/smtk-cmb-release-to-do/166/6 "2018-10-29T13:31:43Z")
> > I think this was better than the above method, but it still made use of run-time “properties” to describe information that is known at compile time (the Write operation knows at compile time that, upon success, its resource should be marked as clean).
> I’m not sure that _every_ use case is known at compile time… for instance, an undo operation.
The fact that a resource may be clean or dirty is what is known at compile time. Run-time information is better suited to _definitions_ that are unknown at compile time (e.g. a VTK model marked as for use by simulation A or simulation B).
> > Couldn’t we inspect the “created”, “modified” and “expunged” components and simply mark their resources as dirty?
> Are expunged components guaranteed able to provide a pointer to their resource? Model entities can, but others?
That’s a good point. Expunged components are a tricky and outstanding piece to consider.