Re: Language bindings and popup_menu and show_help signals



On Fri, 2006-04-14 at 14:14 +0200, Murray Cumming wrote:
> On Thu, 2005-12-15 at 13:18 +0100, Murray Cumming wrote:
> > On Fri, 2005-12-02 at 18:21 +0100, Murray Cumming wrote:
> > > On Fri, 2005-07-22 at 15:59 -0500, Federico Mena Quintero wrote:
> > > > On Fri, 2005-07-22 at 20:22 +0200, Murray Cumming wrote:
> > > > > > The API cannot change, by definition :)
> > > > > 
> > > > > What definition? If some G_SIGNAL_ACTION signals should be wrapped, how
> > > > > can I know which ones should be and which ones should not be wrapped?
> > > > 
> > > > We cannot change the public APIs once they are released.  Those signals
> > > > are part of the public APIs, so we can't change them.  Just bind them
> > > > all.
> > > 
> > > That's not what we were told. We were told not to wrap keybinding
> > > signals. I can't find the email (which I'm pretty sure was from Owen.
> > > 
> > > We were told that we should never have wrapped these signals:
> > > http://cvs.gnome.org/viewcvs/gtk%2B/gtk/gtktreeview.h?r1=1.56&r2=1.57
> > > so the API change should not have affected us. Should I wrap these now?
> > 
> > Anyone?
> 
> I would really really like an answer to this. We seem to need to wrap the 
> popup_menu and show_help signals, but I have no confidence that I won't be 
> told later that we shouldn't have wrapped them.

G_SIGNAL_ACTION just means "this signal can be emitted via
g_signal_emit() directly - it doesn't need a wrapper function"

It could be:

 - A keybinding signal handled by the widget internally - there should
   not be any way of overriding the handler for such a signal or
   for connecting to them.

 - A keybinding signal that has to be handled by derived widgets.
   Overriding these is necessary, connection is often also useful.
 
 - Not a keybinding signal at all.

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... users think they are change notification
and get confused when they don't always get called.

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.

					Owen





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]