Key bindings and subclasssing (was: Language bindings and popup_menu and show_help signals)

["Yevgen Muntyan" <muntyan tamu edu>]

On Thu, April 20, 2006 12:59 pm, Owen Taylor wrote:

> We've made no general attempt to make binding signals overriddable.
> You might be able to do something cool by overriding one of them,
> but that's not the intent of the API. When there is a binding signal
> it means that we wanted to make the keybindings customizable by
> the user or a key theme author. That's all.

Was it the intent or not, it is possible to override key bindings signals,
and it works. Is it not supported use of those signals? If not, how
one is supposed to customize what ctrl-arrows do in GtkTextView, for
example?
One can't just connect to key-press-event and hardcode keys, since there
are gtk key bindings. One can't install new bindings (with new signal
names) since they won't get overridden if user changes bindings for parent
class. One can't create a signal with the same name. Overriding key
binding signal is the only way to customize keyboard behaviour (not just
screw it up to make Ctrl-Left do my special thing regardless of what user
wrote in rc file or something). Or do I miss something?

>> The solution for this problem is documentation which would tell
>> what signal does and when to use or not to use it. "it might confuse
>> someone" is not a reason to limit *functionality*.
>
> You clearly haven't read gtk-app-devel-list over the last many years...
> Adding something that is named almost exactly like what a user wants is
> *not* a good idea; having to add docs that say "don't use this" is a
> sign that there is a problem with your idea.

Well, maybe GtkTextView::move_cursor needed to be named differently in the
first place. But it is there, and it does its job. Docs must tell what
this signal does anyway.

Best regards,
Yevgen