On 6 October 2017 at 12:23, Stefan Salewski <mail@xxxxxxxxxxxx> 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 gtk-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gtk-list
