[Openmcl-devel] CocoaInterface Code

[Paul Krueger]

On Jul 18, 2017, at 1:18 AM, Toomas Altosaar <toomas.altosaar at fi.abb.com> wrote:
> 
> What is the reason why it isn't distributed with ccl?
> 
>> On 18 Jul 2017, at 1.14, Paul Krueger <plkrueger at comcast.net> wrote:
>> 
>> Since I pop off every now and then about my Cocoa user interface contrib code and since it is no longer distributed with CCL (a good decision, I’m not complaining), I decided to make it available on Github. 
>>   https://github.com/plkrueger/CocoaInterface/
>> 
>> I reorganized the code into a somewhat more coherent form, tested everything with the version of CCL that is downloadable from the Apple App Store on Mac OS X Version 10.11.6 (El Capitan). In the process I fixed a bunch of errors that cropped up since the last time I did any real testing about 4 years ago and made a few improvements as well. I made a pass through most of the documentation and updated it as needed.
>> 
>> If you try it and encounter any problems, please let me know.
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> https://lists.clozure.com/mailman/listinfo/openmcl-devel

It has to do with how the CCL code is now distributed. Below is Matthew Emerson’s previous response to this question and I agree with his response. I no longer worry about getting in changes in order to make the next CCL release cycle (not that I’ve done much of that recently). I suppose the downside is that some users won’t know how to find my contrib code or understand exactly how to get it, but developing Cocoa interfaces is complex enough in its own right that learning how to use Github will be a relatively small hurdle for anyone who wants to take on that task. It might be nice if the Clozure web site kept a list of links to various contrib distributions to make it a little easier for CCL users to find them.

> 
> On Feb 13, 2017, at 10:22 AM, Paul Krueger <plkrueger at comcast.net> wrote:
> 
> Any thoughts on how you might want to handle contrib code going forward? That might make a difference to me on when/whether I convert over to GH.

Here's what I think, for what it's worth...

In the past, it wasn't straightforward to host source repositories on one's own.  Since the CCL project was already handling the project hosting chores, I think it made sense to make part of the CCL repository available for user contributions.

These days, project hosting services are common: GitHub, Bitbucket, GitLab, and more.  That being so, I think that it's better for non-core CCL code to be in its own repository, owned by by its author.