Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
On Wed, Oct 2, 2013 at 3:03 PM, Marcus L. [email protected] wrote:
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 
On Wed, Oct 2, 2013 at 3:16 PM, Ethan Trewhitt
[email protected]wrote:
o some kind of “organizer” for parameters and variables
- Some mechanism that allows compiled .py files to avoid having
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
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!
Another feature that would be good for newbies: Like Tracie mentioned
yesterday, when I first jumped into GR earlier this year, my first
move was to run GRC and start playing with some graphs. Unfortunately
it was really hard to figure out where any examples were - and some of
the existing .grc files bundled with GR (at least at the time) didn’t
even work.
I say we take a page out of the Arduino IDE book (see also: NetLogo)
and add a File, Examples menu item. This would provide the user with a
list of example GRC graphs, grouped by module or some other criterion.
A prerequisite to supporting this would be to provide a standardized
method for in-tree and OOT modules to indicate where their examples
were stored. Arduino does this by simply expecting any 3rd-party
libraries to have an “examples” subdirectory; it then adds those to
the friendly list.
o off-page connectors – for managing large flow-graphs
I thought this was covered by virtual sinks and sources. Maybe that’s
somebody’s custom block.
o some kind of “organizer” for parameters and variables
I’ll take one of those, please. I can see how it might be a tricky
feature
though. Do you aggregate existing variables, but allow editing/viewing
them from a single pane, or just scrap it all and have one
multi-variable
block?
o A way to make “Note” blocks larger and maybe multi-line
Notes are cool, but their context can be easily lost when moving blocks
around. I always thought that each block ought to have a “comment”
field
among the other properties, which is just a dumb text blob. When you
generate the python, this could even be inserted as a real python
comment.
I can’t say how many times I’ve opened a block and thought, why is that
property set to that value? A contextual comment for the block would
help
there I think. If you want to get really crazy, you could even display
a
truncated version of it on the block itself in the FG, the same way
values
are shown.
Very Respectfully,
Dan CaJacob
On Wed, Oct 2, 2013 at 3:03 PM, Marcus L. [email protected] wrote:
Just a quick summary of the “things people would like” to see in GRC:
o off-page connectors – for managing large flow-graphs
This would just enable Balint’s addiction.
o better-handling of GRC-produced hier-blocks
o allow blocks to be in more than one category
This is already possible. Like the “Message Debug” block is in both
“Debug Tools” and “Message Tools”.
o make searching “easier”
o integrate Doxygen block documentation better
This was one of the GSoC projects.
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
Aside from that, these are all good suggestions. There will be some
work on GRC at the hackfest on Friday. Hopefully this will all get
recorded and we can make this a sustained effort.
Thanks,
Tom
o some kind of “organizer” for parameters and variables
I’ll take one of those, please. I can see how it might be a tricky
feature though. Do you aggregate existing variables, but allow
editing/viewing them from a single pane, or just scrap it all and have one
multi-variable block?
I would go with simply either adding a new multi-variable block, or
modifying the existing one to allow multiple variables. Don’t do any
‘automatic’ variable aggregation.
truncated version of it on the block itself in the FG, the same way values
are shown.
I second the request for a ‘notes’ field for all blocks, but also want
to
have a more flexible ‘note’ block. Ideally, it would support
multi-line
(HTML-formatted?) text, and allow setting the size/shape manually.
-Greg
Stable system that does not keep changing on a monthly basis?
On Thu, Oct 3, 2013 at 9:35 AM, Gregory W. [email protected] wrote:
I would go with simply either adding a new multi-variable block, or
modifying the existing one to allow multiple variables. Don’t do any
‘automatic’ variable aggregation.
I agree that it shouldn’t be automatic. I was thinking something like:
- Select a bunch of blocks
- Choose “create group”
- A new “group” symbol appears (visually like three rectangles in a
stack, viewed from above) - The previously selected blocks are moved “into” the group
- If you double-click the group, a box is displayed over the current
graph that lets you see its contents.
For the open group, I’m imagining something like a toolbox-style box
that can be dragged around the graph (and left open), complete with a
little grey title bar and a minimize button that restores it to its
“icon” state. That way you can leave it open and work with it until
you’re done, then minimize it to its icon form when you’ve finished
working with its contents.
I can only imagine this making sense for blocks that don’t need any
I/O - or even perhaps for blocks that only have connections among each
other. Visually showing connections going into or out of a group might
be tricky.
Ethan
Slick, I always seem to end up with long linear chains of blocks that
need
duplication on the page, your grouping mechanism could save me from
having
to make so many custom hier blocks.
Jared