From tdukes at freescale.com Tue Aug 16 13:58:45 2005 From: tdukes at freescale.com (Todd Dukes) Date: Tue, 16 Aug 2005 08:58:45 -0500 Subject: [lambda-gtk-devel] problem with button Message-ID: <200508161358.j7GDwjUe002683@cde-tx32-ldt217.sps.mot.com> I am having a problem being able to use both the button "clicked" event and the "button-press-event" at the same time. The difference between the two is: - with button "clicked" the user must press and release mouse button one over the button. If the mouse moves out of the boundary of the button before the user releases the button, no "click" signal is emitted. - with the "button-press-event" the signal is emitted as soon as the mouse button is pressed over the button. You also get an 'event,' which you can use to determine which mouse button was pressed. I have a small application posted below. The function button-test should cause a window to appear with a single button, mis-labeled "quit" in it. Clicking the button should cause the text button-clicked to print. Pressing any mouse button over the button should cause the "button press" event messages to print. Unfortunatly the "click" events never occur. You can comment the button press event signal connection and see that in the case where this signal is not connected, the button clicks do register. The gtk+ documentation says that if the "button-press-event" handler returns false processing of the event will continue, which is why I am returning gtk:+false+. Can anyone point out how to make this work? thanks, Todd. (gtk:define-signal-handler bye1 :void (widget data) widget data ; stop unused var compiler nagging (format t "bye! ~%") (gtk:main-quit)) (gtk:define-signal-handler delete-event-handler :int (widget event data) widget event data ; stop unused var compiler nagging (format t "delete-event occured~%") gtk:+false+) (gtk:define-signal-handler button-clicked :void (widget data) (format t "button-clicked~%") (force-output t)) (gtk:define-signal-handler button-pressed :void (widget event data) (format t "button press ~a~%" data) (force-output t) (when (eq (gdk:EventButton.type event) gdk:button-press) (format t "button press, event ~a~%" (gdk:EventButton.button event)) (when (eq (gdk:EventButton.type event) gdk:button-press) (format t "button event " (gdk:EventButton.button event)) (force-output t))) (format t "returning ~a~%" gtk:+false+) (force-output t) gtk:+false+) (defun button-test () (gtk:init-ensure) (let ((window (gtk:window-new gtk:window-toplevel)) (hbox (gtk:hbox-new t 1)) (button-quit (gtk:button-new-with-label "quit"))) (gtk:window-set-policy window 0 0 1) (gtk:window-set-title window "button test") (gtk:container-add window hbox) (gtk:box-pack-start hbox button-quit nil nil 0) (g:signal-connect button-quit "clicked" (g:callback button-clicked) window) (g:signal-connect button-quit "button-press-event" (g:callback button-pressed) window) (g:signal-connect window "delete-event" (g:callback delete-event-handler) (g:nullptr)) (g:signal-connect window "destroy" (g:callback bye1) (g:nullptr)) (mapcar (lambda (x) (gtk:widget-show x)) (list button-quit hbox window)) (gtk:main))) From lisp22 at bellsouth.net Sun Aug 21 11:34:57 2005 From: lisp22 at bellsouth.net (Nineteen84) Date: Sun, 21 Aug 2005 11:34:57 +0000 Subject: [lambda-gtk-devel] problem with button In-Reply-To: <200508161358.j7GDwjUe002683@cde-tx32-ldt217.sps.mot.com> References: <200508161358.j7GDwjUe002683@cde-tx32-ldt217.sps.mot.com> Message-ID: <200508211134.57602.lisp22@bellsouth.net> On Tuesday 16 August 2005 01:58 pm, Todd Dukes wrote: > I am having a problem being able to use both the button "clicked" > event and the "button-press-event" at the same time. > > The difference between the two is: > > - with button "clicked" the user must press and release mouse button > one over the button. If the mouse moves out of the boundary of the > button before the user releases the button, no "click" signal is > emitted. > > - with the "button-press-event" the signal is emitted as soon as the > mouse button is pressed over the button. You also get an 'event,' > which you can use to determine which mouse button was pressed. > > I have a small application posted below. The function button-test > should cause a window to appear with a single button, mis-labeled > "quit" in it. > > Clicking the button should cause the text button-clicked to > print. Pressing any mouse button over the button should cause the > "button press" event messages to print. Unfortunatly the > events never occur. > > You can comment the button press event signal connection and see that > in the case where this signal is not connected, the button clicks do > register. > > The gtk+ documentation says that if the "button-press-event" handler > returns false processing of the event will continue, which is > why I am returning gtk:+false+.> > > Can anyone point out how to make this work? > > thanks, > Todd. > > > > (gtk:define-signal-handler bye1 :void (widget data) > widget data ; stop unused var compiler nagging > (format t "bye! ~%") > (gtk:main-quit)) > > (gtk:define-signal-handler delete-event-handler :int (widget event data) > widget event data ; stop unused var compiler nagging> > (format t "delete-event occured~%") > gtk:+false+) > > (gtk:define-signal-handler button-clicked :void (widget data) > (format t "button-clicked~%") (force-output t)) > > (gtk:define-signal-handler button-pressed :void (widget event data) > (format t "button press ~a~%" data) (force-output t) > (when (eq (gdk:EventButton.type event) gdk:button-press) > (format t "button press, event ~a~%" (gdk:EventButton.button event)) > (when (eq (gdk:EventButton.type event) gdk:button-press) > (format t "button event " > (gdk:EventButton.button event)) > (force-output t))) > (format t "returning ~a~%" gtk:+false+) > (force-output t) > gtk:+false+) > > > (defun button-test () > (gtk:init-ensure) > (let ((window (gtk:window-new gtk:window-toplevel)) > (hbox (gtk:hbox-new t 1)) > (button-quit (gtk:button-new-with-label "quit"))) > (gtk:window-set-policy window 0 0 1) > (gtk:window-set-title window "button test") > (gtk:container-add window hbox) > (gtk:box-pack-start hbox button-quit nil nil 0) > (g:signal-connect button-quit "clicked" (g:callback button-clicked) > window) (g:signal-connect button-quit "button-press-event" (g:callback > button-pressed) window) (g:signal-connect window "delete-event" (g:callback > delete-event-handler) (g:nullptr)) > (g:signal-connect window "destroy" (g:callback bye1) (g:nullptr)) > (mapcar (lambda (x) > (gtk:widget-show x)) (list button-quit hbox window)) > (gtk:main))) Todd, The problem is with this line: (gtk:define-signal-handler button-pressed :void (widget event data) The return value of an event callback needs to be of type :int Things should work as advertised, if you make that change. Regards, Nineteen84 PS: Has anyone started working on some wrapper classes for lambda-gtk? I've done a little preliminary work; a good set of classes would hide a lot of the tedium involved in calling GTK directly and they would insulate the user from the type of errors shown above. From taube at uiuc.edu Mon Aug 22 00:13:21 2005 From: taube at uiuc.edu (Rick Taube) Date: Sun, 21 Aug 2005 19:13:21 -0500 Subject: [lambda-gtk-devel] problem with button In-Reply-To: <200508211134.57602.lisp22@bellsouth.net> References: <200508161358.j7GDwjUe002683@cde-tx32-ldt217.sps.mot.com> <200508211134.57602.lisp22@bellsouth.net> Message-ID: hi -- no, at least i havent and it would be welcome! It seems that Clisp has a good ffi and callback support now too, that is another 'hole' that needs filling. im gearing up for a very busy fall semester and wont have any time for gtk things for several months... best, RIck > PS: Has anyone started working on some wrapper classes for lambda-gtk? > I've done a little preliminary work; a good set of classes would hide > a lot > of the tedium involved in calling GTK directly and they would insulate > the > user from the type of errors shown above. > > _______________________________________________ > lambda-gtk-devel site list > lambda-gtk-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/lambda-gtk-devel From tdukes at freescale.com Mon Aug 22 13:37:26 2005 From: tdukes at freescale.com (Todd Dukes) Date: Mon, 22 Aug 2005 08:37:26 -0500 Subject: [lambda-gtk-devel] problem with button In-Reply-To: <200508211134.57602.lisp22@bellsouth.net> References: <200508161358.j7GDwjUe002683@cde-tx32-ldt217.sps.mot.com> <200508211134.57602.lisp22@bellsouth.net> Message-ID: <17161.54550.244061.27603@gargle.gargle.HOWL> >>>>> "Nineteen" == Nineteen writes: .... Nineteen> Todd, Nineteen> The problem is with this line: Nineteen> (gtk:define-signal-handler button-pressed :void (widget Nineteen> event data) Nineteen> The return value of an event callback needs to be of Nineteen> type :int Things should work as advertised, if you make Nineteen> that change. Nineteen> Regards, Nineteen84 Thanks so much, this does exactly what I need. Todd. From lisp22 at bellsouth.net Mon Aug 22 15:05:48 2005 From: lisp22 at bellsouth.net (Nineteen84) Date: Mon, 22 Aug 2005 15:05:48 +0000 Subject: [lambda-gtk-devel] problem with button In-Reply-To: References: <200508161358.j7GDwjUe002683@cde-tx32-ldt217.sps.mot.com> <200508211134.57602.lisp22@bellsouth.net> Message-ID: <200508221505.48752.lisp22@bellsouth.net> On Monday 22 August 2005 12:13 am, Rick Taube wrote: > hi -- no, at least i havent and it would be welcome! It seems that > Clisp has a good ffi and callback support now too, that is another > 'hole' that needs filling. im gearing up for a very busy fall semester > and wont have any time for gtk things for several months... > > > PS: Has anyone started working on some wrapper classes for lambda-gtk? > > I've done a little preliminary work; a good set of classes would hide > > a lot of the tedium involved in calling GTK directly and they would >> insulate the user from the type of errors shown above. Rick, I'll clean up the code I've currently got and make it available to the members of the list. It will just be a prototype and will only implement some of the GTK classes, but it should be enough to demonstrate how a set of wrapper classes might work. The list members can give it a try and offer suggestions for improving the design. Before we know it, we could have a good set of classes. I'll try to upload the prototype by the end of September. --Nineteen84