Your problem description indicates very strongly that this is perhaps an initial foray into GUI programming. Before jumping into the deep-end of event-driven GUI interfaces, there is one very important design consideration of which you should be aware. GUI design and programming basically comes down to this: 1. Once you decide to make any program GUI-enabled, you must shift your understanding as to the hierarchies of priorities. That is, in GUI-land, the end-user is king. If you do not design and program based upon this single assumption, your program will probably not work very well, and thus, not be used very much. (Nobody but nobody gets lucky in creating a successful user interface (and resulting experience) while not accepting this absolute fact of reality; if the point of the program is not the end-user, then the end-user won't use the program.) (Think EGO, and it all becomes clear.) (The one exception I might consider to this rule is where you, yourself, are the only end-user you are programming for, but how many programs does this constitute in the world?) So, while you think that the gtk main loop "hangs", it is actually following #1 above: listening to all the various input channels (it has been configured to listen to, and more) and responding accordingly when anything is received. These input channels mostly relate to human input/actions, but not necessarily. In your case, your simulator must become a background task to the GUI front-end; while it is the "point" of your program, it isn't as far as the mainloop is concerned. You do this by starting the simulator as a separate thread at program startup (i.e., in the background), and then enter the main loop (i.e., in the foreground), waiting for activity. Once the simulator has done something and requires a result to be displayed (i.e., sent to the end-user), use the g_idle_add() function from within the simulator. This will insert an event into the main loop and will have the function you provided to g_idle_add() be executed. That is, by using g_idle_add(), you create your own input channel to the main loop, originating from your background thread, the simulator. In other words, your program has two distinct aspects and priorities, your background thread responsible for making data, and your foreground thread (the mainloop) responsible for interactions with the human and drawing to the screen. The point of all this is: the mainloop thread is now the boss, not your simulator. Trying to turn this upside down (and modifying the main loop code directly to force it) will cause you great struggle and strife, most likely resulting in much hair loss, cursing, all coupled with a very low likelihood of success. As well as the mainloop documentation already provided, read up on threads (GLIB), g_idle_add(), as well as the many previous posts on this subject. have fun, richard On Jan 7, 2008 12:49 AM, Saravana Kumar <Saravana.Kumar@xxxxxxxxxxx> wrote: > I am trying to develop a GUI for using it with Verilog Simulator. > > Verilog Simulator will invoke this main function in my application code and > which in turn will call gtk_main function. > > Whenever it reaches gtk_main, the simulator hangs forever till I do a > key/button press. This should not happen since verilog simulator should run > independent of this main function call. So I thought of modifying gtk_main > function little bit to avoid zero delay loop(which is currently happening in > while statement inside gtk_main function and so the simulator hangs). There are more reasonable options at your disposal as yours is not an uncommon need. I believe giving a good thorough reading to this document in the documentation will help you understand what your options are: http://library.gnome.org/devel/glib/stable/glib-The-Main-Event-Loop.html _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
