[Openmcl-devel] default directory

[Joakim Sandgren]

thank you for your thoughts!!
it's exactly that.
I am hesitating starting with the cocoa bridge and my own bad hacking  
functions to give me the visualizing windows I need in my composition  
environment...
but if there will be a "better" or more lisp-y set of functions for  
cocoa windows in ccl this will be much better and probably worth  
waiting for.

I do know a little of cocoa, I wrote 1 or 2 years ago a small  
visualizer app that showed spectrums read from a text file with a  
certain format from a Ircam app called audiosculpt. but thats all. and  
it was before obj-c 2.0 with garbage so I had to figure out the object  
counting as well. not fun. But after all I "love" cocoa but I need  
more time with it. (much more time).

So, for the ccl development then, I wait a little more? for the window  
functions? I mean, I am still composing on my old power book G4 PPC in  
MCL 5.2 final 3 (from clozure) and all of my questions here is about  
porting my environement as soon as possible to the intel macbook pro...
I found a midi package that works. Now the dialogs and directory stuff  
seemes to arrive. And finally the visualizers (I never did edit-able  
windows). In MCL I use find-click-view (or something like that) to  
inspect the object, bound to the view, in the inspector window. it  
would be good to be able to have the same functionality in my future  
clozure ccl windows...

I can click in these fields with cmd, alt, ctrl shift key to have  
different content (like: go to pitch object, go to dynamics object, go  
to top level etc etc)

Sincerely
Joakim




Le 4 mai 09 à 10:19, R. Matthew Emerson a écrit :

>
> On May 3, 2009, at 4:39 PM, Joakim Sandgren wrote:
>
>> it seems to me that easygui is a package that is made a little ad  
>> hoc, "for now", to resolve urgent needs now. and the gui package is  
>> part of the "real" cocoa communication in clozure ccl...
>> and perhaps in a future better version the easygui will be obsolete  
>> but the gui package not...
>>
>> I am of course still waiting for some window functions in ccl, and  
>> for the moment being I dont know on wich horse I should bet...
>
> At the moment, I find that I am more-or-less writing Objective-C  
> code in Lisp.  That is to say, I'm just using the Objective-C bridge  
> directly.  On the one hand, this is not so bad:  it's certainly  
> handy to be able to add and redefine Objective-C methods on-the-fly,  
> and so forth.  In some ways, it even feels pretty high-level.  After  
> a while you become desensitized to the  #/callSomeMethod syntax and  
> forget that you're calling foreign code (at least until you screw up  
> and crash the lisp).
>
> On the other hand, you really need to know Cocoa pretty well in  
> order to work like this.  You have to understand various Cocoa  
> conventions like naming, memory management, the model-view- 
> controller pattern (ugh, I said "pattern"), threading issues, etc.
>
> I think we do need some sort of CLOS-y interface to Cocoa that  
> abstracts out the need to worry about running stuff on the proper  
> thread, takes care of appropriately retaining and releasing  
> Objective-C objects, does something about the lisp string to  
> NSString hassle, and so on.
>
> Easy GUI is an experiment in that direction.  I am not using Easy  
> GUI when developing code for the IDE, but I do hope that as we all  
> get more experience programming Cocoa in CCL, we'll be able to  
> identify and implement good abstractions for various aspects of  
> Cocoa and put that code somewhere, whether that be Easy GUI or  
> somewhere else.
>




Joakim Sandgren
joakim sandgren musik
42, rue de Maubeuge
75009 Paris
France
+33 (0)1 45 26 43 90
info at joakimsandgren.com
http://www.joakimsandgren.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20090504/b6d5742a/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pastedGraphic.tiff
Type: image/tiff
Size: 3139354 bytes
Desc: not available
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20090504/b6d5742a/attachment.tiff>