I got a question in connection with a gtkmm commit,
Why was the new GtkSpinButton::activate signal not wrapped in C++ code?
GtkSpinButton::activate is an action signal, i.e. it has the G_SIGNAL_ACTION flag
in gtk’s call to g_signal_new().
I was once told that apps shall not connect to action signals. Therefore they shall
not be wrapped in language bindings. There are lots of action signals which are
not wrapped in gtkmm. A few examples: GtkButton::activate, GtkDropDown::activate,
GtkFlowBox::activate-cursor-child, GtkLabel::move-cursor, GtkMenuButton::activate.
There are also exceptions (action signals which are wrapped in gtkmm), such as
GtkButton::clicked, GtkEntry::activate, GtkFlowBoxChild::activate.
In some cases the signal description in gtk says explicitly that the signal shall
not be used by apps. In other cases it says that the signal can be used by apps.
In most cases it does not say anything about the use in apps. How shall such
action signals be handled? What does other language bindings do?
Action signals are generally only emitted—that’s the whole point of them. In practice, though, they are seldom used, these days, because key shortcuts are not modifiable with “themes” any more, and we prefer actions.
The “activate” signal is a remnant of that era: a signal that is emitted when a widget is “activated”, either by the user through a key combination, or programmatically via gtk_widget_activate()—which is why the signal uses G_SIGNAL_ACTION: the signal is emitted by code that is not directly part of the type that defined it.
The whole activation-via-signal API was left into GTK4 because it was too late to clean up; for GTK5 there’s already an issue related to its replacement.
As far as generic G_SIGNAL_ACTION signals are concerned, you really don’t want to have special API for them: only allow signal emission with the equivalent of g_signal_emit_by_name().
For the specific case of the “activate” signal, you may want to allow people to connect to it, so they can respond to widget activation.