On 20/12/10 20:42, John Hoare wrote: > I feel that I should also mention that the "robot" in question is > essentially a toy, and this library in question is used for students who > have never written code before. (Introduction to Computer Science). > > The user of the library (the CS1 student) writes their own main() > function, and doesn't care about how the GUI works, other than it works. > > If I can't get away with having Fl::wait() in its own thread, can I do > it within a signal handler/timer? > > Perhaps maybe it would be better to follow Greg Ercolano's suggestion, > and fork() off another binary that handles the videoStream(), and > communicates to it through a pipe.
Though fork() per se will not work on win32 either - though you can of course exec another process in a way that's analogous... My worry is that, to make the code reliably portable, we need to ensure that the creation/destruction of window objects is done from within the main() thread... Also, it may be easier to do the key UI interactions from the main() thread too, removing the need to lock() / unlock() from worker threads. How about (and this maybe more trouble than it is worth) providing the GUI elements pre-compiled into static objects that the students just need to call periodically from within their main() loops, without necessarily understanding (at this stage) what the GUI objects are doing. I envisage their would be one object to create the UI elements, and set them running (called once at main() startup), and one (or maybe more) that the students call in their loop to pump the fltk system (probably just needs to call Fl::check() most of the time to keep things pumped along.) All access to/from the UI could be via variables in the global scope... This is not elegant, but might be easy to get up and running, and should work on all host systems in the same way. Any use? -- Ian _______________________________________________ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
