[mac-lisp-ide] Moving forward...

[Duncan Rose]

On Tuesday, February 10, 2004, at 08:36 PM, mikel evins wrote:

>
> On Feb 10, 2004, at 12:29 PM, Timothy Moore wrote:
>
>> On Feb 10, 2004, at 9:24 PM, mikel evins wrote:
>>>
>>
>>> The current name of the Backend is "Cocoa", but that's probably not 
>>> right. For one thing, it's OpenMCL-specific; what if you get an 
>>> SBCL-based Cocoa Backend working, for example? I'd be interested in 
>>> hearing people's naming suggestions before we go committing a new 
>>> directory to McCLIM.
>>>
>> If a SBCL-based Cocoa backend appeared I'd really hope, in fact I 
>> would insist, that it share code with an OpenMCL backend unless some 
>> issue made that  completely impossible. I don't think we need to 
>> worry about other Cocoa backends showing up any time soon :), but you 
>> could call it "MetaCocoa" or something.
>>

The current Cocoa back end shares a lot of code with the CLX back end - 
how much code can be shared above and beyond this depends on how an 
SBCL (or CMUCL now that's getting to work on OS X, or indeed a non-Free 
implementation) Cocoa interface might look; at the moment there's CCL:: 
peppered liberally over the code. I did initially start to put all the 
FFI methods into a separate source file and it might be worthwhile 
going back to that. My priority at the moment is to get it all working 
(obviously!) so I'm not really thinking about decent code separation 
currently.

I'm intending on putting in a whole bunch more code when what's already 
there works "well enough" - at the moment I'm implementing the "McCLIM 
standard" look and feel and I want to implement a "Cocoa native" 
environment. I suspect much of the code will naturally separate out 
when I add this "Cocoa native" frame manager (I think this would not be 
straightforward to do with the code in its current state. I might be 
wrong about this though).

Hopefully things will be clearer in another week.

-Duncan



>
> If nobody objects then I guess we can check it in as "Cocoa", on the 
> understanding that code for future support of alternative lisps may 
> require some reorganization (I always wince when I think about 
> reorganizing directories in cvs).
>
> --me
>
>
> _______________________________________________
> mac-lisp-ide site list
> mac-lisp-ide at common-lisp.net
> http://common-lisp.net/mailman/listinfo/mac-lisp-ide
>