RE: gtk main and slemr main

[Matt Eisemann <meisemann dsrnet com>]

Currently owr company uses a product called middleware, which as its name 
suggests runs between the application and the hardware so that one can run 
a sigal application on many different hardware platforms and the code does 
not have to be hardware dependant.  That said, our middleware 'main' loop 
is used for callbacks similar to gtk's main loop.  It other words, I can 
register for various message id's and when I go into the middleware 'main' 
loop, I wait on the network until one of my registered message id's comes 
to me.  When a msg id comes to me that I have registered for, my 
application will go into a msg_callback function which starts a function 
very similar to gtk's gtk_signal_connect, when a user pushes a button, but 
my messages are coming to me via the network either through tcp or udp 
ports (as far as I know).  Maybe I don't know a lot about sockets and how 
they work with tcp/ip and udp/ip but how could I use sockets or 
gtk_idle_add or some feature since I have two loops which I can not clearly 
have.

  gtk_main()
  middleware_main()

  I have to keep track of which messages are being sent to me that I 
registered for on the network in addition to the callbacks for the GTK+ GUI 
buttons and events there.
  Any ideas or suggestion are greatly welcome.  Thanks.

  Matt



-----Original Message-----
From:	otaylor redhat com [SMTP:otaylor redhat com]
Sent:	Friday, October 06, 2000 1:06 PM
To:	Matt Eisemann
Cc:	Massato Dom (SMTP); gtk-list gnome org; Murphy Rodney (SMTP)
Subject:	Re: gtk main and slemr main


Every CORBA implementation I'm aware of provides the ability
to use an external event loop for getting notification when
file descriptors that are ready for reading.

Integrating this type of thing with GTK+ is easy - when
the library requests notification on a file descriptor,
you use g_io_add_watch ().

I'm not familiar with the "Middleware" application/library
that you are talking about, but adding this capability should
be reasonably easy if it doesn't already have it. (And this
feature is really a requirement for any serious library
of this sort.)

GTK+'s main loop is not designed to be used as a slave main
loop - basically because GTK+ expects a better and more flexible
main loop than would be provided by most other libraries.
So the approach of trying to check for GTK+ events occasionally
is not going to work reliably, though people have sort of hacked
to to work when really desparate.

Regards,
                                        Owen

Matt Eisemann <meisemann dsrnet com> writes:

> There may be a problem with using gtk and middleware together in the same 
> application.  I was talking with Tom Phelan and he said that I can't have 
> two main loops even though they are both waiting for different events to
> occur.  He mentioned some potenntially tricky scenarios.  One, that they
> did in Middleware once to solve this dilemma was to modify the middleware 
> main loop and include the other event check in it, which probably is not 
a
> great solution.  For example, the following is
>
> MWLOOP
> {
>   while(1)
>   {
>    middleware event_check;
>    gtk event check
>   }
> }
>
> Secondly, I could create my own task loop and get the function calls that 
> middlware uses and then include the API's that gtk_main() uses.  For
> example,
> somethine like.
>
> While(1)
> {
>   middleware event check;
>   gtk event check;
> }
>
> If gtk does not provide the source code or API's to gtk_main, I don't see 
> how I am going to use middleware and gtk together.  Either way, this is
> going to increase my project time since I am going to have to do some

[ Of course, the source code to gtk_main() is available, like
  the source to the rest of GTK+ ]