After a class of shapes can be separated in states, the next step is to create custom commands. As of today most work was focused for common cases like resolving automatically with minimum setup old actions to the new code.The new actions work as you fill states and you have to write in advance which steps do you need for that action to complete and the current code will try to automatically fill the Inputs and to give the data for the action.
The "old" actions were working by querying application resources (like: OpenCascade's context, OpenCascade's View, mouse clicks) named Inputs. What will happen if an action will need a new resource that was not "invented" at the moment of defining it? It is needed the same solution: an extensible framework to give to that action as Inputs code already exist. So the Inputs are now accessible to any state based action via it's dependency class that is needed to be filled.
I did also worked to the command line parser to create "stages". I use other name just to differentiate with States name. Those stages are for known command line definitions that I will try to fill them tomorrow in the command line. They are mapped to command line states. So if a command line will ask for a double, or integer, the command line may offer that to user.
Small fix: WPF treeview was fixed in filtering part so most probably is functionally equivalent with the old code.