There's an argument to be made for this. It'll go into the thinking
about the refactoring of the code.
blks2impl must be burned
I think the structure in the gr-noaa directory is a good example of how
to organize a set of related blocks and applications.
There is also the concept of using SWIG's XML output for the GRC
files. I've only played around a bit with them, but it's something to
look into if you haven't already. It looks like it captures _most_ of
the information about the blocks that is exposed in the GRC xml files.
It's fairly expressive output, so we'd have to see if it actually
covers everything necessary for GRC to use with updated parsing.
Have you already looked at, and dismissed, this, Josh?
I have not looked at nor have I dismissed the possibility. There are
certain visually appealing things you can do like hiding parameters that
dont matter when another parameter is set, or grouping two similar
blocks that have different outputs. I believe that there is no general
abstraction on how to do this and that generated xml files will be
somewhat lacking. That said, maybe generating the xml files might be
useful for enough of the blocks that its worth figuring out. Maybe we
can have a middle ground and find a way to generate the xml and leave a
place to get extra block specific information into the generator.
Basically, I will take a look at the SWIG XML when I get the chance.
-Josh
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
