On 23:55 Thu 24 Jan , Tor Lillqvist wrote: > > Write wrapper functions for any gtk operation you'd like to execute from > > threads in a way that the thread calls a glib's idle function which does > > the real gtk work. > > An interesting approach. Did you use some automated technique to > generate these wrappers, or just manual work?
It is not automated in the sense of having implemented it into gtk directly. However, I've made a library which of course sets up an architecture with wrappers and callback tables which in turn makes it easier to integrate those gtk widgets I personally had no need for yet. > How well does it work and how general is it? I believe it works well, I've coded an app with several windows, a tree like selection and some 50 complex user interfaces created and deleted on the fly by selecting items from the tree. This app starts algorithms in the background as threads. They all may change widgets simultaneously (like log window entries, displaying images or simply change counters etc.). And it is portable on win32 and linux. > Do you think it would be > generally useful for other people, or is it just for your own specific > need? Hm, from what I read in the mailing lists there seems to be some need to push gtk a bit from the thread-awareness towards the thread-safety. > Are you interested in making your stuff available for others > (and maintain it in the future...)? I'd like to spend some spare time to offer my experience, and the code, too, but I've got to talk to my boss if that is o.k. And there would be the need to separate this library from my win32/linux thread wrapper and keying (handle) system. Do you think it would help to first simply create a draft of the concept as a pdf or so for download ? Are there already plans to make gtk thread-safe (or reasons not to do so) ? As I mentioned it was necessary to wrap even the widgets itself to access their values immediatedly rather than bothering gtk and wait for the return of idle functions. So, the library IS something like a layer on top of gtk rather than something to be easily implemented into gtk. Would it make sense to you to continue this way ? Felix _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
