Re: Added tooltip to display details of items in TreeView

[Tony Yum <tony tony-yum co uk>]

Murray Cumming wrote:

> 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
>
>  
Thanx. Now it's all clear. I think adding this bit to the book would 
help many others who are confused with way the signal aren't calling the 
slot coz before I thought I've read most of the document for sigc, but 
still didn't know about the second parameter.

>  
>
> > 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.
>  
Now the problem with the signal is solved, the second problem is putting 
the tooltip on the items in the tree instead of on the entire tree so 
that the tooltip wouldn't be at the bottom. I have already been told 
that tooltip don't support this. I can work around by putting the 
information in the status bar. But I am just wondering if the Gtk+ team 
is working on adding this support or is there other easy way around it 
for example writing your own tooltip, or using a bunch of label instead 
of using a tree (in my application I'm using list store in the 
TreeView)? Help is appretiated.

Tony