| Hi, Like the others posting so far, I do not use any IDE to program my gtk+ app. I had a quick look once upon a time, but quickly determined that if you want or require to change the code that is automatically generated, you might as well just write your own instead of trying to get in the deep-end of someone else's ideas about how this should be done. This subject came up a little while ago as well. Then, the poster found that writing your own code was a big pain since this required coming up with a variable name for every widget needing to be created. But I didn't and still don't understand this complaint. When creating widgets, two types of widgets are required, one which never again needs to be accessed (e.g., a static label (don't even start talking about dynamic labels...:) ), and the other requiring accessing (e.g., an entry area taking input from the user). For those widgets not needing to be accessed, it is not necessary to provide a unique variable name, rather, you can re-use the same variable over and over since once a widget is registered/packed/whatever, you need not reference it again. To illustrate, the following snippet generates two buttons and an entry area with a label laid out simply in a vertical container: vbox = gtk_vbox_new(FALSE, 0); button = gtk_button_new_with_label("TRACES"); g_signal_connect((button), "clicked", G_CALLBACK(buttonCallback), &enums[TRACES]); gtk_size_group_add_widget(size_group, button); gtk_container_add(GTK_CONTAINER (vbox), button); strcpy(toolTip, "Open Trace files"); gtk_tooltips_set_tip(GTK_TOOLTIPS (tips), button, toolTip, toolTip); button = gtk_button_new_with_label("Next"); g_signal_connect((button), "clicked", G_CALLBACK(nextTrace), &enums[NEXT]); gtk_size_group_add_widget(size_group, button); gtk_container_add(GTK_CONTAINER (vbox), button); strcpy(toolTip, "Display NEXT Screen of Trace Files"); gtk_tooltips_set_tip(GTK_TOOLTIPS (tips), button, toolTip, toolTip); hbox = gtk_hbox_new(FALSE, 0); label = gtk_label_new("min:"); MTfixed[MIN] = entry = gtk_entry_new(); g_signal_connect(MTfixed[MIN], "activate", G_CALLBACK(reMag), &OV[MAGNIFYSCR]); gtk_entry_set_width_chars(GTK_ENTRY (entry, 5); gtk_container_add(GTK_CONTAINER (hbox), label); gtk_container_add(GTK_CONTAINER (hbox), entry); gtk_container_add(GTK_CONTAINER (vbox), hbox); strcpy(toolTip, "MIN: define as absolute (e.g., 1000) or as Percentage of MAX/MIN Mean (e.g., 50%) (BLANK = Real MIN)"); gtk_tooltips_set_tip(GTK_TOOLTIPS (tips), entry, toolTip, toolTip); As another poster pointed out, this repetitive type of widget creation can be contained within its own routine. But basically, once you've got the various types of widgets and layouts you require, it is trivial to copy and paste the code over and over, only requiring the widget's creation details to be changed for each new instance. The above snippet requires only that the entry area be uniquely named for later reference. In my code, all widgets are globally defined as GtkWidget *, casting when- and wherever appropriate. (Some purists might balk at global variables but I have no problem with globals which never change value over the entire life of a program, especially when they're widgets needed possibly anywhere.) To handle the problem of having to name so many widgets nonetheless, adopt a simple and shorthand naming convention you can immediately recognize, deduce, and even guess which makes sense somehow to the program and their usage. As well, arrays of widgets can be very helpful here. And like another poster, I highly recommend attaching as few callbacks as possible to the widgets. Like he does, as can be seen above, each button is attached to the same callback with an enum value passed to the callback routine. Once called, case statements handle each button's differing requirements. (Unlike how he does it, however, I do this more directly in the signal connection itself; either method works though depending on exact requirements, using g_object_*_data() may be more appropriate.) In general, try to attach like widgets to the same callback. In practice this won't be universal, some callbacks demand their own routine; the point is, maintaining code in the future is always made easier when the number of callbacks is minimized to the greatest extent possible. And good luck, richard |