[Openmcl-devel] Events, Windows, and OpenMCL
bfulg at pacbell.net
Mon Dec 11 03:53:52 EST 2006
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/
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:
... lots of stuff ...
? (defvar *A* (ccl::new-cocoa-window))
? (defvar *B* (ccl::send *A* 'window-ref))
#<NS-WINDOW <NSWindow: 0x3a6cb0> (#x3A6CB0)>
#<NS-OBJECT <NSCFType: 0x3ad950> (#x3AD950)>
? (defvar *C* (ccl::%get-ptr *B*))
#<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*)
Does not hide the window.
? (#_MoveWindow *C* 100 200)
Does not move the window.
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
> 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.
More information about the Openmcl-devel