Reading the post about Googles’s SoC it reminded me of an idea had for
quite a while:
Imagine a graphical interface to Gnuradio where all python blocks are
represented by some widget, with name, parameters, description/doc and
the like. On the left side fo an widget you’ve some docking nodes for
input, on the right side nodes for output. All available blocks are
presented in a toolbar. You create a flowgraph (like a “work space”) and
drag the blocks onto the flowgraph. The new inserted block is initially
named <block_type>_, which you’ll probably change at first. To
connect blocks, just click on a input or output docking node and drag to
the corresponding docking node on a different block to do a
flowgraph.connect(). To change options, simply click on the option and
edit, or create some “data type” block, which holds the value and would
be connected to some block’s options.
The interface does sanity checks while you build your application, maybe
even constructs a working flowgraph on the fly, and runs it. If an error
occurs the user is notified.
I hope it’s clear what I mean: graphical programming. I’m not sure if
Python supports enough reflection to give information about the block
properties, so no explicit description has to be written for each and
every block. With good python docstrings help can be context sensitive.
Perhaps people with wxGlade experience have an idea how to connect a
wxWidgets interface to the Application Builder.
Something I’ve not sorted out is saving: Should the Application Build
generate python code or some description format? Where should metadata
(position, description) go (comments, metadata file)? What about
reading/parsing handwritten apps?
Engineers motto: cheap, good, fast: choose any two
Student of Telematik, Techn. University Graz, Austria