Re: Connecting signals syntax.

[German Diago Gomez <al059365 alumail uji es>]

Mensaje citado por Marko Anastasov <marko marko anastasov name>:

> On Sat, 2007-01-13 at 15:22 +0100, German Diago Gomez wrote:
> >  When I want to connect some signal to a slot, I think the syntax should
> be
> > clearer. Why have I to do:
> > 
> >    button.signal_clicked().connect(sigc::mem_fun(this, &MyClass::myFunc));
> >    button.signal_clicked().connect(sigc::ptr_fun(&myFunc));
> > 
> > When I could do:
> > 
> >    button.signal_clicked().connect(this, &MyClass::myFunc);
> >    button.signal_clicked().connect(&myFunc);
> 
> connect() expects a sigc::slot, which is what sigc::mem_fun() and
> sigc::ptr_fun() provide.
> 
> > But the thing gets worse when you combine that with bind:
> >  
> >    button.signal_clicked().connect(boost::bind(sigc::mem_fun(this,
> > &MyClass::myFunc), data));
> 
> There's sigc::bind for that matter.
> 
> > This is difficult to write. I always have to think carefully what I'm
> writing.
> > Otherwise I make mistakes.
> 
> Well, binding is not very common when dealing with widgets' signals.
> But anyway, you should always think carefully when programming :).
> 
> >   I think that sigc should be replaced by boost::function which is more
> powerful
> > and you haven't to deal explicitly with mem_fun and ptr_fun because it has
> a
> > better type deduction system.
> 
> They are not the same. libsigc++ implements a typesafe callback system
> for standard C++ [1]. A signals and slots system. Boost equivalent is
> boost.signals, actually influenced by libsigc++ [2] . However, gtkmm
> won't be switching to boost.signals.
> 
> >   And I think that instead of using bind, you could overload connect to
> receive
> > additional parameters until an arbitrary number. This would make the
> syntax
> > like this:
> > 
> >   button.signal_clicked().connect(this, &MyClass::myFunc, data1, data2);
> > 
> >  You could do this for an arbitrary number of arguments, say, 10 arguments
> for
> > example. I think that syntax matters because you have to deal with
> connections
> > in code since the signaling system is type-safe and you can't do it from
> glade
> > like in python or C.
> 
> This is possible with libsigc++. It supports arbitrary number and
> provides compile time typesafe callbacks [1].
> 
> I strongly suggest you go through the gtkmm tutorial [3]. There's
> a section dedicated to the usage of signals and slots [4]. There is
> also a separate libsigc++ tutorial [5].
> 
> Marko
> 
> [1] http://libsigc.sourceforge.net/
> [2] http://www.boost.org/doc/html/signals/s06.html#id2740156
> [3] http://www.gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/index.html
> [4] http://www.gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/apb.html
> [5] http://libsigc.sourceforge.net/libsigc2/docs/manual/html/index.html
> 
> 
> 

But what matters, I think it's not just what you can do. I know that sigc and 
the signal system is powerful, but having to write so much code is not
convenient at all and makes it unreadable compared to a simpler syntax.
What matters is that you can do it in an easy and straightforward way. It's not
a big difficulty for me maybe, but it can be for
other people who wants to write code for my application (a plugin)
I think that maybe changing sigc and so on is not a good idea, but connect
should have some overloads to match the syntax I'm suggesting. Not the bind
syntax, but at least it should provide the two former ways to do it. I think it
wouldn't be too difficult. It's just adding some functions in the toolkit, it's
a few lines of straightforward code that wraps C++ functions with sigc::mem_fun
and sigc::ptr_fun