Re: [gnome-love] glade_xml_signal_connect VS g_signal_connect

[Elijah P Newren <newren math utah edu>]

Hi,

On Thu, 3 Jun 2004, ethan zimmerman wrote:

> Is this g_signal_connect method...
>
> widget = glade_xml_get_widget (the_widgets, "quit_button");
> g_signal_connect (G_OBJECT (widget), "clicked",
>                   G_CALLBACK (time_to_quit),
>                   NULL);
>
> "Better" than this glade_xml_signal_connect method...
>
> glade_xml_signal_connect(the_widgets,
>                          "on_quit_button_clicked",
>                          G_CALLBACK(time_to_quit));
>
> I ask because it seems no one uses the latter method which leads me to
> believe there's a good reason not to.

I personally dislike the glade_xml_signal_connect* functions for the
following reasons:

  1. They provide no advantages over the g_signal_connect variants.  It
     just feels like confusing bloat to me to have yet more functions
     that basically do the same thing (and in fact, the
     glade_xml_signal_connect* functions are just thin layers over
     g_signal_connect_object).
  2. They actually require more work because you must name the callback in
     the glade interface AND call the connection function, whereas with
     g_signal_connect (and variants) you don't have to name the callback
     in the glade interface.
  3. As a result of 2, you cannot combine glade_xml_signal_autoconnect and
     glade_xml_signal_connect* for the same interface or you will have
     your callbacks called twice for every action.  Mixing of
     glade_xml_signal_autoconnect and g_signal_connect* is fine.
  4. The g_signal_connect* functions are very similar to the connection
     methods in other language bindings (whereas glade_xml_signal_connect*
     are not).  This may not be that big of a deal, but consistency is
     just really nice.
  5. The glade_xml_signal_connect* functions are implemented by calling
     g_signal_connect_object with the G_CONNECT_SWAPPED flag set, which
     isn't mentioned in the API documentation (yeah, yeah, I know, I
     should have submitted a patch for the API documentation when I
     stumbled across this).  This basically means that parameters are
     swapped.  But it's easy to forget when it's not explicitly there in
     the program.  And believe me, that has tripped me up.  Especially
     when I first ran across it and spent a few hours debugging and
     finally tracing the code down into the libglade library itself.  If
     there's going to be swapping of parameters, I'd like it to appear in
     my code so I don't forgot and have a hard to track down bug (or so
     that someone else doesn't).
  5.5.  (5 was getting to long, so I thought I'd add two more comments
     along the same lines here).  Using G_CONNECT_SWAPPED actually does
     make sense for most situations, but it's still annoying that it's
     hidden and thus can cause problems in the remainder of the
     situations.  Also, it appears that the meanings of the
     glade_xml_signal_connect functions have varied slightly over time (I
     traced things back to old versions of CVS when trying to debug my
     code when I ran into this swapped problem to try to understand what
     those functions meant and why they were written the way they were).
     However, I have long since forgotten the specifics.
  6. You have to use g_signal_connect and its friends anyway if you
     manually build part of your interface (and there are cases where you
     may want or need to do that).  Why not just use the same functions
     everywhere?

In summary, IMNSHO, glade_xml_connect* should be shot and put out of their
misery.  Use glade_xml_signal_autoconnect or one of the g_signal_connect_*
functions.

Hope that helps,
Elijah