Re: Assigning an accelerator to a button

Sorry for the very slow answer.
You are very right: the current type of Gobj.misc_ops#add_accelerator
only allows to use GtkWidget signals, whereas it should allow all
signals of the current widget.
This is in some way unavoidable, as misc_ops does not take the current
widget class as parameter.

I have fixed that in the repository by making the type of add_accelerator
polymorphic:

    method add_accelerator : 'a.
      sgn:('a, unit -> unit) GtkSignal.t ->
      group:accel_group -> ?modi:Gdk.Tags.modifier list ->
      ?flags:Tags.accel_flag list -> Gdk.keysym -> unit

In the mid-time, you can do what you want without using
Obj.magic by writing:

  let cast_to_widget_signal sg = {sg with GtkSignal.classe = `widget}

This is of course unsafe since it allows to use this widget with
other classes, but here this cannot be avoided.

	Jacques

2014/02/22 21:41: Erkki Seppala <[email protected]> wrote:

> Hello,
> 
> I'm having trouble with the following piece of code:
> 
> --8<--
> (* ocamlfind ocamlc  -o foo -linkpkg -package lablgtk2,lablgtk2.auto-init foo.ml *)
> 
> open Gtk
> 
> let destroy () = GMain.Main.quit ()
> 
> let cast_button_signal_as_widget_signal
>  (x : ([`button], unit -> unit) GtkSignal.t) :
>  (Gtk.widget, unit -> unit) GtkSignal.t =
>  Obj.magic x
> 
> let main () = 
>  let main_window = GWindow.window () in
>  let accel_group = GtkData.AccelGroup.create () in
>  main_window#add_accel_group accel_group;
>  let quit_button = GButton.button ~label:"Quit" ~packing:main_window#add () in
>  quit_button#misc#add_accelerator
>    ~sgn:(cast_button_signal_as_widget_signal GtkButtonProps.Button.S.activate)
>    ~group:accel_group
>    ~modi:[`CONTROL] GdkKeysyms._q;
>  ignore (quit_button#connect#clicked ~callback:destroy);
>  main_window#show ();
>  GMain.Main.main ()
> 
> let _ = main ()
> 
> --8<--
> 
> The problem is in the binding of the Ctrl-q to the quit button (doing
> the same with menu items has many examples on the net). This solution
> works, but the function involving Obj.magic is far from optimal.
> 
> So, perhaps there's a better way? Or perhaps this is a bug?