[cl-gtk2-devel] gtk_widget_add_events
Roman Klochkov
monk at slavsoft.surgut.ru
Sun Jul 17 05:04:07 UTC 2011
You can try http://common-lisp.net/project/gtk-cffi/
It is less "weird".
-----Original Message-----
From: Peter Keller [mailto:psilord at cs.wisc.edu]
Sent: Sunday, July 17, 2011 4:19 AM
To: cl-gtk2-devel at common-lisp.net
Subject: Re: [cl-gtk2-devel] gtk_widget_add_events
On Thu, Jul 14, 2011 at 11:45:53AM +0400, Valeriy Fedotov wrote:
> In gtk.demo.lisp (the most reliable source of documentation now),
> there is such code:
>
> (connect-signal area "realize"
> (lambda (widget)
> (declare (ignore widget))
> (pushnew :pointer-motion-mask
> (gdk-window-events (widget-window area)))))
>
> I did the same in my application and it worked fine.
>
> > However, your code seems to be getting
> > the window the widget is a part of and then adjusting the masks for
> > that instead.
>
> I think gtk_widget_add_events() is a kind of shortcut for low level
> GDK event handling details. Anyway, the above code works.
I finally got some time and tried the above out. It works.
Aside:
I am seriously considering of taking all of the source code from
"Foundation of GTK+ Development" by Krause and converting it over to
Common Lisp using cl-gtk2 so people can follow along the book but write
CL instead.
If I do this, then I have to have really good reasons to tell the audience
of my work why things deviate in "weird" ways from the canonical GTK+
functions.
I understand the desire to "make things Lispy", but I will say that
IMHO, a CL wrapping library should provide as close to the original API
as possible and THEN a higer-level lispy inferface put over THAT light
wrapper. I think the SDL interface in lispbuilder-sdl does a fair job
of this as an example.
This way, when people find the many GTK+ tutorials in C online, or read
books on GTK+ development, they aren't immediately frustrated by having
to decipher someone's (arbitrary, IMHO) viewpoint of what it meant to be
Lispy while also trying to understand the material (and its conversion
to CL).
An example is that in the C GTK interface, you can associate a data
pointer with a widget when connecting a signal. The data pointer gets
passed unadulterated to the handler when the handler is invoked. This
doesn't exist in the CL API. It took me a while to realize the reason
is because the author of cl-gtk2 decided it would be a good idea
to just close over the "data" variable in the closure passed to the
connect-signal. Sometimes, this is exactly the right thing because you
can make the anonymous closure right there. Other times it sucks because
you just associate the signal to a reference of a function which might
be arbitrarily complex. Pushing the responsibility of handling that
data binding to a function which doesn't care about it (and isn't even
called!) is awkward. But, I have no choice given the implementation
of cl-gtk2. This is an example where the "close to the bare metal"
interface could be provided to me and a lispy shortcut way could be
written on top of it. Of course I'd use the lispy shortcuts all the time,
but occasionally some idiomatic GTK+ should be translated as is.
Thank you.
-pete
_______________________________________________
cl-gtk2-devel mailing list
cl-gtk2-devel at common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/cl-gtk2-devel
More information about the cl-gtk2-devel
mailing list