guile-gtk: problem in "insert-text" signal handling.

guile-gtk: problem in "insert-text" signal handling.

[Stan Pinte]

hello,

with the following program, I am getting garbage from the "new-text" variable, when introducing the second and following characters...

Is this a bug in guile-gtk-1.2-0.31, or am I only supposed to use the first charachter of the string?

thanks a lot,

Stan.

output:

inserted: ["2"]
inserted: ["3B
             L˜âÿ¿:6@XB
                      pãÿ¿¸âÿ¿³@@D@"]
inserted: ["4B
             L˜âÿ¿:6@XB
                      pãÿ¿¸âÿ¿³@@D@"]
inserted: ["7B
             L˜âÿ¿:6@XB
                      pãÿ¿¸âÿ¿³@@D@"]
inserted: ["8B
             L˜âÿ¿:6@XB
                      pãÿ¿¸âÿ¿³@@D@"]


test program:

(use-modules (ice-9 format))
(use-modules (gtk gtk))

(let ((window (gtk-window-new 'toplevel))
      (button (gtk-button-new-with-label "Say Hello"))
      (ref-entry (gtk-entry-new)))
  (gtk-widget-set-name button "mybutton")
  (gtk-widget-set-name window "mywindow")
  (gtk-window-set-title window "Guile-Gtk: Hello World")
  (gtk-container-border-width window 10)
;  (gtk-container-add window button)
  (gtk-container-add window ref-entry)
  (gtk-signal-connect ref-entry "insert-text"
		      (lambda (new-text new-length position)
			(if (string? new-text)
			    (format #t "inserted: [~s]~%" new-text)
			    (format #t "not text!!!~n"))))
  (gtk-widget-show-all window)
  (gtk-standalone-main window))

-- 

Stanislas Pinte

Computer Consultant

	98, rue Bois l'Evêque
	B-4000 Liège

web:		http://www.altosw.be
email:		alto_stan@wanadoo.be

Re: guile-gtk: problem in "insert-text" signal handling.

[Daniel Skarda]

Hello,

> with the following program, I am getting garbage from the "new-text" variable,
> when introducing the second and following characters...
>
> Is this a bug in guile-gtk-1.2-0.31, or am I only supposed to use the first
> charachter of the string?

  I think you found a (design) bug in Gtk+ - string received by signal handler
is not terminated by '\000', the length of the string is passed as an additional
argument. Unfortunately, any other signal does not use "STRING, LENGTH" pattern
for passing string parameters. The bug is also potential source of SIGSEGV (when
no random '\000' is found, which is quite unlikely - but hey, all hideous bugs
have unlikely conditions.... )

  Another sad part of the story: sgtk_callback_marshall does not now the signal
name, so all we can do now on guile-gtk part is an ugly hack:

   if (n_args == 3 && GTK_FUNDAMENTAL_TYPE (args[0]) == GTK_TYPE_STRING) && ...)
     /* let's hope we handle "new-text" signal.... */

  Please report the bug to Gtk+ folks.

Have a nice day,
0.

Re: guile-gtk: problem in "insert-text" signal handling.

[Kevin Ryde]

Daniel Skarda <0rfelyus@ucw.cz> writes:
>
>   Another sad part of the story: sgtk_callback_marshall does not now
> the signal name, so all we can do now on guile-gtk part is an ugly
> hack:
>
>    if (n_args == 3 && GTK_FUNDAMENTAL_TYPE (args[0]) == GTK_TYPE_STRING) && ...)

Perhaps the class of the object could be checked too.  If it's a
GtkEditable with string+int+pointer parameters then that be tight
enough to avoid hitting anything else.

>   Please report the bug to Gtk+ folks.

Looks like it's become insert-at-cursor or some such in gtk 2, taking
a just a gchar* which presumably is null-terminated.

Re: guile-gtk: problem in "insert-text" signal handling.

[Daniel Skarda]

Kevin Ryde <user42@zip.com.au> writes:
> Perhaps the class of the object could be checked too.  If it's a
> GtkEditable with string+int+pointer parameters then that be tight
> enough to avoid hitting anything else.

  You are right. First I rejected the idea - I was aware of
gtk_signal_connect_object function. But fortunately there are no guile-gtk
bindings for the function, so the problem looks simple now (though check
for GtkEditale+string+... still smells like ugly hack).

0.