Re: libglademm and signal autoconnect

[Stas Sergeev <stsp aknet ru>]

Hi.

Murray Cumming wrote:
> I see nothing there that suggests that you have found a way to correctly
> connect any slot (with any return type or parameter types) to a signal
> based on just the name.
>
> All you are doing is storing specific sigc::slot instances in a std::map
> via the sigc::slot base class, and getting that specific slot types back
> again from your get_slot() via dynamic_cast<>. Of course the application
> code needs to specify the get_slot()<> template type (via
> get_widget()<>) so that the dynamic_cast<> can succeed.
That's what the application (the
test I hacked) does now, but this
is not what it was supposed to do.
Of course the types have to be
specified to get_slot()<>, but this
is not what an application should
do - libglademm can do that now.
I think it should iterate the widget
tree, get every widget that emits
the signal, and specify the correct
types for that widget, of course,
this is unavoidable. The main goal
is to move that task inside libglademm,
as with the string-based lookup there
seem to be no more reasons why the
libglademm's code cannot do that itself.
I wasn't looking for the way to avoid
specifying the types entirely. I only
want to provide libglademm with all
the code it needs to do that without
a help of an application. Application
should only create the slots object
and pass it to libglademm, and forget.
My current example doesn't do this,
simply because I don't know how to
iterate the widget tree.

> If you can really make this automatic rather than just rearranging the
> syntax of a normal signal connection, I'd be happy to be proved wrong. I
No, what you expected was not my goal.
Someone have to specify the types for
the dynamic_cast to succeed, but if that
someone is libglademm, not an app writer,
then the things are much better.

> suggest that you use bugzilla.
OK, here:
http://bugzilla.gnome.org/show_bug.cgi?id=573482