Re: Added tooltip to display details of items in TreeView

[Murray Cumming <murrayc murrayc com>]

On Fri, 2005-05-13 at 21:52 +0100, Chris Vine wrote:
> On Friday 06 May 2005 15:41, Andrew E. Makeev wrote:
> > Bob Caryl wrote:
> > > Tony Yum wrote:
> > > That connection syntax should probably be:
> > >
> > > signal().connect(sigc::bind<bool>(sigc::mem_fun(object, &mem_fun),
> > > false));
> > >
> > > where mem_fun expects the boolean value as a formal parmater.
> >
> > I don't think that was changed in Gtkmm-2.6 comparing to Gtkmm-2.4, but
> > connect() function has 2 arguments: 1 - connection slot, 2 - flag after
> > = true by default. So, if you would your callback to be called before
> > other handlers you should to pass false as second argument. Instead, you
> > may wish to use connect_notify() function that "sending" after = false.
> 
> You don't use sigc::bind.
> 
> Although they are not well documented for those new to gtkmm, these are glibmm 
> signal proxies, which are interfaces to the GObject signal system on which 
> GTK+ relies.  The connect method for these takes two arguments, the second 
> argument determining whether the user's callback is called after the GTK+ 
> default handler (if any) - a true value, or before it - a false value.

By the way, I added this to the book recently, under "signal handler
sequence":
http://www.gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/apbs06.html#id2530916


> A glibmm signal proxy has two forms of connect: connect(), which by default 
> passes true (after) to the second argument, and connect_notify(), which by 
> default passes false (before) to the second argument.  connect_notify() also 
> always expects a void return type for the callback, even if the signal 
> requires a boolean return type (say it is handling an GDK/X event, all of 
> which have "_event" in the signal name).  connect_notify() will supply the 
> boolean return value itself, and return false (carry on processing the 
> signal).
> 
> Confusingly, GObject's g_signal_connect() calls the callback before the 
> default handler (g_signal_connect_after() will call it after the default 
> handler).  Both these are macro front ends for g_signal_connect_object().  
> Returning true from a callback connected using g_object_connect() will 
> therefore stop signal emission to the default handler.  I do not know why 
> gtkmm does it the other way around but I expect there is a reason.

Connecting new signals after the existing signals seems obvious. I'd
expect my methods to run in the order in which I added them.

>   Of course 
> with gtkmm you have access to the equivalent virtual protected member 
> function ("on...()") for more fine-grained control of how the default handler 
> executes (the GObject signal system offers you before or after, and if 
> before, either skip the default handler or don't skip it, whereas with the 
> gtkmm virtual protected member function you can call the default handler at 
> any point you want).
> 
> A sigc signal object does not have the second argument - it knows nothing 
> about default handlers, as it is justs a generalised callback mechanism.  
> Likewise it has no connect_notify() method.

However, libsigc++ does offer you detailed control over the order in
which signal handlers will be called, using a different API. It's not
very useful though.

-- 
Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com