Re: libglademm and signal autoconnect

[Stas Sergeev <stsp aknet ru>]

Hi.

Murray Cumming wrote:
> > For example, the attached hack allows
> > to get the handlers by names
> I don't see your implementation of autoconnect_clicked().
Yes, its not there yet. :)
As stated above, the patch allows to get
the handlers by names, and that's what it
does in an example. I thought it is the main
problem with implementing autoconnect, so
the patch does only this right now. Note the
slots.get_slot("on_button_clicked") in an
example now, which demonstrates an ability
to get handlers by name.
I haven't implemented autoconnect_clicked()
(yet) because I don't see the libglade SAX
parser wraps in libglademm. I guess I'd have
to iterate the widgets tree, but this API
seems to be not wrapped yet, right?

> And this only works for void something(void) slots,
In this POC hack, only the void handlers are
supported. It might be easy to add anything
else though.

> rights, and even
> only for signals called "clicked"?
No, the main "feature" is to get the slot by
_any_ name, like in the example I changed.
The example now finds the slot by the name
"on_button_clicked", and that works.
Ignore the autoconnect_clicked() prototype
for now. :)

So, essentially, what my hack currently does,
is the possibility to look-up the handlers by
its names. That's all it does for now. If I
find out how to iterate the widget tree (for
which, I presume, the libglademm API is
currently missing), I'll implement autoconnect
(not only for clicked, but for everything).
So, how to iterate the widget tree? :)
Or any other way I can get the widget_name->slot_name
map for all widgets? That's all I need to get
the thing done, because the handler look-up already
works, as demonstrated. :)
I was also wondering whether or not such a
technique would be acceptable for inclusion
at all when everything is implemented, or only
the gmodule-like approach is considered acceptable
here (which I don't find practical to even try
with C++).