'waterfallsink.py' uses pipes as an IPC mechanism to get data from one thread (running gnuradio dispatch loop) to another thread (running wxPython's dispatch loop), by creating a pipe and using file_descriptor_sink/source to move the data.
This seems to be a good way to do things, and I'd like to see how well it fits in a more general case. One could implement the 'data plane' of one's application as a set of gnuradio blocks that implement all the signal processing, and have a set of pipes that output various display updates. The user interface code could select() on these pipes and handle updating the various GUI elements after reading the available data. For control, having the GUI code invoke public methods on the gnuradio blocks seems ok, bearing in mind any inter-thread data access locking required. Aside from select not working with pipes on Win32, does this seem like a good application structure? How have people dealt with the separation of user interface and data flow in a scalable way? -Johnathan (wanting to think about something besides autotools!) _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
