On Wed, Oct 2, 2013 at 3:03 PM, Marcus Leech <mle...@ripnet.com> wrote: > 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
I'd like to add a couple requests for GRCC as well: - 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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
