If what you mean by "widget hierarchy" is what I think you mean --
namely, the parent-child relationships between container widgets and
the stuff they contain -- then I would recommend modularizing
according to this hierarchy. That is, steps 2, 3, and 5 in your list
can go together in a single module, as long as they deal with a set of
widgets that is meaningful to you ("is" applies to "set", not
"widgets"). Another module could handle steps 1 and 6 together; this
is basically the "main" module.
So if you've got a program with a main window, from which various
other windows may be open, or in which subwindow-like collections of
widgets (like a GtkNotebook, say) are contained, you might try
something like:
/* main module */
GtkWidget *
create_main_window()
{
...
w1 = create_sub_window1();
w2 = create_sub_window2();
...
}
main( int argc, char *argv[] )
{
GtkWidget *w;
gtk_init(&argc, &argv);
w = create_main_window();
gtk_widget_show_all(w);
gtk_main();
return 0;
}
/* sub module 1 */
GtkWidget *
create_sub_window1()
{
...
}
/* sub module 2 */
...
/* end */
Anyway, on the rare occassion that a GTK app of mine gets large enough
that I want to modularize, this is how it usually goes. And a large
app that I'm working on (though not the GTK end) seems to be doing
things in a similar way.
Maybe it's just my style, but it seems to me that if you split up what
you refer to as steps 2, 3, and 5, the code will become hard to follow
and harder still to organize, since you will need to keep track of
pointers to a large number or widgets (passing them hither to hook up
callbacks, passing them yon to put them in the hierarchy, display
them, etc.), which whenever possible is something I like to avoid,
since GTK keeps track of that sort of thing for me. It also seems the
most intuitive system of organization.
Have fun,
Alem.
2005/8/14, MEA-MikeFriedrichs <[EMAIL PROTECTED]>:
> List,
>
> Accidentally hit the send button too soon.
>
> I'm beginning to learn and use GTK+.
>
> Here is the steps that I believe are needed to build an GTK+ application:
>
> 1. Initialize the library.
> 2. Create widgets and set attributes.
> 3. Register callback routines.
> 4. Define widget hierarchy.
> 5. Show widgets.
> 6. Process signals and events.
> 7. Quitting
>
> I can see an application becoming very large in one module. So I would
> like to break the program into modules, where each module can be managed
> and compiled independently and finally link all the modules together. But
> I don't see any divisions because of inter dependency where separate
> modules can be applied. Is this true or am I missing something?
>
> Any recommendations on a modular approach to coding an GTK application?
>
> Thanks,
> MikeF
>
>
>
>
>
> _______________________________________________
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>
_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
