[cl-gtk2-devel] gtk_widget_add_events

[Valeriy Fedotov]

> 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).

Indeed, I think that currently cl-gtk2 interface is close to GTK2
original interface, of course, if you understand certain conventions.
Of course if you translate several examples form GTK2 to cl-gtk2, it
will be very helpful.

> 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.

If you add :data argument you will need to pass "responsibility"
somewhere anyway, because otherwise the data will be possibly garbage
collected. Introducing explicit memory management to common lisp
program is generally bad idea. And lexical closures instead of :data
argument is the most natural way of doing garbage collection in the
lisp way.

2011/7/17 Roman Klochkov <monk at slavsoft.surgut.ru>:
> 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
>
>
>
> _______________________________________________
> cl-gtk2-devel mailing list
> cl-gtk2-devel at common-lisp.net
> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/cl-gtk2-devel
>



-- 
With best regards, Valeriy Fedotov.