[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [OT?] libglade, guile-gtk and glade-xml-signal-autoconnect

From: Brett Viren
Subject: Re: [OT?] libglade, guile-gtk and glade-xml-signal-autoconnect
Date: Wed, 30 Jan 2002 09:58:48 -0500

Bill Gribble writes:
 > The current behavior is that the C function binding for the specified
 > name is used by autoconnect.  i.e., you can't directly specify a scheme
 > function name in the signal handler slot in the Glade file.  This
 > preserves the semantics that libglade expects.  So, for example, if you
 > use 'gtk_main_quit' as the signal handler for a widget you will still
 > quit the app.  

Yes, connecting to gtk_ functions from Glade's list of defaults

But, I am a little confused.  Are you just saying that using "_"s
instead of "-"s should work?  It doesn't.  Even defining a scheme
function to be the what Glade gives as a default fails.  Ie like:
"(define (on_button1_clicked) ...)".

But, maybe you mean that the (glade-xml-signal-autoconnect ...) simply
doesn't look through "scheme space" for symbols (which is what I

 > It would be nice to have a way to specify that the function name is
 > Scheme rather than C.  Since libglade seems to silently drop things that
 > don't map to C functions, you could have a naming convention that signal
 > handlers starting with scm: are treated as Scheme functions and invoked
 > via a wrapper.  autoconnect could be wrapped with a little test that
 > makes those connections. 

To me, I think that nothing typed into a Glade session should be
implementation language specific.  Instead, I'd like to see the
glade-xml-* scheme functions do the following:

 - Translate all "_" to "-" in handlers defined in the .glade file
 - Try to find the resulting function in scheme space
 - If failed, pass the (untranslated) name to the C glade-xml*
   function so it can do whatever it does in the C world.

 > However, the guile-gtk wrappers make assumptions about the availability
 > of lexical closure for signal handlers.  For example, the 'widget'
 > argument is always omitted, with the assumption that an anonymous
 > function will be used as the handler:
 >   (gtk-signal-connect 
 >     widget "clicked"
 >     (lambda () 
 >       (simple-format #t "widget ~A was clicked.\n" widget)))
 > The Scheme handler for the "clicked" signal is arity 0, but the C
 > function is arity 1. If you wanted the handler to be a top-level
 > function, the handler would have to figure out a way to determine what
 > the "widget" argument to the C handler would have been.
 > I find the current behavior convenient, because I like using anonymous
 > functions as signal handlers.

Yes, I agree.  Many handlers don't/shouldn't care about what widget
triggered them.

 > What would happen if you used a generic Scheme function-caller as the
 > signal handler, and put a literal C string with quotes in the "data"
 > field?  the string could be the Scheme function name.  This might not
 > work at all, I'm just thinking out loud. 

Or how about defining the callbacks in a scope that can see the
widgets they need.  Ie:

;; "button-handler" is attached to "the-button" in the .glade file
;; and doesn't need to know its triggering widget
(define (button-handler) (display "the-button went click!\n"))

(let* ((xml (glade-xml-new ""))
       (entry (glade-xml-get-widget xml "the-entry")))

  ;; "entry-handler" is attached to "the-entry" in the .glade file
  ;; and needs to know its triggering widget
  (define (entry-handler) 
    (display "The entry contains:\n")
    (display (gtk-entry-get-text entry))

  ;; I wish this would connect up the two handlers in the .glade file!
  (glade-xml-signal-autoconnect xml))

Would this work (assuming, glade-xml-signal-autoconnect actually
checked for scheme functions)?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]