Hi Harry, my program has a lot of I/O (user, TTYS, TCP) and many inputs can cause a consistent update of the GUI, for this reason I opted for accessing the GUI from many threads. This software is for my company (while all my open source apps in GTK are using python) and it's not easy at this point to revolution the software which should be tested in days for the Milan (Italy) underground. Cheers, Giuseppe.
On Sun, Jul 8, 2012 at 2:28 AM, <[email protected]> wrote: > On , Giuseppe Penone <[email protected]> wrote: > > I'm not very experienced in c++ and gtkmm > > Hi Giuseppe! I'm not a Gtkmm wizard, but from my experience its best to > leave all graphics drawing calls to one thread. > That thread we will call "main" thread, and its the thread that runs into > Gtk::Main::run(), after which your programs UI shows. > All other work ( I don't know what the context is of your program, but > lets say its downloading something) should be done in a worker thread. This > can signal to the Gtk::Main thread, and perhaps use a Glib::Mutex for > serializing data access. > > Since you have to serialize all graphics calls anyway (that's what the GDK > lock does), there's no point in having different threads doing the > graphics: only 1 will run at a time. > > I know this was slightly OT, but I found I asked many similar questions to > yours when I was starting out with Gtkmm so I hope its relevant... -Harry
_______________________________________________ gtkmm-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gtkmm-list
