[Openmcl-devel] Events, Windows, and OpenMCL

[Brent Fulgham]

One last question for the night:

Is there an easy way to test that the "windowRef" returned for a  
Cocoa window is valid?  According to "http://developer.apple.com/ 
documentation/Cocoa/Conceptual/CarbonCocoaDoc/Articles/ 
CarbonCocoaComm.html" the windowref in a Cocoa application should be  
a valid Carbon reference.  However, this doesn't seem to work.

If I do something like:
?(require 'cocoa)

... lots of stuff ...

? (defvar *A* (ccl::new-cocoa-window))
*A*
? (defvar *B* (ccl::send *A* 'window-ref))
*B*
? *A*
#<NS-WINDOW <NSWindow: 0x3a6cb0> (#x3A6CB0)>
? *B*
#<NS-OBJECT <NSCFType: 0x3ad950> (#x3AD950)>
? (defvar *C* (ccl::%get-ptr *B*))
*C*
? *C*
#<A Mac Pointer #xA07C35C0>

I don't think the NS-OBJECT returned is what I want, because calling  
various Carbon-based things don't seem to do anything.

? (#_HideWindow *C*)
NIL

Does not hide the window.

? (#_MoveWindow *C* 100 200)

Does not move the window.

Thanks,

-Brent



On Dec 10, 2006, at 11:56 PM, Gary Byers wrote:

>
>
> On Sun, 10 Dec 2006, Brent Fulgham wrote:
>
>> Speaking of the Cocoa bindings:
>>
>> 1.  Do all child classes of things derived from NS:NS-OBJECT have  
>> to be declared as members of the NS:+NS-OBJECT meta-class?
>
> Yes.  There are two axes involved when one defines a class:
>
> 1) one describes inheritance relationships that apply to instances.
> A BINARY-FILE-STREAM is a FILE-STREAM and therefore also a STREAM.
> The superclasses specified in a DEFCLASS form specify these
> relationships.
>
> 2) the other - not used as often - describes inheritance relationships
> that apply to the class itself.  In most cases, CLASS objects are
> just "instances of the class whose name is STANDARD-CLASS"; when
> defining an ObjC class, we want the class object to something that
> the ObjC runtime can use directly.
>
> In contrast to CLOS classes (which usually inherit from one of
> a small number of CLASS metaobjects), ObjC classes typically
> have their own unique metaclasses, but this unique metaclass
> is usually created at the same time that the class object is.
> Using (:metaclass ns:+ns-object) is kind of a hack to work
> around the fact that the -real- metaclass doesn't exist yet.
>
> The AMOP says that the :METACLASS option to ENSURE-CLASS defaults to
> STANDARD-CLASS.  It might arguably have been better to make it default
> to something based on the metaclasses of the superclass arguments
> or something, though that may be harder to do in general than it
> might seem at first clance.  (The :metaclass option already controls
> how the superclasses default, so there's a slippery slope there.)
>
>>
>> 2.  Is there any reason the "Cocoa" framework (which works quite  
>> nicely for creating windows from the console) is still part of  
>> "examples", rather than part of the main system image?  It's  
>> really quite nice.
>
> It started out as an example, and not enough work has been done on it
> in the last few years to really justify moving it elsewhere.  (This is
> of course circular, since some of the work that needs to be done is to
> simply move it elsewhere.)
>
> Over much of that few years of underactivity, I've said "I hope that
> it'll soon be possible to move forward with both the bridge/framework
> and the proof-of-concept-but-not-too-usable demo IDE."  Rather than
> repeat that, I think that I'd rather say:
>
> 1) Clozure refuses to be held legally responsible for any unfortunate
>    breath- holding incidents.  (E.g., don't hold your breath.)  But
>
> 2) Stay tuned.
>
>>
>> Thanks,
>>
>> -Brent
>>