[Mono-devel-list] Running MWF/SWF and GTK# in the same process with the same mainloop

Zac Bowling zac at zacbowling.com
Mon Mar 28 19:29:05 EST 2005

One challenge that I keep hearing about mixing both Gui's in the same
application is that people really don't understand the mainloop
differences between SWF and GTK#/GLib#. I was wondering this myself when
I started my work on a way of hosting a MWF control in a GTK#
application. Its really not all that hard as I though after
investigating the differences between the two. In-fact its very easy to
hack a solution in just a few lines of code without the use of threads. 

You can do something as simple as:

        public static bool Shutdown = false;
        public static void Main()
            // Initialize and show everything you need too.

            // Nasty but simple dual SWF/GTK# mainloop
            // Close anything left open.

This is far from the best solution. This will bypass all the
optimization in the MWF/SWF main loop and eat away at the processor. 

Another issue, that takes some understanding of how the DoEvents and
RunIteration functions really work. DoEvents will allow the application
to block the code at its current point and process any messages in its
message queue in order they are in, in the MWF queue and if there are
none it just keeps running. The RunIteration(false) function will do the
same except that it will only run it once. A better solution is to wrap
that into its one while loop and keep running until are events are
finished for GTK# but I'm not going into that here. The issue with the
example above is that both use a queue for their events/messages that
need to be processed, but its not the same queue. That means that if 3
things are in the queue that just took place in the Gtk# loop, they
could running before any event that took place after in the SWF/MWF

If anyone wants to tinker with it or has any ideas on writting a mixed
GTK#/SWF queue it would be interesting to hear :).

Hope that helps and sparks peoples interests.


More information about the Mono-devel-list mailing list