After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 451527 - Confusing GtkRadioButton variable names in some functions
Confusing GtkRadioButton variable names in some functions
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: Other
2.11.x
Other All
: Normal enhancement
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2007-06-27 08:38 UTC by Olivier Delhomme (IRC : dup)
Modified: 2007-06-27 11:29 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch to replace "group" variable names by "radio_button" (3.18 KB, patch)
2007-06-27 08:42 UTC, Olivier Delhomme (IRC : dup)
rejected Details | Review
new patch with radio_group_member instead of radio_button (3.26 KB, patch)
2007-06-27 10:18 UTC, Olivier Delhomme (IRC : dup)
none Details | Review

Description Olivier Delhomme (IRC : dup) 2007-06-27 08:38:47 UTC
Some functions in the gtkradiobutton.[ch] files are working on GtkRadioButton but the variable name is "group". This is confusing. I propose to replace this variable name with "radio_button" which leads to less confusion.
Comment 1 Olivier Delhomme (IRC : dup) 2007-06-27 08:42:08 UTC
Created attachment 90734 [details] [review]
patch to replace "group" variable names by "radio_button"
Comment 2 Tim Janik 2007-06-27 08:58:05 UTC
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.
Comment 3 Olivier Delhomme (IRC : dup) 2007-06-27 09:42:03 UTC
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.
Comment 4 Tim Janik 2007-06-27 09:49:08 UTC
(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.
Comment 5 Olivier Delhomme (IRC : dup) 2007-06-27 10:04:00 UTC
(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 ?

Comment 6 Tim Janik 2007-06-27 10:09:44 UTC
(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.
Comment 7 Olivier Delhomme (IRC : dup) 2007-06-27 10:18:48 UTC
Created attachment 90742 [details] [review]
new patch with radio_group_member instead of radio_button
Comment 8 Tim Janik 2007-06-27 11:29:32 UTC
thanks, applied.