[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sc-dev] CocoaBridge bug

Hi Jan,

probably, because since Ryan's excellent CocoaCollider < http://
www.wabdo.com/CocoaCollider/index.html >
there wasn't any further development of the CocoaBridge.

I know CocoaCollider, it is very nice i agree, but i do not use it. Full binding is nice if you use extensively ObjC, but <humble opinion> it has also an overhead. I tend to prefer the light approach of CocoaBridge for managing small additions to sc using Objc/Cocoa : it is effective and the invocation mechanism is the same.

Probably it
should be removed.

I understand perfectly from the CocoaCollider point of view. Ryan's work is the perfect addition for using a full-option Cocoa with SC. But, <still a personal user view>, i don't want to have two applications for one purpose. SuperCollider development is constantly changing. I prefer to have one application. For exemple, if i want to draw an NSImage with SuperCollider, i will prefer CocoaBridge, i won't use CocoaCollider for a simple addition. (or i can choose SwingOSC wich offers also a java alternative for GUIs and do not need to have a 'different' sc application). As a second exemple, for testing for small projects i modified the CocoaBridge, so it can accept Class methods and do simple automatic conversions (along with the doesNotUnderstand method in sc you can create nice Proxies) and i still had a light and transparent approach that suited my needs...But of course that's my point of view. I do not know if you fully understand me but i really think CocoaBridge is a very nice alternative, wich keeps the transparent/ decoupled aspect of distributed/remote messaging.

Thanks a lot for your response and attention Jan