GitLab

We have an over-abundance of signals and virtual functions inside GtkEditable, and it all gets worse when throwing delegates into the mix.

Calling gtk_editable_insert_text() runs the GtkEditableInterface.do_insert_text() virtual function, which will emit the GtkEditable::insert-text signal, whose default handler will call gtk_editable_insert_text() on the delegate function, if one is set.

graph TD;
  editable.insert_text-->editable.do_insert_text;
  editable.do_insert_text-->editable.insert-text;
  editable.insert-text-->delegate.insert_text;

This prevents us from hoisting the GtkEditable::insert-text signal from the delegate to the wrapper editable, because then the wrapper will emit the signal on the delegate, which will then emit it on the wrapper, and so on, and so forth.

The same happens for GtkEditable::delete-text.

This prevents us from completely fulfilling the contract of GtkEditable on implementations that have a delegate. Sadly, we documented that the appropriate way to deal with editable signals is to connect to the signal and stop the emission from the callback. This means that any attempt at fixing this mess is going to break existing code.

Ideally, we should decouple signals from virtual functions; eliminating signals altogether might be the best option, in favour of some sort of filter object attached to the GtkEditable in case you want to transform the text.