Created attachment 90734 [details] [review]
patch to replace "group" variable names by "radio_button"

in the cases that you picked, the radio button API actually expects NULL or another radio button that is already a member of the radio button group for the newly created widget to join. so radio_button isn't really an improvement here. if your patch were to change the names to (radio_)group_member instead, that could go in though.

I do not understand what you are saying. Is there any cases where a radio button is not a member of a radio button group ?

gtk_radio_button_new_from_widget is waiting for an already created GtkRadioButton named "group". My patched proposed to name it radio_button (to be consistent with it's type). The aim of the patch is to have variable names consistent with their types. I guess that you would apply a patch that will have variable names consistent with their functions. I'm I true ? Is this the case in the whole GTK naming scheme ?

Please let me know.

(In reply to comment #3)
> I do not understand what you are saying. Is there any cases where a radio
> button is not a member of a radio button group ?

arguably, e.g. if there is only a single radio button in a window.

> gtk_radio_button_new_from_widget is waiting for an already created
> GtkRadioButton named "group". My patched proposed to name it radio_button (to
> be consistent with it's type). The aim of the patch is to have variable names
> consistent with their types. I guess that you would apply a patch that will
> have variable names consistent with their functions. I'm I true ? Is this the
> case in the whole GTK naming scheme ?

no, names in glib/gtk are given after intended purpose or function, not simply after type names. (if we named after type name only, we could only ever deal with *one* radio_button variable per scope ;)
so you may for example have variables help_dialog, toolbox and color_palette, which are *all* of type GtkWindow*.

for the specifc case of this bug, "radio_button" is what the functions create and return (conceptually), while the expected argument is a possible radio_button_group_sibling or NULL.

> Please let me know.

(In reply to comment #4)
> (In reply to comment #3)
> > I do not understand what you are saying. Is there any cases where a radio
> > button is not a member of a radio button group ?
> 
> arguably, e.g. if there is only a single radio button in a window.

In that case this single radio button is a member of his own radio button group isn't it ?

[...] 
> no, names in glib/gtk are given after intended purpose or function, not simply
> after type names. (if we named after type name only, we could only ever deal
> with *one* radio_button variable per scope ;)
 :)

> so you may for example have variables help_dialog, toolbox and color_palette,
> which are *all* of type GtkWindow*.

Of course !

> for the specifc case of this bug, "radio_button" is what the functions create
> and return (conceptually), while the expected argument is a possible
> radio_button_group_sibling or NULL.

So the variable name should be something like "radio_button_group_member". But as stated, every radio button is a member of a group. (NULL is also a member of the NULL group :)). therefor radio_button seemed to me to be a less long, but still consistent variable name.

I can rewrite my patch with "radio_group_member" or "radio_button_group_member" or you can apply the previous one with "radio_button". Now it's only a matter of choice (I think that "group" is not the right one). What is your's ?

(In reply to comment #5)

> I can rewrite my patch with "radio_group_member" or "radio_button_group_member"
> or you can apply the previous one with "radio_button". Now it's only a matter
> of choice (I think that "group" is not the right one). What is your's ?

(radio_)group_member as stated in comment #2.

Created attachment 90742 [details] [review]
new patch with radio_group_member instead of radio_button

thanks, applied.