Move ccr out of lib, and put asynch in

[mrob95]

I have moved the ccr folder into the main directory, and transferred the asynch folder into lib, as discussed in #325 . Hopefully this gives a cleaner separation between user and non-user space, and moves a step closer to #246 . It was mostly just a ctrl-f job and it seems to be working, but could do with testing to make sure nothing is broken.

I've also done a quick edit on the Go module so that it uses lib.actions instead of Dragonfly, and fixed an erroneous keystroke in the else command.

[LexiconCode]

I'll work on testing this tomorrow.

[Versatilus]

I'm going to try to get to this today. I'll be trying to reconcile it with the synkarius/restructure branch so that it can hopefully all be merged at once. It's still going to take a bit of work to make the transition go more smoothly for end-users.

[LexiconCode]

So far everything works as expected.
Perhaps we should rename core to core...Something?

C:\NatLink\NatLink\MacroSystem\core
Could be easily confused with
E:\NatLink\NatLink\MacroSystem\caster\ccr\core

[mrob95]

Good thought. apps is really the only folder which has a usefully descriptive title.

• core -> basics, core_commands, always_on?
• ccr -> languages?

[LexiconCode]

How about will leave it as core,and break it down into folders
caster_core
programming_languages

This allows us to expand using a folder structure other aspects that we might Integrated the future.
Examples could be Linux, Windows, and Macintosh?

I'm not really sure but it's definitely worth exploring.

[LexiconCode]

On further testing the MouseGrid commands do not work on your branch but do work in the development branch.

[Versatilus]

Even though technically it can all be disabled, I personally like the term essential. It makes sense to me to move /ccr/core to /ccr/essential. If you think it's necessary to change things, I would be in favor of changing ccr by expanding the acronym to continuous_command_recognition or doing it PascalCase as ContinuousCommandRecognition.

I still haven't taken a look at this. I've let my day get a little backed up. I'll try to get to it as soon as I can.

[mrob95]

@LexiconCode Try that, it is working for me now. The problem for me was with the way that the UI launchers find the caster base path - by splitting the full string on "\caster". I had my branch in a folder named "casterfork" so it was splitting on that instead. It should be slightly more picky now.

@Versatilus I agree that big changes like this aren't ideal as they pretty much force people to start afresh and re-implement all of their modifications, so it may be best simply to leave the names as they are. I'm not sure moving the folders around can be avoided though, as any plans to make caster a package or simplify the installation will require a clearer distinction between user space and backend.

[LexiconCode]

Perhaps we should create an issue to track issues that would be considered disruptive to the end-user or breaks in compatibility. I think it would be easier to make these changes all at once rather than incrementally. For now let's not change file names but but we could further discuss it in a new issue.

Fundamentally a lot of our issues come from users editing source code rather than filter rules. This issue will only become more exacerbated when Caster becomes a package.

[LexiconCode]

@LexiconCode Try that, it is working for me now. The problem for me was with the way that the UI launchers find the caster base path - by splitting the full string on "\caster". I had my branch in a folder named "casterfork" so it was splitting on that instead. It should be slightly more picky now.

It works as expected although I had to regenerate settings.toml

Which brings me to an interesting question perhaps. There's a lot of duplicate code to find the default base path. The base Is already contained in settings.toml as BASE_PATH.

[mrob95]

One for another PR I think, it seems to be very easy to break the ui commands inadvertently

[LexiconCode]

Sounds good I'm ready to merge if you considered it complete.

[mrob95]

I'm happy, but I don't know what the best way of reconciling /develop with /restructure is going to be

[Versatilus]

I haven't tried integrating this branch with it yet, but I spent some time this past weekend integrating restructure into develop and made it this far: https://github.com/Versatilus/caster/tree/pr-restructure-reconciliation-20181208. It still needs a bit of polish, including code to make the transition less bumpy. It doesn't automatically transfer your existing settings, but instead re-creates the defaults in the new location. Also, it doesn't really handle the /user directory and its rules.

I have a pretty decent idea in my head of where where I would like to go with this. I'll try to get back into it before this weekend.

Before merging either of these larger projects, I think it might be a good idea to update master. Before that, though, I need to look into a couple of weird behaviors.

[LexiconCode]

I put in a request to @synkarius to release an a new version to master. Once that's done we will proceed with the merger

[Versatilus]

I would prefer not to do that for a few days. I found a weird bug or behavior with the changes to formatting which I need a few days to sort through. I would prefer not to merge into master until I have had a chance to sort it out.

[LexiconCode]

Sounds good!