GNOME Bugzilla – Bug 447037
some signal names are duplicated with different prototypes for the handlers
Last modified: 2007-06-29 07:20:16 UTC
some signal names are reused in other classes with different prototypes. example: signal name toggled is used differently in: /usr/include/gtkmm-2.4/gtkmm/cellrenderertoggle.h: Glib::SignalProxy1< void,const Glib::ustring& > signal_toggled(); compared to the more prevalent: /usr/include/gtkmm-2.4/gtkmm/checkmenuitem.h: Glib::SignalProxy0< void > signal_toggled(); /usr/include/gtkmm-2.4/gtkmm/toggleaction.h: Glib::SignalProxy0< void > signal_toggled(); /usr/include/gtkmm-2.4/gtkmm/togglebutton.h: Glib::SignalProxy0< void > signal_toggled(); /usr/include/gtkmm-2.4/gtkmm/toggletoolbutton.h: Glib::SignalProxy0< void > signal_toggled(); at the moment, don't see it as a bug, but more of a user nightmare. granted gtk+ is probably the one naming these as well, and gtkmm tries to match it. it's more of a problem for me at the moment as I'm trying to make a code generator based on glade3 and using libglademm. I made a simple scanner to generate the prototypes from the header files for the signal names... I'm also avoiding the class type that the signal is tied to if possible since that makes the scanner more difficult. There are other duplicate signal names with different prototypes if this is indeed of interest, here's output from my program: warning: signal `changed' is already defined! previous: rtype = void params = current : rtype = void params = const Glib::RefPtr<RadioAction>& warning: signal `event' is already defined! previous: rtype = bool params = GdkEvent* current : rtype = bool params = const Glib::RefPtr<Glib::Object>&,GdkEvent*,const TextIter& warning: signal `set_scroll_adjustments' is already defined! previous: rtype = void params = Adjustment*,Adjustment* current : rtype = void params = Gtk::Adjustment*,Gtk::Adjustment* warning: signal `toggled' is already defined! previous: rtype = void params = current : rtype = void params = const Glib::ustring&
> it's more of a problem for me at the moment as I'm trying to make a code generator based on glade3 and using libglademm. [snip] > I'm also avoiding the class type that the signal is tied to if possible since that makes the scanner more difficult. I just don't think you should do that. You need to fix your code generator. (Not that I think anyone should use a code generator). This is like having different add() functions with different parameters. It's OK, even if it's unnecessarily inconsistent. We can't change it now anyway without breaking ABI. You might file a bug about the inconsistency with GTK+, in case they ever do a GTK+ 3.0 version.
I did just that. I added more smarts to the code generator and now it works great. It was a little more pain, but only a little. The generator only reduces the amount of redundant coding involved in getting pointers to widgets and the dialog, and tying signals to class member functions. it also makes a factory method so that you never have to look at the glade file loading and getting the derived instance stuff ever again. If anyone is interested, please leave a comment and I'll post details. It sure made my life easier... ;-)