On Sep 24, 2012, at 4:16 AM, Arshdeep Singh wrote:
I think there are a few "big-picture" things that can help you in getting things in.
First and foremost is that you should stay aware that our code started as C and has slowly been migrating to C++. Also there is quite a lot of code that needs a few rounds of refactoring and cleanup. So don't be worried about questioning code you see in there, since there are good chances there is a lot that needs improving and shouldn't be just copied without at least some review.
Now I face a problem in editing the ' RegisteredCheckButton:<GtkWidget>CheckButton' class ' I added a function 'void setGray(RegisteredChekcButton* ,bool b) to the class definition, obviously the declaration in the <registered-widget.h> and the definition in <registered-widget.cpp>
void setGray (RegisteredCheckButton* A , bool b) { gtk_toggle_set_active ( (GtkToggleButton*) A , !b); }
We probably want to avoid function names using "gray", since that is a physical appearance of things. Instead we want to stay with more logical states.
One first reference we can use is the C-based GTK+ documentation. Looking at the hierarchy
http://developer.gnome.org/gtk/stable/GtkCheckButton.html#GtkCheckButton.obj...
you can see that it inherits from GtkTogleButton which in turn inherits from GtkButton, etc. Often working your way back up the hierarchy will reveal methods you might want to use.
(Keep in mind that we are using the C++ wrapper that would give Gtk::ToggleButton and Gtk::Button... but the C implementation is the main GTK+ library)
GtkToggleButton has functions to get and set "active". Gtk::ToggleButton has get_active() and set_active() methods. http://developer.gnome.org/gtk/stable/GtkToggleButton.html http://developer.gnome.org/gtkmm/stable/classGtk_1_1ToggleButton.html
Working our way all the way up to "Widget", we see settors and gettors for
"sensitive"
Looking at detail on that http://developer.gnome.org/gtk/stable/GtkWidget.html#gtk-widget-set-sensitiv...
Sets the sensitivity of a widget. A widget is sensitive if the user can interact with it. Insensitive widgets are "grayed out" and the user can't interact with them. Insensitive widgets are known as "inactive", "disabled", or "ghosted" in some other toolkits.
So for any widget we want to use "sensitive" instead of "gray". Additionally for toggle buttons such as check buttons or radio buttons we want to use "active" instead of "checked" or "pushed". Sticking with the logical meaning, not the physical presentation.
The object hierarchy shows that GtkCheckButton derives from GtkToggleButton, so this should work. This showed the error that you cannot convert RegisteredCheckButton* to GtkToggleButton* . So I switched
void setGray (RegisteredCheckButton* A , bool b) { gtk_widget_set_sensitive ( (GtkWidget*) A , !b); }
This compiled fine but nothing seems to happen now. This code should 'gray-out' the RegisteredCheckButton.
The next big-picture item is to try to avoid C-style casts. The bit of code that is "(GtkWidget*)" is actually fairly dangerous. In C++ first we have inheritance of classes that usually works with no casting at all. If you have a pointer to some class instance, you can pass it to a call of that takes a pointer to some parent class with no casting at all.
One dangerous aspect is that such casting can even corrupt your code. For example, the compiler will happily change a pointer to a constant string (such as char *ptr = "foo";) and pass it in as a GtkWidget class instance pointer. Avoiding those is good. The GTK+ library itself has an overall approach of providing macros that do the casting conversion while validating the pointers supplied. For example, this one could be
gtk_widget_set_sensitive( GTK_WIDGET(A) );
However keep in mind that this is more for C coding and we want to stick with C++ as much as we can (normally in our code we can just remove casts and the C++ compiler will do the right thing).
And as a final note, we try to avoid parameter names that are capitalized. (Also I personally dislike single-letter names and prefer ones that are a little more descriptive). http://inkscape.org/doc/coding_style.php