On Sat, 2007-04-07 at 18:06 +1000, Aaron Oxford wrote: > From a purely chump user POV, I don't agree with the idea that it's > my responsibility to use work-arounds to make an API stable on a > not-uncommon target platform. I also can't imagine what amount of > overhead could justify not ensuring this stability when problems are > occuring with Gtk#'s own sample applications - what I'm saying is > that if what I'm observing is in fact the norm, the problem is not > limited to advanced uses of Gtk# or to systems that are particularly unusual.
I'm not sure why we're still having this discussion since I thought my last message stated that I plan to add a fix for the glib thread init issue next week. FWIW, I never meant to imply that workarounds should be added to user code instead of Gtk#. What I meant was that I would rather fix root causes in Gtk# (or its upstream bound libraries), instead of committing things that just seem to fix the problem even though we have no clear understanding of why they fix the problem, or what problem they are actually fixing. Until recently, that was where the Thread.Init "workaround" sat in my mind. Now that I understand why it fixes the problem on win32, why that problem is not a bug in the Gtk+ win32 port, and why the problem doesn't exist on mono on linux, it's clear that Gtk# should be doing that initialization. > >I don't recall that discussion. My recollection was being opposed to > >the overhead of performing that initialization indiscriminately for > >applications that did not intend to use it. > > Are you now saying you've changed your mind? I believe that based on its own usage of multithreading with glib, Gtk# needs to call g_thread_init prior to any other glib calls. That's not exactly changing my mind in the context of the quoted discussion, but I think that's what you are asking. -- Mike Kestner <[EMAIL PROTECTED]> _______________________________________________ Gtk-sharp-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
