Re: How do you develop you GTK code?

["David J. Andruczyk" <djandruczyk yahoo com>]

I do pretty much as you, regarding variable naming, 
unneeded vars (i.e. mainly layout containers and
static labels in glade), are just left to be named via
glade's default naming system.  Since my app
(megatunix) is 100% built in glade,  pretty much evey
widget there that require signal handlers has them
defined IN GLADE,  but on app initialization when the
gui is created,  I have extra config files I built,
that share a common naming scheme with the glade
files.  I wrote a .ini style parser and code that
traverses the weidget tree of each Gui tab, search for
those widget names in my .ini files.  if ti findsa
match, it runs some code that looks for custom
attributes I created and sets them on the widgets.
(things like signal handler enumerations, and other
simple and some very complex attributes.    

NOTE: My app is very much a NICHE app, and is designed
to be modular as it has to adapt on runtime, and
statically defining all these attributes in code made
the code IMPOSSIBLE to be extensible. (megatunix
adapts to ECU firmware on startup using a minimalist
gui, and once it determines the ecu capability, it
ONLY loads specific Glade tabs that correspond to
controls valid for the device, hence my needs to be
able to define my extended attributes outside of the
application itself).

I also use the trick of a global hashtable to store
pointers to "customized" widgets, so they are easily
retrieved without having to use:
glade_xml_get_widget().  This is done because I want
to reference NON glade created widgets, and prefer to
rather just name one global definition of "extern
GHashTable *dynamic_widgets;" instead of a pile of
other externs.


In one of my simple apps (part of megatunix),  called
gaugedesigner,  this app is 100% glade, and I designed
it the same way as megatunix, defining all signal
handlers in the glade UI.  On app startup are init
functions that specifically retrieve widgets by name
to manipulate or bind additional data to them

tmp=glade_xml_get_widget(xml,"save_gauge_menuitem");
gtk_widget_set_sensitive(tmp,FALSE);

tmp=glade_xml_get_widget(xml,"save_as_menuitem");
gtk_widget_set_sensitive(tmp,FALSE);

g_object_set_data(G_OBJECT(glade_xml_get_widget(xml,"precision_spin")),"
handler",GINT_TO_POINTER(PRECISION));
       
g_object_set_data(G_OBJECT(glade_xml_get_widget(xml,"value_xpos_spin")),
"handler",GINT_TO_POINTER(VALUE_XPOS));
       
g_object_set_data(G_OBJECT(glade_xml_get_widget(xml,"value_ypos_spin")),
"handler",GINT_TO_POINTER(VALUE_YPOS));

and so on.


--- Richard Boaz <riboaz xs4all nl> wrote:

> 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>
_______________________________________________
> gtk-list mailing list
> gtk-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-list
> 


-- David J. Andruczyk

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com