Move CCR and Apps in to user space

[LexiconCode]

Now that Caster is a package in its current limitation isolates the CCR and apps from the user in the Python directory. For some users this is undesirable as they want to directly edit source code to make customizations.

Therefore by default apps and CCR should be copied on first run in to the user space.

A few things for discussion

• This should be toggled in the user settings for those that wish to use filter rules.
• A mechanism to notify users that there's an update to a specific application or CCR?
• This is going to fragment users as requires users to manually update apps complicating support. Should we be include Caster version number to apps and ccr files?

[synkarius]

Not to be pedantic, but we want to copy on first run, not move. Effectively they're moving since the user dir is where they'll run from, but the files will exist in both locations.

[synkarius]

So let's get to the discussion parts of this.

Rule filters: being as we don't have a standard set of these like we have for rules, what would be getting copied to the user dir on first run?

Update notifications: I could design a mechanism for change detection. (Off the top of my head, as we copy the rule files, we also hash them and then write a line to the end of each file setting the hash as the string value of some variable -- then later when we want to compare versions, we compare the new hash to the old hash. You would want to compare to the old hash versus the hash of the old file because user customizations would make the "old" file hash differently than the original.) Detection is easy. The question is, what then? We couldn't just copy the updated file over their changes, and any kind of git merge would be ungodly complex to do correctly. We could also just alert them "rules are available for update" or something like that and then leave it to the user to both (A) go get new changes and (B) update the hash at the end of their file so that Caster would stop nagging them, but IMO, that would be more annoying than helpful.

I think maybe the best approach, at least to start, is the simplest approach: copy the files once and then forget about it unless the user unsets the "has been copied" setting-- in which case, overwrite mercilessly. The assumption here is that everyone customizes, and most people are capable of copy/pasting any special new goodies they like off of Github and into their old rules.

That said, maybe while copying, we add a "version" variable to the end of the file, just for support reference?

[LexiconCode]

Rule filters: I think we should include the rule filters, I had a number of people ask and I had to point them to the files in the master branch. They could use better documentation but having code locally is useful. Personally I don't want this feature to die off. That only because I use it but it has potential to be more than what it is in its current implementation. They could use the same system as app/ccr but not be notified for update.

Update notifications: The hash implementation is sufficient. As part of the notification it could print out the app/ccr names for update that they currently have customized and simply overwrite the ones that they have not without a notification.(Which could be overridden in the settings) I think it would be best to not include the hash information in the files themselves. We could create a hidden file in the user directory for that. Setting for turning off notifications for customized grammars would do nicely.

Yes version information would be invaluable for support.

[synkarius]

Rule filters: Oh, I'm not suggesting killing these off. It's just that the handful that I initially created were just intended as documentation by example, not actual filters to be used. I guess we could preserve those and copy them along if you think it'd be useful. Or, are you thinking that the "starter" set of filters can grow over time into a useful set rather than a bare bones how-to? That I could see being useful.

Update notifications: That way does give maximal flexibility. Alright, I'll do it that way then.

[LexiconCode]

@synkarius I'm thinking as we have more development time those filter rules can evolve into something besides documentation by example. Therefore desire to keep them up-to-date. They'll probably turn into a set of functions that's call on toml files..

[LexiconCode]

Caster 1.0.0 allows the user to move grammars into the user space. From then on the grammar loads from the user space instead of source code. I'm considering this closed. Other related topics such as update notifications can be opened up as a new issue.