On Thu, 2006-04-20 at 15:26 -0500, Yevgen Muntyan wrote: > Owen Taylor wrote: > > >Please don't bind all keybinding signals. You are just asking for > >problems (as you discovered) if you bind them, and, perhaps worse, > >they pollute the API and confuse users... see for instance, > >GtkTextView::move-cursor... > > > But if it's not wrapped, binding user won't be able to override > the default handlers. GtkTextView::move-cursor is an example > of a signal where overriding is useful - e.g. for customizing moving > cursor by words. 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. > >users think they are change notification > >and get confused when they don't always get called. > > > > > 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. > >I think you have to figure out ad-hoc what signals need to be bound > >for connection/overriding and when it isn't clear from the docs, file > >bugs. > > > > > If a signal has class method, then it is supposed it may be overridden > in subclasses, isn't it? There is _gtk_binding_signal_new, that may be > used, or header must say "you may not override it", or something; but > by default if a signal is public, it must be public and must be in bindings. _gtk_binding_signal_new() is a relatively recent addition; it postdates GTK+-2.0, while the binding mechanism was introduced prior in GTK+-1.2 (iirc) assuming that anything with a default handler is *meant* to be overriddable is ignoring that history. We can't change them in the C API, but that doesn't mean that language bindings should expose them. Regards, Owen
Attachment:
signature.asc
Description: This is a digitally signed message part