@ShaneStanley, have you considered maintaining Dialog Toolkit on GitHub?
Seems like this would make it easier for people to fork for their own version, and then for you to update the master when appropriate.
And, make it easy for all of us DT users to always get the latest, or alternate, versions.
I haven’t considered it seriously, no. I don’t think GitHub is very good for AppleScript stuff because it’s compiled, and I don’t think most scripters are familiar with it.
Shane, I urge you to reconsider it. It is a very well known system for open source software.
For the AppleScript users who are not familiar with it, it will have no impact.
But for those few that want to improve/enhance DT, it is a great system, and, I’d guess, that most like likely these few are familiar with it.
Currently we have at least two users who have enhanced DT, yet we have no way of accessing their enhancements.
I think the ROI is very high.
Regarding “not very good because compiled”, I don’t think there are good reasons to not use text (.applescript) for sharing code on such sites. Developers do a checkout, open in their AS editor of choice, develop, test, and when they commit, the commit the text, and not the compiled version.
There is plenty of applescript code on Github and equivalents. Good quality code hosted in such places would have a non-trivial impact.
Can you point me to an example where the code relies on an .sdef file for its terminology?
Pretty much all non trivial applescript code relies on some .sdef or another doesn’t it ?
Um, no. I think you’re misunderstanding – I mean having its own .sdef.
I was only half misunderstanding. What I am not understanding is if you can build the thing on your side supposedly from non compiled code, how is it a problem to host that non compiled code and let others build all the elements required to run it?
Give it a try, and see how it goes.
I don’t want to go on about this — there are other reasons I really don’t want to go down the GitHub path.