[glade--]Bug and possible fix for radio button grouping

Mark Jones <[email protected]>
Newsgroups gmane.comp.gnome.glademm
Message-ID <20021101214511.VBFJ1440.out008.verizon.net@[127.0.0.1]>
Christof,

I ran into a bug today with radio button grouping.  Glade-2 works a little differently than glade did with assigning groups to radio buttons.  I suspect there is a bug in it as well, as it doesn't allow you to name it whatever you want, but that is separate from this issue.  This issue arose when I had more than one rb and wanted them all grouped in the same group.  I put them all in the same group, and they would be so when run as C code with glade-2, but when run as C++ with glademm (from CVS) the button that the group was named after would always be in its own separate group, a group not named after itself, which is the group all of them including itself had been assigned in glade-2.  I looked in the .glade file, and it turns out it had not been assigned a group within the XML.  So I realized either that is a bug in glade-2 (and how it writes out the XML), or else the source writers should put it in a group named after itself by default (which is what glade-2's C source wr
 iter appears to do based on the interface.c file it writes).  So I dug into the glademm code and fixed it to handle that.  

writers/radiobutton.cc



void Gtk_RadioButton::ConstructionArgs(const Widget &w, CxxFile &f) const
{  f.FunctionArg();
    
   if ( w.hasProperty("group") )
       f << "_RadioBGroup_" << Configuration.InstanceName(w.getProperty("group"));
   else         // no group specified, should be in group named after itself
        f << "_RadioBGroup_" << w.Name();
   // checkbutton's arguments
   Parent::ConstructionArgs(w,f);
}

void Gtk_RadioButton::CreatePointer(const Widget &w,CxxFile &f) const
{  
//   This is what it was doing:
//   Gtk::RadioButton::Group _RadioBGroup_;
//   Gtk::RadioButton *radiobutton1 = manage(new class Gtk::RadioButton(_RadioBGroup_, "radiobutton1", true));
//   Gtk::RadioButton::Group _RadioBGroup_radiobutton1;
//   Gtk::RadioButton *radiobutton2 = manage(new class Gtk::RadioButton(_RadioBGroup_radiobutton1, "radiobutton2", true));

//   If glade-2 is writing the .glade file correctly, this is what it should have done:
//   Gtk::RadioButton::Group _RadioBGroup_radiobutton1;
//   Gtk::RadioButton *radiobutton1 = manage(new class Gtk::RadioButton(_RadioBGroup_radiobutton1, "radiobutton1", true));
//   Gtk::RadioButton *radiobutton2 = manage(new class Gtk::RadioButton(_RadioBGroup_radiobutton1, "radiobutton2", true));

//   Glade-2 does not write out a group for the first radio button in a group
//   and when it writes c code, it makes the assumption that if there is no group
//   then it will named after itself.

    if ( w.hasProperty("group") )
    {
    if (Cxx_Fileset::NeedToDeclareRadioGroup("B:"+w.getProperty("group","")))
        f.Declaration() << "Gtk::RadioButton::Group _RadioBGroup_" 
            << Configuration.InstanceName(w.getProperty("group",""));
    }
    else
    {
    if (Cxx_Fileset::NeedToDeclareRadioGroup("B:"+w.Name()))
        f.Declaration() << "Gtk::RadioButton::Group _RadioBGroup_" 
            << Configuration.InstanceName(w.Name());
    }
    Parent::CreatePointer(w,f);
}

I've attached the .glade file for verification of this.  I have tested it for a variety of numbers of radio buttons, but all in gtkmm-2 only.

Mark
project22.glade (application/octet-stream, 8.3 KB) - not displayed
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.