|Subject:||Re: [Discuss-gnuradio] Summary of desires for GRC, just discuss on the #ghuradio channel|
|Date:||Wed, 2 Oct 2013 15:22:34 -0400|
On Wed, Oct 2, 2013 at 3:03 PM, Marcus Leech <address@hidden> wrote:
I'd like to add a couple requests for GRCC as well:> Just a quick summary of the "things people would like" to see in GRC:
> o off-page connectors -- for managing large flow-graphs
> o better-handling of GRC-produced hier-blocks
> o allow blocks to be in more than one category
> o make searching "easier"
> o integrate Doxygen block documentation better
> o provide a safe method for blocks object handle to be passed into
> "helper code"
> o some kind of "organizer" for parameters and variables
> o A way to make "Note" blocks larger and maybe multi-line
- The "--directory" parameter should be respected for even for hier
blocks. Right now it's ignored for hier blocks and they're put into
~/.grc_gnuradio no matter what.
- Should work without an accessible X display (I think there's a bug
tracker entry for this already)
- Some mechanism that allows compiled .py files to avoid having
hard-coded references to the "/home/____/.grc_gnuradio/" directory
when referring to custom hier blocks.
A combined feature request for both:
- (Modeled like a modern programming IDE) GRC has the concept of projects
- Projects can contain any number of top blocks and hier blocks
- GRC generates a Makefile when building, then runs that Makefile,
which calls GRCC
This would allow someone to build an entire app ecosystem inside one
GRC window, complete with a build process that allows later users to
compile the .grc files into .py simply by calling "make" on a headless
machine. The goal is to support the paradigm of committing only .grc
files to version control, then treating the .py files as derived
source code not to be committed.
Oh, and finally ... snap to grid :D
|[Prev in Thread]||Current Thread||[Next in Thread]|