Hi,
I was trying out CFFI at the weekend and was pleasantly surprised at how simple it was to create some simple bindings to GTK:
http://people.vislab.usyd.edu.au/~ssmith/lisp/cffi-gtk-test.lisp
What's interesting to me is that rather than relying on third-party bindings it is reasonable to just add your own as-needed, as creating a binding manually is no more work than actually using it.
Thanks for the good work.
Cheers, Steve
On 2005-dec-11, at 07:00, ssmith wrote:
I was trying out CFFI at the weekend and was pleasantly surprised at how simple it was to create some simple bindings to GTK:
http://people.vislab.usyd.edu.au/~ssmith/lisp/cffi-gtk-test.lisp
Hello,
Looking at your code, I have a couple of suggestions:
1. (defcfun ("gtk_window_new" gtk-window-new) ...)
This is identical to (defcfun "gtk_window_new" ...), CFFI will convert the name automatically for you and generate a function named GTK-WINDOW-NEW.
2. WITH-FOREIGN-OBJECT allocates memory, if what you want to do is bind the return value of some foreign function to a variable use let. So your gtk-button-test should look something like this:
(defun gtk-button-test () (let (win button) (gtk-init (null-pointer) (null-pointer)) (setf win (gtk-window-new :gtk-window-toplevel)) (g-signal-connect win "delete_event" (callback delete-event) (null-pointer)) (gtk-container-set-border-width win 10) (setf button (gtk-button-new-with-label "Press Me")) (g-signal-connect button "clicked" (callback click-event) (null-pointer)) (gtk-container-add win button)) (gtk-widget-show-all win) (gtk-main)))
BTW, have you looked at cells-gtk? It might be nice to port it to CFFI *hint* *hint*. :-) It'd be very nice, since IIRC it currently only supports CLISP, Lispworks and Allegro. You'd have my support, by e-mail or in #lisp!
On Sun, Dec 11, 2005 at 07:39:57AM +0000, Luís Oliveira wrote:
Hello,
Looking at your code, I have a couple of suggestions:
Cool, thanks.
BTW, have you looked at cells-gtk?
I have, although briefly. It looks neat from a software-engineering view, but my feeling is it would be hard to develop a HIG-compliant GTK app in it. Good for code reuse if that was your goal though.
The "right" way to do a GTK lisp framework would probably be similar to the PyGtk bindings. CLG looks more like this method, but I only discovered it last night soI need to take a closer look. It may be another good candidate for a CFFI port though. However I'm a relative newbie to Lisp.
BTW, has there been any thought on mapping C++ classes to CLOS?
Cheers, Steve
On 2005-dec-11, at 09:45, ssmith wrote:
BTW, has there been any thought on mapping C++ classes to CLOS?
If I'm not mistaken, that's one of Verrazano's goals.
On Sun, Dec 11, 2005 at 11:13:37AM +0000, Luís Oliveira wrote:
On 2005-dec-11, at 09:45, ssmith wrote:
BTW, has there been any thought on mapping C++ classes to CLOS?
If I'm not mistaken, that's one of Verrazano's goals.
My (possibly mistaken) understanding is Verrazano only handles the automated generation of C/C++ bindings, relying on CFFI for the binding implementation. I assume it must wrapper the C++ calls in C for CFFI?
Cheers, Steve
On 2005-dec-11, at 11:42, ssmith wrote:
My (possibly mistaken) understanding is Verrazano only handles the automated generation of C/C++ bindings, relying on CFFI for the binding implementation. I assume it must wrapper the C++ calls in C for CFFI?
See the "Project Status" on Verrazano's page as well as these two documents:
ftp://common-lisp.net/pub/project/fetter/proposal.pdf ftp://common-lisp.net/pub/project/fetter/design.pdf
I have an complete FFI to GTK+2 that currently runs in sbcl 0.9.7, cmucl 19c and openmcl 1.0. I generate the FFI using a program i wrote (lambda-gtk) from a "gtk database" i made with FFIGEN. I plan on moving this interface to CFFI, but dont know exactly when I will have time. (all that woudl be required would be to write a new "back end" that generated cffi exprs instread of an sbcl/cmu/openmcl exprs. I would also like to have the project use a verazanno generated "gtk database" at some point, but thats more work and not necessary for the first step of moving the whole thing to cffi.
details at http://common-lisp.net/project/lambda-gtk/
--rick
On Dec 11, 2005, at 3:45 AM, ssmith wrote:
On Sun, Dec 11, 2005 at 07:39:57AM +0000, Luís Oliveira wrote:
Hello,
Looking at your code, I have a couple of suggestions:
Cool, thanks.
BTW, have you looked at cells-gtk?
I have, although briefly. It looks neat from a software-engineering view, but my feeling is it would be hard to develop a HIG-compliant GTK app in it. Good for code reuse if that was your goal though.
The "right" way to do a GTK lisp framework would probably be similar to the PyGtk bindings. CLG looks more like this method, but I only discovered it last night soI need to take a closer look. It may be another good candidate for a CFFI port though. However I'm a relative newbie to Lisp.
BTW, has there been any thought on mapping C++ classes to CLOS?
Cheers, Steve _______________________________________________ cffi-devel mailing list cffi-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
details at http://common-lisp.net/project/lambda-gtk/
oops forgot to add the pretty picture links:
http://commonmusic.sf.net/doc/dict/plotter-topic.html#examples http://commonmusic.sf.net/doc/dict/cmio-topic.html
--rick
On 2005-dec-11, at 07:00, ssmith wrote:
http://people.vislab.usyd.edu.au/~ssmith/lisp/cffi-gtk-test.lisp
Also, another small suggestion. You could define the gboolean type and make the callback a little more lispy:
(defctype gboolean :boolean)
(defcallback delete-event gboolean ((widget :pointer) (event :pointer) (data :pointer)) (format t "Got delete event, quitting~%") (gtk-main-quit) nil)
-
Luís Oliveira -
Rick Taube -
tarka＠internode.on.net