Re: Connecting signals syntax.

On Sat, 2007-01-13 at 15:22 +0100, German Diago Gomez wrote:
>  Hello. I'm using gtkmm to build an application. Great work! A good GUI
> toolkit.
>  But I'd like to give some feedback of what, from my perspective, would be some
> little improvements to the API.
>  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);

This might be possible already with libgsigc++. If not then I wonder how
boost::signal achieves it.

>    button.signal_clicked().connect(&myFunc);

I think this is possible already.

> But the thing gets worse when you combine that with bind:
>    button.signal_clicked().connect(boost::bind(sigc::mem_fun(this,
> &MyClass::myFunc), data));
> This is difficult to write. I always have to think carefully what I'm writing.
> Otherwise I make mistakes.

I find that spaces or newlines help.

>   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.

libsigc++ and boost::signal are very similar because they have tried to
be similar, influencing each other, and avoiding unnecessary
differences. Today libsigc++ is really just "like boost::signal but with
an officially stable API/ABI.".

When signals are in the official C++ standard, and are widely available,
I expect that we will port gtkmm to it.

>   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.
>  Don't get me wrong, I think gtkmm is a good toolkit, but I think that doing
> what I'm suggesting would be an improvement in API usability.

Murray Cumming
murrayc murrayc com

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