|
From: | Josh Blum |
Subject: | Re: [Discuss-gnuradio] Costas parameter in DPSK2 grc block not in .py? |
Date: | Tue, 19 Oct 2010 14:45:45 -0700 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8 |
There's an argument to be made for this. It'll go into the thinking about the refactoring of the code.
blks2impl must be burnedI 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
[Prev in Thread] | Current Thread | [Next in Thread] |