Hi Stef, On Tue, 2012-05-22 at 12:19 +0200, Stef Walter wrote: > On 05/21/2012 04:18 PM, Paul Davis wrote: > > > That claim sounds really strange; since - well - we do that in > > > LibreOffice ourselves :-) ... > Michael, it may just happen that the GTK calls you've seen being > performed from arbitrary threads in LibreOffice don't result in Win32
Wait - we're not using gtk+ on windows :-) we are using our own native VCL toolkit. I'm well aware of the windows constrains on message handling, and thread affinity of some subset of the API. > Even if you get the locking "right" -- even if absolutely only one > thread is executing at once in your process -- like Paul said, you still > get behavior that at a minimum freezes your window, and in other cases > can act a lot like memory corruption. Sure I can believe gtk+ is broken currently in this regard. However my contention is that this is not an inevitable problem for gtk+ caused by the windows API. It is -possible- to get the gtk+ model to work, well, on windows. VCL does it today with a very similar locking model to the one gtk+ has used (again without using gtk+). I would also point out that VCL is not a top-flight, well-maintained, documented, high-quality toolkit with dozens of people working on it either ;-) So the "it is fundamentally impossible to do" argument seems just a bit weak from my perspective, I read it as "it is easier not to do, and it's better to make our API users do the work instead" ;-) which is rather different. ATB, Michael. -- michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list