Hi James, I really appreciated to read your experiences. Thanks for sharing them!
JAMES SCOTT wrote: > This response may be a little off topic. But as I have followed this thread > I understand your are moving some application to linux from MS. Moreso, you > are planning on using gtk to get that port done. Here is a little of my > experience with gtk threaded program design. In fact I am currently evaluating the way I have to go when doing my port. I currently see three options: - using the Free Pascal Compiler together with Lazarus (the original program is written in Delphi) - using the g++ compiler together with QT - using the g++ compiler together with GLib/Gtk or GLibmm/Gtkmm At the moment the last option seems to be the most attractive one. But I will not make the decision alone, instead my task is to make a solid proposal and show it to the rest of our developers. > 1. having gtk thread security features turned on is required if you > plan to call gtk_ api's from more than one thread: Which you > should NOT try to do. > [...] Yes, indeed I plan to use only the main thread for GUI stuff. That fits well with the program design I'm usually using. > 2. Spend some time devising a way to collect data values that need to > be visually represented in gtk inside a container or memory > structure that you can g_new0() allocate. > 1. Then pass that pointer from the background thread to the > foreground GTK main thread for display or updating > 1. maybe using GAsyncQueue to pass the pointers > [...] > > 3. For gtk main thread to background thread interchanges look over > the g_idle/g_timeout set of apis and potentially > g_io_channel/watch apis; along with g_mutex 'es where needed. > [...] I think that this can be a good substitute for the SendMessage/PostMessage functions I used. > 4. If you look at how gtk suggest you setup for multi-threaded > program, it describes wrapping the call to gtk_main() with ( > gdk_threads_enter(); gtk_init(); > gtk_window...;gtk_main();gtk_threads_exit() ). What is not so > obvious is that this protects most callback except for > g_timeout... g_thread... based functions; as those callbacks > occur inside the current gtk_main loop. > 1. You need to consider using gdk_threads_enter/exit in any > g_timeout/g_thread/g_io_ based routine > 2. if you follow me thus far, then you will never call a > gtk/gdk routine from outside the gtk_main loop or thread; > except for maybe g_io_watch based functions. I'm not sure if have understood this but as described above I will try to follow 4.2 here :-) > 5. Socket based, and other OTHER PROCESS, communication wheter a pipe > or a socket or orther mechanism may lend itself to g_io_channel > and g_io_watch based apis. > [...] Yes, most probably I will add private instances to some threads with g_main_loop_new()/g_main_context_new(). > 6. Finally, be careful how you implement or use classic unix > signals: Danger, Danger Will Robinson.. Is it possible to work with signals if they are only handled by the main thread? Anyway I'm not sure if I will need signals at all... > I can not stress enough that you need to buy the book, readit, and > workout some off-project tests before pounding out a ported > application. You will find gtk/glib to have a rich set of widgets and > programming constructs that make using it almost fun. Of course I will start with some small concept evaluations before doing the whole port. What do you mean with "the book"? Which book(s) would you recommend for Gtk/GLib or even Gtkmm/GLibmm programming? > I hope some of what I've said help your quest. Your comments helped me a lot. Thanks again! /Tobias -- NOA Audio Solutions Vertriebsges .m.b.H. Tel: +43-1-5452700 Johannagasse 42/4 Fax: +43-1-545270014 A - 1050 Wien Www: http://www.noa-audio.com _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
