Hello all.
I'm quite new to lisp, but over the last year I've become fascinated by
the language, reading several books as well as lurking on these groups.
It seems clear to me that lisp and scheme are far more powerful than any
languages I have programmed in before (c++, java, ruby, basic) but I am
yet to write anything substantial in either. Having now found 'an itch
to scratch', I'd like to start using one of them.
I'm looking to develop some games. The graphics will be fairly simple
(think early pacman or space invaders). I need a language with graphics
capabilities that is free (beer and speech). Would CMUCL with FreeCLIM
be a reasonable approach, or maybe bigloo with the graphics from some C
library?
As for the games themselves, there is an unusual constraint. The
children who will play them have varying degrees of handicap, some may
be only capable of using a simple clicking device, for these the game
will have to be designed so that there is only one type of user event
(i.e. no TURN_LEFT, TURN_RIGHT etc, but just BUTTON_PRESSED. Many of the
children cannot double-click). I've some ideas for games along these
lines, but any other suggestions would be appreciated.
Thanks
Alex
Alex McGuire wrote:
> Hello all.
>
> I'm quite new to lisp, but over the last year I've become fascinated by
> the language, reading several books as well as lurking on these groups.
> It seems clear to me that lisp and scheme are far more powerful than any
> languages I have programmed in before (c++, java, ruby, basic) but I am
> yet to write anything substantial in either. Having now found 'an itch
> to scratch', I'd like to start using one of them.
<pounce> Sounds like you are overdue on my survey:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
</pounce>
>
> I'm looking to develop some games. The graphics will be fairly simple
> (think early pacman or space invaders). I need a language with graphics
> capabilities that is free (beer and speech). Would CMUCL with FreeCLIM
> be a reasonable approach, or maybe bigloo with the graphics from some C
> library?
FreeCLIM? Is that a going concern? I know McCLIM is getting a lot of
attention these days, and the last Lisp-NYC meeting on Tuesday one
attendee was raving about it.
Here are various free graphics projects, of various levels of usability:
http://www.cliki.net/Graphics%20Toolkit
Many rave about Gtk (one of the cliki projects) as a graphics solution
for CL.
Or check the other link in my sig for some rough idea of my Cello (ne
Cellophane) project, which I am trying now to move from win32 onto X11
(which should be easy since I am using Freeglut and that runs under X as
well as win32 (and Apple has their own Glut which I am still
investigating but might be on top of Quartz)).
The only downside is that the imaging layer is OpenGL (for
portability--I guess you need Mesa on Linux?), which is great but can be
challenging to program. But if as it seems you just care about 2D
graphics, it gets a /lot/ easier. And I plan to build a nice little GUI
framework using my Cells technology, which would make your game a lot
easier to develop.
btw, CL can talk to C, ya just have to muddle through some FFI work.
Does bigloo have some special advantage in this regard? Transparent
calls into C? That would be nice.
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> FreeCLIM? Is that a going concern? I know McCLIM is getting a lot of
> attention these days, and the last Lisp-NYC meeting on Tuesday one
> attendee was raving about it.
BOO! :)
I went back and read about some of the stuff people said that
discouraged you from CLIM. I don't know what exactly is wrong with the
lower layers of CLIM after reading that thread. However, the fonts issue
is troublesome. My take on it is that the fonts should be specified by
the user to the toolkit anyway. The option for anything more is gravy,
IMHO, but desirable for many applications.
--
Rahul Jain
Rahul Jain wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>FreeCLIM? Is that a going concern? I know McCLIM is getting a lot of
>>attention these days, and the last Lisp-NYC meeting on Tuesday one
>>attendee was raving about it.
>
>
> BOO! :)
>
> I went back and read about some of the stuff people said that
> discouraged you from CLIM. I don't know what exactly is wrong with the
> lower layers of CLIM after reading that thread.
I had the advantage of knowing the naysayers by (very good) reputation,
and a cursory glance had already left me thinking, "Too complicated." I
also did not see the portability I needed. YMMV.
However, the fonts issue
> is troublesome. My take on it is that the fonts should be specified by
> the user to the toolkit anyway. The option for anything more is gravy,
> IMHO, but desirable for many applications.
I do not recall the CLIM fonts issue. Is it like GLUT, where you have to
prepare some font data file to ship with the lib to provide a given
font, as opposed to loading arbitrary fonts found on a user's system?
I was hoping to add the latter to Glut via wgl/agl/xglUseFont* routines,
but today I discovered that the agl variant is rather limited. Now I am
looking at FTGL on top of Freetype, which would work with TrueType fonts
anyway. FTGL looks like a helluva package, complete with VC++ projects
and Mac OS X ProjectBuilder projects. Internally seems to do great
things interfacing to OpenGL to get the project objective
"commercial-grade" text output. I already built Freetype and FGLT
tonight and ran an FGLT demo tonight in just a couple of hours.
We'll see.
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> I had the advantage of knowing the naysayers by (very good) reputation,
I didn't really see any serious naysayers, FWIW. I'd consider SWM to be
the cannonical expert on CLIM, and he was just saying that the lower
layers weren't as good as the lower layers in DUIM. The higher layers in
CLIM are what application developers really tend to use, and those don't
exist in any other system, AFAIK.
> and a cursory glance had already left me thinking, "Too complicated."
It's layered, not really that complicated at each layer.
> I also did not see the portability I needed. YMMV.
Isn't the best portability the kind that makes you not even notice that
it needs to be done?
> I do not recall the CLIM fonts issue. Is it like GLUT, where you have to
> prepare some font data file to ship with the lib to provide a given
> font, as opposed to loading arbitrary fonts found on a user's system?
No, it's just very difficult to get the exact font you want. The
handling is very abstracted.
> I was hoping to add the latter to Glut via wgl/agl/xglUseFont* routines,
> but today I discovered that the agl variant is rather limited. Now I am
> looking at FTGL on top of Freetype, [...]
Good luck! :)
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Thanks for that. McClim looks well documented, I'll give it a go later
today.
Kenny Tilton wrote:
>
> btw, CL can talk to C, ya just have to muddle through some FFI work.
> Does bigloo have some special advantage in this regard? Transparent
> calls into C? That would be nice.
>
> kt
Calling C from bigloo is as easy as the following. Is it as simple in CL?
$cat add_two_numbers.c
double addTwoNumbers(double x, double y){
return x + y;
}
$bigloo add_two_numbers.c -c
$
$cat example_c_call.scm
(module example_c_call
(extern (add-two-numbers::double (::double ::double) "addTwoNumbers"))
(main start))
(define (start args)
(display (format "~A + ~A = ~A~%" 3.0 4.0 (add-two-numbers 3.0 4.0))))
$
$bigloo example_c_call.scm -c
example_c_call.scm:
$
$bigloo add_two_numbers.o example_c_call.o -o test
$
$./test
3.0 + 4.0 = 7.0
$
Thanks
Alex
Alex McGuire wrote:
> Thanks for that. McClim looks well documented, I'll give it a go later
> today.
OK. I want to warn you that what I heard (before Rahul came along) was
that CLIM was a bitch to learn. And, OK, I perused the doc and I confess
I did not see how to use the damn thing myself. I gathered from what I
saw and had heard that a lot of potential was there, but it just struck
me as a project gone bad.
>
> Kenny Tilton wrote:
>
>>
>> btw, CL can talk to C, ya just have to muddle through some FFI work.
>> Does bigloo have some special advantage in this regard? Transparent
>> calls into C? That would be nice.
>>
>> kt
>
>
> Calling C from bigloo is as easy as the following. Is it as simple in CL?
>
> $cat add_two_numbers.c
>
> double addTwoNumbers(double x, double y){
> return x + y;
> }
>
> $bigloo add_two_numbers.c -c
> $
> $cat example_c_call.scm
> (module example_c_call
> (extern (add-two-numbers::double (::double ::double)
> "addTwoNumbers"))
> (main start))
>
> (define (start args)
> (display (format "~A + ~A = ~A~%" 3.0 4.0 (add-two-numbers 3.0
> 4.0))))
Yes, tho what CLers call an FFI (the extern statement above) is not
standard across languages (but then that is just a hassle for folks like
me trying to develop portable software, and even then there is a very
nice UFFI package that covers many CLs and is educational enough that it
shows one how to tackle CLs not covered. CMUCL is in there, IIRC).
Anyway, CL folks call C libs (such as OpenGL) all the time using the
FFI. And in CL we load libs dynamically (tho I suppose you could build
your own CMUCL and link it against some other lib at the same time, but
I just made that up so don't bet on it).
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> wrote:
+---------------
| Anyway, CL folks call C libs (such as OpenGL) all the time using the
| FFI. And in CL we load libs dynamically (tho I suppose you could build
| your own CMUCL and link it against some other lib at the same time, but
| I just made that up so don't bet on it).
+---------------
If you don't want to build special images for every possible combination
of FFI code you might use, what you can also do that works on a standard
image (at least on FreeBSD, Linux, and several others) and that I find
much more convenient than CMUCL's LOAD-FOREIGN (which always fork/execs
the Unix linker as a child process!) is to separately pre-compile/load
your C code as a ".so" (DSO) sharable library (using the same flags the
linker that's run by LOAD-FOREIGN would use for your platform), and use
the internal routine SYSTEM::LOAD-OBJECT-FILE to do the "dlopen()". Just
remember to ensure that the DSO is loaded *both* in the compiler image
when compiling files that ALIEN:DEF-ALIEN-ROUTINE functions in that DSO,
*and* at run time before any of those routines are called.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
[following up to comp.lang.lisp only]
Kenny Tilton writes:
> OK. I want to warn you that what I heard (before Rahul came along) was
> that CLIM was a bitch to learn. And, OK, I perused the doc and I
> confess I did not see how to use the damn thing myself. I gathered
Yes, it does take time. It took me several iterations of
documentation/sample code reading to maybe understand CLIM. I'm still
not fluent in all of it yet, but I think that I am beginning to see
the light.
I encourage everybody interested in learning or using CLIM to
subscribe to the CLIM mailing list (clim AT bbn DOT com). Traffic is
"very low" these days--i.e. absent--but I think several experts still
lurk there. If you don't get from that list the information you need,
I think comp.lang.lisp is another appropriate forum.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
>>>>> "Paolo" == Paolo Amoroso <·······@mclink.it> writes:
Paolo> [following up to comp.lang.lisp only] Kenny Tilton writes:
>> OK. I want to warn you that what I heard (before Rahul came along)
>> was that CLIM was a bitch to learn. And, OK, I perused the doc and I
>> confess I did not see how to use the damn thing myself. I gathered
Paolo> Yes, it does take time. It took me several iterations of
Paolo> documentation/sample code reading to maybe understand CLIM. I'm
Paolo> still not fluent in all of it yet, but I think that I am
Paolo> beginning to see the light.
Paolo> I encourage everybody interested in learning or using CLIM to
Paolo> subscribe to the CLIM mailing list (clim AT bbn DOT
Paolo> com). Traffic is "very low" these days--i.e. absent--but I think
Paolo> several experts still lurk there. If you don't get from that
Paolo> list the information you need, I think comp.lang.lisp is another
Paolo> appropriate forum.
Are there plans to implement a Gtk backend for McCLIM, or integrate Gtk
widgets in other ways?
--J.
Jan Rychter writes:
> Are there plans to implement a Gtk backend for McCLIM, or integrate Gtk
> widgets in other ways?
None that I have heard of. The only currently available McCLIM
backends are for CLX, PostScript and OpenGL (not recently tested).
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
On Fri, 12 Dec 2003 09:35:03 +0100, Alex McGuire <····@alexmcguire.com> wrote:
> Calling C from bigloo is as easy as the following. Is it as simple
> in CL?
Yes - see below. With the added benefit that, thanks to UFFI, this
code will work in at least six different Common Lisp
implementations. UFFI is at <http://uffi.b9.com/>.
Edi.
···@bird:/tmp > cat add_two_numbers.c
double addTwoNumbers (double x, double y) {
return x + y;
}
···@bird:/tmp > gcc -fPIC -c add_two_numbers.c
···@bird:/tmp > ld -shared add_two_numbers.o -o add_two_numbers.so
···@bird:/tmp > cmucl
; Loading #p"/home/edi/.cmucl-init".
CMU Common Lisp 18e, running on bird.agharta.de
With core: /usr/local/lib/cmucl/lib/lisp.core
Dumped on: Thu, 2003-04-03 15:47:12+02:00 on orion
Send questions and bug reports to your local CMUCL maintainer,
or see <http://www.cons.org/cmucl/support.html>.
Loaded subsystems:
Python 1.1, target Intel x86
CLOS 18e (based on PCL September 16 92 PCL (f))
* (asdf:oos 'asdf:load-op :uffi)
; loading system definition from /usr/local/lisp/Registry/uffi.asd into
; #<The ASDF1017 package, 0/9 internal, 0/9 external>
; registering #<SYSTEM UFFI {48512EB5}> as UFFI
NIL
* (uffi:load-foreign-library "add_two_numbers.so" :module "foo")
T
* (uffi:def-function ("addTwoNumbers" add-two-numbers)
((x :double)
(y :double))
:returning :double
:module "foo")
ADD-TWO-NUMBERS
* (format nil "~A + ~A = ~A" 3.0d0 4.0d0 (add-two-numbers 3.0d0 4.0d0))
"3.0d0 + 4.0d0 = 7.0d0"
Alex McGuire wrote:
> Thanks for that. McClim looks well documented, I'll give it a go later
> today.
>
> Kenny Tilton wrote:
>
>>
>> btw, CL can talk to C, ya just have to muddle through some FFI work.
>> Does bigloo have some special advantage in this regard? Transparent
>> calls into C? That would be nice.
>>
>> kt
>
>
> Calling C from bigloo is as easy as the following. Is it as simple in CL?
Which CL implementation? Your question contains a run-time type error,
as you are comparing the implementation of the bigloo language (no, it
ain't Scheme anymore) to a language (Common Lisp). It is as if you were
trying to do
(+ 3 "4")
or
(compare "apple" 'orange)
Cheers
--
Marco
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Which CL implementation? Your question contains a run-time type
> error, as you are comparing the implementation of the bigloo language
> (no, it ain't Scheme anymore) to a language (Common Lisp). It is as
> if you were trying to do
>
> (+ 3 "4")
I wrote a couple of functions to do (english:+ "twenty two" "ten"
"seven" "three") and to get "forty two". So I'm not afraid of your:
(+ 3 "4") at all!
> or
>
> (compare "apple" 'orange)
[49]> (string< "APPLE" 'orange)
0
[50]> (string< "APPLE" 'ananas)
NIL
[51]>
--
__Pascal_Bourguignon__ . * * . * .* .
http://www.informatimago.com/ . * . .*
There is no worse tyranny than to force * . . /\ () . *
a man to pay for what he does not . . / .\ . * .
want merely because you think it .*. / * \ . .
would be good for him. -- Robert Heinlein . /* o \ .
http://www.theadvocates.org/ * '''||''' .
SCO Spam-magnet: ··········@sco.com ******************
Marco Antoniotti wrote:
>> Kenny Tilton wrote:
>>
>>>
>>> btw, CL can talk to C, ya just have to muddle through some FFI work.
>>> Does bigloo have some special advantage in this regard? Transparent
>>> calls into C? That would be nice.
>>>
>>> kt
>>
>>
>>
>> Calling C from bigloo is as easy as the following. Is it as simple in CL?
>
>
> Which CL implementation? Your question contains a run-time type error,
> as you are comparing the implementation of the bigloo language (no, it
> ain't Scheme anymore) to a language (Common Lisp). It is as if you were
> trying to do
>
> (+ 3 "4")
>
> or
>
> (compare "apple" 'orange)
>
Is interfacing with C very different in each CL implementaton? If not
then surely what I'm trying to do is
(compare "apple" "lots of fruit that are quite similar to apples")
:-)
Alex
Alex McGuire wrote:
> Marco Antoniotti wrote:
>
>>> Kenny Tilton wrote:
>>>
>>>>
>>>> btw, CL can talk to C, ya just have to muddle through some FFI work.
>>>> Does bigloo have some special advantage in this regard? Transparent
>>>> calls into C? That would be nice.
>>>>
>>>> kt
>>>
>>>
>>>
>>>
>>> Calling C from bigloo is as easy as the following. Is it as simple in
>>> CL?
>>
>>
>>
>> Which CL implementation? Your question contains a run-time type
>> error, as you are comparing the implementation of the bigloo language
>> (no, it ain't Scheme anymore) to a language (Common Lisp). It is as
>> if you were trying to do
>>
>> (+ 3 "4")
>>
>> or
>>
>> (compare "apple" 'orange)
>>
>
> Is interfacing with C very different in each CL implementaton?
As much different as between two different bigloo implementations :)
oooops: there's only one. :)
You want to have a look at UFFI. That will give you a lot of mileage.
Cheers
--
Marco
Kenny Tilton wrote:
> <pounce> Sounds like you are overdue on my survey:
>
> http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
>
> </pounce>
Yeah, I tried that, couldn't get it to work, when I saved I got this
*Internal Server Error
*
*Was asked for URL http://alu.cliki.net/edit/Alex%20McGuire , but it
*didn't happen for us. Sorry
No doubt I'm doing something wrong.
Alex
Alex McGuire <····@alexmcguire.com> writes:
> Kenny Tilton wrote:
>> <pounce> Sounds like you are overdue on my survey:
>> http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
>> </pounce>
>
> Yeah, I tried that, couldn't get it to work, when I saved I got this
>
> *Internal Server Error
> *
> *Was asked for URL http://alu.cliki.net/edit/Alex%20McGuire , but it
> *didn't happen for us. Sorry
>
> No doubt I'm doing something wrong.
No, you're not. The cliki sites are currently read-only, as was
announced here and elsewhere, because some idiot thought that defacing
a world-writeable website was a test of (presumably) virility.
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Alex McGuire wrote:
> Kenny Tilton wrote:
>
>> <pounce> Sounds like you are overdue on my survey:
>>
>> http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
>>
>> </pounce>
>
>
> Yeah, I tried that, couldn't get it to work, when I saved I got this
>
> *Internal Server Error
> *
> *Was asked for URL http://alu.cliki.net/edit/Alex%20McGuire , but it
> *didn't happen for us. Sorry
>
> No doubt I'm doing something wrong.
>
> Alex
>
You're not. CLiki is temporary read-only, cause it was vandalised
lately by some great H4X0R, no doubt. ;)
--
Ivan Toshkov
email: ··········@last-name.org
[following up to comp.lang.lisp only]
Kenny Tilton writes:
> FreeCLIM? Is that a going concern? I know McCLIM is getting a lot of
> attention these days, and the last Lisp-NYC meeting on Tuesday one
FreeCLIM is just an early name for the same McCLIM project.
> attendee was raving about it.
I rave about it too :)
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Alex McGuire wrote:
>
> I'm looking to develop some games. The graphics will be fairly simple
> (think early pacman or space invaders). I need a language with graphics
> capabilities that is free (beer and speech). Would CMUCL with FreeCLIM
> be a reasonable approach, or maybe bigloo with the graphics from some C
> library?
>
>
I'd suggest investigating CMUCL with CL-SDL for games -
http://cl-sdl.sourceforge.net/
CL-SDL includes OpenGL bindings more than adequate for most stuff,
and IMHO SDL is a bit nicer than GLUT. OpenGL is actually quite nice for 2D
games - just use a constant z-coord, and textured polygons as sprites -
see open-source games like "Chromium".
Translation of most SDL+OpenGL C examples into Lisp should be pretty
obvious if you know a bit of both C and Lisp, so you should be up and
running pretty quickly, and CL-SDL comes with a few of the earlier
NeHe tutorials translated into lisp.
I've been toying with CL-SDL myself recently with a view to maybe writing a
game, but real-world concerns keep distracting me so I'll probably never
get anything done. As usual. :-)
There's something to be aware of: most forms of garbage collection can make
games intermittently jerky. I've stopped noticing such things on my shiny
2GHz box, so it's probably much less of a concern than in the past - if you
code reasonably carefully (avoid overenthusiastic consing) and have a >1GHz
PC, any gc jerkiness is probably not worth worrying about IMHO, if it's
perceptible, users will probably put it down to the 3d-accel glitches
they're used to anyway. If it really annoys you, you can assume control of
the GC and decide when the jerks are acceptable - but beware runaway
memory usage, then.
David Golden wrote:
> Alex McGuire wrote:
>
>
>>I'm looking to develop some games. The graphics will be fairly simple
>>(think early pacman or space invaders). I need a language with graphics
>>capabilities that is free (beer and speech). Would CMUCL with FreeCLIM
>>be a reasonable approach, or maybe bigloo with the graphics from some C
>>library?
>>
>>
>
>
> I'd suggest investigating CMUCL with CL-SDL for games -
> http://cl-sdl.sourceforge.net/
Ah, yes, I forgot that one, which is dopey because I actually got my
start in CL->FFI->OpenGL playing with that.
The only drawback I can think of is the one-window limitation, which
would not be a problem for game development.
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton wrote:
> The only drawback I can think of is the one-window limitation, which
> would not be a problem for game development.
>
Indeed. I should have qualified my SDL vs. GLUT comment with
"SDL is a bit nicer _for games_" - it does stuff you want as a game
programmer, does the stuff simply (like it says), and not much else.
David Golden wrote:
>>
> I'd suggest investigating CMUCL with CL-SDL for games -
> http://cl-sdl.sourceforge.net/
Thanks for the tip. I've now tried it and it seems perfect for what I need.
cheers,
Alex
Alex McGuire <····@alexmcguire.com> aspired:
> I'm looking to develop some games. The graphics will be
> fairly simple (think early pacman or space invaders). I
> need a language with graphics capabilities that is free
> (beer and speech).
Take a look at:
http://www.kuro5hin.org/story/2003/8/29/72710/3408
a whack-a-mole game using CMUCL and CLX
Your might be discouraged because the game very crude, or you
might be encouraged because I lack experience in both CMUCL
and CLX, yet still produced a game able to amuse for nearly
as long as it takes to download.
I've been writing up my learning experience with CLX in
http://www.cawtech.demon.co.uk/examples.txt
which is structured as simple examples of CLX programming to
help others get started too.
Alan Crowe <····@cawtech.freeserve.co.uk> writes:
> Alex McGuire <····@alexmcguire.com> aspired:
> > I'm looking to develop some games. The graphics will be
> > fairly simple (think early pacman or space invaders). I
> > need a language with graphics capabilities that is free
> > (beer and speech).
>
> Take a look at:
>
> http://www.kuro5hin.org/story/2003/8/29/72710/3408
>
> a whack-a-mole game using CMUCL and CLX
I can report that it runs under Allegro 6.2 on GNU/Linux to.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Alan Crowe <····@cawtech.freeserve.co.uk> wrote:
+---------------
| I've been writing up my learning experience with CLX in
| http://www.cawtech.demon.co.uk/examples.txt
| which is structured as simple examples of CLX programming to
| help others get started too.
+---------------
Nice introduction! One thing you might want to add, though, in the
section on CREATE-WINDOW, where you say:
You have to say where you want it, even though, as a top level
window, the window manager will intervene and put it where it
thinks best. The window manager can also overrule your chosen
width and height, though that is less common.
You can *usually* put it where you want it by executing the following
after the CREATE-WINDOW but before the MAP-WINDOW:
(set-wm-properties window :user-specified-position-p t
:name title ; optional
:icon-name icon-title) ; optional
[Note: As of X11R5 (R4?), the X & Y parameters of SET-WM-PROPERTIES no
longer do anything useful. It's only the X & Y from CREATE-WINDOW that
matter.]
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607