arbaugh@hqda-ai.UUCP (Bill Arbaugh) (03/18/88)
A couple of things concerning the discussions about lisps for the
mac. Someone mentioned that the ExperCommon Lisp bombed a great
deal. They are correct! That and the fact that it is not a
complete common lisp are the primary reasons I switched to using
Allegro Common Lisp.
Yes, Coral does not support CLOS (PCL). And, it
is rather difficult to learn without examples, although it is
somewhat like Symbolics flavors. The primary benefit of using
CLOS is that I can develope a majority of the application on a
Symbolics or TI Lisp machine and then port it to the mac and only
have to worry about the window conversions.
I do believe that Coral is working on implementing Common
Windows. Intellicorp is pushing for Common Windows to become the
standard window system for Common Lisp because that is what they
used to implement KEE on so many machines. I don't believe that
they are having much luck. As for X windows, I thought I saw
something on comp.windows.x indicating a patch file for CLX for
Allegro Common Lisp. I'm not sure though- and probably only
allows operation as a client. Does anybody know?
The way I creatde a pseudo "application" with allegro is to
write a function, say test, that sets the menubar to the one for my
application, closes the Listener window and selects my
application window. I then continually loop through a function
that controls my application. I think you could use
window-null-event-handler here as well. This must be done because
if the function test returns a new listener window will be made
and exposed. Then at the end of the file containing my
application I add the s-expression (TEST). When the user double
clicks on the application file icon the default menu bar appears for a second
but then is quickly replaced by my own menu bar and window. The
above description worked for my particular application because I
needed to continually apply the same function. I am not sure how
performace will be affected by continually applying, say,
window-null-event-handler. Let me know if you try it.
There are some problems with the above method.
Unfortunately, memory is wasted because we had to load the entire
developement environment. Also, if an error occurs a listener
window will magically appear, or the user can abort test by
clover-. Although I think you can trap that if needed. I didn't
really care enough to look into it.
I hope the above helps or at least points you in the right
direction.
--
==========================================================
Bill Arbaugh Phone: (202) 694-6900
UUCP: *!uunet!cos!hqda-ai!arbaugh ARPA: ai02@hios-pent.arpa
==========================================================ewing@yale.UUCP (ken ewing) (03/23/88)
Expires: Sender: Followup-To: Distribution: In article <1267@hqda-ai.UUCP> arbaugh@hqda-ai.UUCP (Bill Arbaugh) writes: > The way I creatde a pseudo "application" with allegro is to >write a function, say test, that sets the menubar to the one for my >application, closes the Listener window and selects my >application window. I then continually loop through a function >that controls my application. I think you could use >window-null-event-handler here as well. This must be done because >if the function test returns a new listener window will be made >and exposed. Then at the end of the file containing my >application I add the s-expression (TEST). When the user double >clicks on the application file icon the default menu bar appears for a second >but then is quickly replaced by my own menu bar and window. The Instead of trying to keep any listener windows from being created, you need only (ask *top-listener* (window-hide)). No need for a never- returning function at all! >-- >========================================================== >Bill Arbaugh Phone: (202) 694-6900 >UUCP: *!uunet!cos!hqda-ai!arbaugh ARPA: ai02@hios-pent.arpa >========================================================== ken ewing ewing@cs.yale.edu