dictation-toolbox / Caster

Dragonfly-Based Voice Programming and Accessibility Toolkit
https://dictation-toolbox.github.io/Caster/
Other
340 stars 121 forks source link

New Grammars in `const.py` as a default are only Loaded but not Active. #721

Open LexiconCode opened 4 years ago

LexiconCode commented 4 years ago

I discovered something unexpected with how Caster Loads but does not Activate new default rules.

Current Behavior Only when rules.toml is regenerated does does default rules defined in const.py become Loaded and Active.

Desired Behavior I would have expected a new Grammar defined as a default in const.py added to rules.toml to Active and Loaded by default.

Further analysis of code to determine whether or not this is a bug expected behavior. If it is expected worth changing the behavior as described above.

Steps to reproduce

  1. Create a new valid rule for example ExperimentalRule.
  2. Add ExperimentalRule to const.py as a default rule.
  3. Restart Dragon
  4. The ExperimentalRule rule will be loaded not active.
  5. Rule have to be manually enabled by voice for first use.

Explanation ExperimentalRule rule is Loaded but not Active. This is expected behavior for new rules in general not new default rules. Rules defined as defaults in const.py should be Loaded an Active when added to an existing rules.toml file for the first time.

How does the rule become active in the scenario described above?

Assuming the class name is also the name of the rule Experimental Rule will activate the rule.

Debug process Watching rules behavior in rules.toml the following were observed.

_enabled_ordered represents all active grammars. For grammars to be Active they must be Loaded first.

[whitelisted] Whitelist where grammars can be toggled to false to prevent grammars loading. The default is true for all new grammars and they only switch false by end-user intervention.

kendonB commented 4 years ago

I think the use case for this comes in when you want to add a new core Rule? If we are to deal with this, we would have to do it in a way that preserves the ability of users to remove core elements from _enabled_ordered. We would have to also maintain a user-folder file that contains the core rules that have ever been activated?

A simpler option might be to just add another command to the caster rule that refreshes the core elements in _enabled_ordered.

I think this one is low priority as we don't often add or subtract core rules anyway.

LexiconCode commented 4 years ago

I think the use case for this comes in when you want to add a new core Rule?

Correct. It would be active by default when first added. In the event that the user disables it, that preference would be preserved as it does now.

I agree though it is a low priority but could have an issue for the behavior.