Why are signal names strings and not enums?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Why are signal names strings and not enums?

Stefan Salewski-2
We are using code like

   g_signal_connect(G_OBJECT(btn), "clicked", 
      G_CALLBACK(gtk_main_quit), G_OBJECT(window));

  g_signal_connect(G_OBJECT(window), "destroy", 
      G_CALLBACK(gtk_main_quit), NULL);

Why strings and not enums for clicked and destroy parameter?

I wondered about that myself when I started with GTK ten years ago and
recently someone suggested to do not use strings for my Nim GTK
bindings.

Well, strings have the disadvantage that undefined signal names are not
discovered during compile process.
_______________________________________________
gtk-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list
Reply | Threaded
Open this post in threaded view
|

Re: Why are signal names strings and not enums?

Gergely Polonkai
Yes, but in that case how would you deal with custom signals, e.g. the ones you implement for your own custom widgets?

It’s pretty much impossible for an extendable API.

Stefan Salewski <[hidden email]> ezt írta (időpont: 2017. okt. 6., P, 13:24):
We are using code like

   g_signal_connect(G_OBJECT(btn), "clicked", 
      G_CALLBACK(gtk_main_quit), G_OBJECT(window));

  g_signal_connect(G_OBJECT(window), "destroy", 
      G_CALLBACK(gtk_main_quit), NULL);

Why strings and not enums for clicked and destroy parameter?

I wondered about that myself when I started with GTK ten years ago and
recently someone suggested to do not use strings for my Nim GTK
bindings.

Well, strings have the disadvantage that undefined signal names are not
discovered during compile process.
_______________________________________________
gtk-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list

_______________________________________________
gtk-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list
Reply | Threaded
Open this post in threaded view
|

Re: Why are signal names strings and not enums?

Emmanuele Bassi
In reply to this post by Stefan Salewski-2
On 6 October 2017 at 12:23, Stefan Salewski <[hidden email]> wrote:
> We are using code like
>
>    g_signal_connect(G_OBJECT(btn), "clicked",
>       G_CALLBACK(gtk_main_quit), G_OBJECT(window));
>
>   g_signal_connect(G_OBJECT(window), "destroy",
>       G_CALLBACK(gtk_main_quit), NULL);
>
> Why strings and not enums for clicked and destroy parameter?

Signal names were encoded as strings in the very beginning, and even
if there was a reason, it's now lost in the mists of time. We can but
speculate.

One of the reasons is that signal details with enumerations are
impossible, as you cannot have a compact "notify::foo" signal
definition.

> Well, strings have the disadvantage that undefined signal names are not
> discovered during compile process.

You cannot discover signals at compile time, since they are added at
run time anyway.

The only way to have them discoverable at compile time with
enumerations would be to have a public enumeration type with the names
of all signals.

Additionally, enumerations are just integers, so the API would need to be:

  g_signal_connect (gpointer instance, int signal_id, ...)

which doesn't give you anything in terms of type safety at compile time.

Ciao,
 Emmanuele.

--
https://www.bassi.io
[@] ebassi [@gmail.com]
_______________________________________________
gtk-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list