And you shouldn’t name your files “.DS_Store” either .
No, what I meant, was, that Git in general works fine with dot files. (Not counting “reserved” file names.)
Anyway, _.SomeMacro is perfect! I don’t see any conflicts ATM. But, as said, it’s not a problem to rename those macros either. [1] So don’t waste much time on that. (Probably nobody else has macros with a leading dot in the name.)
[1] It’s just a group of macros where the macros are named according to the dot-config file they are supposed to open.
###Feedback on Importing from Repository
* **First, it worked** for the one test I did.
* In your instructions, you state:
"A Macro will get pasted into whatever group you have selected."
• But when I select a Group and trigger the Paster, I get this error:
* <img src="/uploads/default/original/2X/f/feee8b070ca190d2d2ec375d727650e0fac244a3.png" width="537" height="156">
* So, I'd suggest that you **refine your instructions a bit,** or better, allow either the Group, or a Macro in a Group, to be selected.
* **Allow the JSON file to be directly imported** from a Finder selection.
* Allow multiple files to be selected
* **If the Macro Name is a dup**, add a number to the end like the Finder does dup files. Actually, I'd prefer you add " [DUP 1]" etc.
* **Provide Option to Replace Existing Macro**, keep the original UUID
* I think this is very important for scripts and URLs that execute the macro by its UUID
These are just my thoughts, my feedback. I realize your Macro is in Beta, so feel free to use or ignore this as you see fit.
**Overall, looks like a great start on a Macro Repository system.**
Many thanks for the great idea, great design, and for sharing.
Dan, I just want to confirm my understanding of how the Updater works AFTER the initial run.
Please confirm or correct these:
Only Macros revised since last run of Updater are actually exported to JSON, and the Repository file is replaced.
It appears that all of the JSON files for Groups are updated in the Repository, regardless of whether or not any changes were actually make to the Group in KM.
Based on all of the date/time stamps for these files.
I just wanted to share my naming of Dan's macros, for those that might be interested. Each of us have our own style and preference, and this reflects mine.
Only Macros revised since last run of Updater are actually exported to JSON, and the Repository file is replaced.
Correct. Based on the macro's Updated Date.
It appears that all of the JSON files for Groups are updated in the Repository, regardless of whether or not any changes were actually made to the Group in KM.
Correct. I'll change this to match the Group's behavior.
Regarding what you have to have selected in order to paste: Let me do some research on this. I thought this was what the KM Editor required, but I just did a test, and now I'm not sure. So let me get back to you on this one.
As for the rest of the import process, I just haven't gotten far enough to do anything else. Thanks for the feedback, and I'll get back to you on it.
I totally appreciate your help with this. And I want it to work correctly, so I’ll continue working on that.
But I doubt I’ll be doing much, if any, more work on the pasting/importing process. Most everything beyond what I’ve already done is a lot more work than you might initially realize.
However, I’m perfectly fine with someone else working on that part. The only issue is, you’ll have to use at least some of my JXA code, because of how I handle “CustomIconData” and “StyledText” (not to mention JSON). Although now that I think of it, the Data issue is really just a few regex search-and-replaces, so perhaps AppleScript isn’t out of the question either.
I can provide any details necessary. I’m also not against my doing some coding - I just don’t want to do all the work to figure everything out. It makes my head spin.
By the way, if you look at any of my JXA code in Atom, the first thing you want to do is “Edit->Folding->Fold Level 2”. This gives you something much easier to digest, and you can more easily focus on the areas you’re interested in. And remember to start at the bottom.
At the moment, after multiple test runs, the macro works perfectly for me. Also works nicely with Git! Getting back a reversed change from the repo into KM is also very easy and well working.
Many thanks for your work, Dan. Really appreciated!
However, the macro has made me aware that the first thing I have to do in the next days, is rigidly clearing out my macro collection Huge amounts of very old, unfinished, temporary test macros…
However, the macro has made me aware that the first thing I have to do in the next days, is rigidly clearing out my macro collection Huge amounts of very old, unfinished, temporary test macros…
OMG, don't even start! LOL. Me too, obviously. Also, I'd love to clean up all the variables I have hanging around. Sigh. It'll probably never happen...
Hey guys, just found a bug. The macro will fail if you’ve renamed a group. It worked OK once, then I made a change and must have forgotten to test it again.
Are you doing that in the code somewhere? Because I don't see a filter action doing it.
Other Comments:
I had a group named Mail.app that was turned into a package in the Finder.
I just renamed it to “Mail (Apple)”, although I'm not certain this would matter a bit to Git.
It would be nice if once the first dupe-error was thrown you'd complete the scan and provide a list of all dupes at once.
I had a number of duplicate names and had to run the whole macro x-many times to root them all out. (Inexpert users are quite likely to get frustrated and quit.)
A legit use of a duplicate names is for the same macro with different triggers.
While multiple triggers can be added to a single macro, they won't show up as multiple buttons in a palette.
I have solved this for the present by appending either 1, 2, … or a, b, … The look is not as clean, but it works.
It would be nice if the “Finished” dialog responded to the “OK” button, although this is not a big deal – since it will respond to “Esc”.
I had a group named Mail.app that was turned into a package in the Finder.
Interesting. It makes sense, actually, because a package is just a folder anyway. I agree that it wouldn't matter to Git. Do you have any ideas how to handle this?
It would be nice if once the first dupe-error was thrown you'd complete the scan and provide a list of all dupes at once.
Sounds like a good idea.
A legit use of a duplicate names is for the same macro with different triggers.
How about using different prefix numbers? They don't show up in the palette, right?
It would be nice if the “Finished” dialog responded to the “OK” button, although this is not a big deal – since it will respond to “Esc”.