Re: [Discuss-gnuradio] Summary of desires for GRC, just discuss on the #ghuradio channel

[Aditya Dhananjay]

On Wed, Oct 2, 2013 at 3:16 PM, Ethan Trewhitt <address@hidden> wrote:

On Wed, Oct 2, 2013 at 3:03 PM, Marcus Leech <address@hidden> 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 lar

ger 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

Some more, if I may: Make sure the 'wires' are always visible, and are not hidden behind blocks. And that two or more wires cannot 'overlap' on the screen.

When two blocks are connected using a 'wire', and the wire needs to bend, display the bend in the wire in a rounded manner. This way, it is easily distinguishable from two wires that merely cross over. When the screen is tightly packet with blocks, it gets visually confusing. Thanks!