[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
works.
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
feared).
> 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 "file.glade"))
(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))
(newline))
;; 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)?
-Brett.