Re: Compilation of gtkmain.c file

["Richard Boaz" <riboaz xs4all nl>]

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 sandisk com> 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