This is a summary of the "things people would like" to see in GRC. These items are collected from the IRC, the mailing list and the discussions during GRCon13.
- Search (Sebastian - merged)
- make searching "easier"
- Export function (unassigned)
- Rename the menu entry.
- Support vector graphics.
- Possibility to add a legend (of port types)
- GUI builder (unassigned)
- A graphical tool for designing GNU Radio GUIs
- Block implementation language (unassigned)
- Add some indicator for C++, Python. Useful for embedded, I guess.
- Integrate Doxygen (done, but unassigned)
- Open doxygen page for any block in the flow-graph
- Support OOT project documentation
- Status: Code exists. Needs some refinement and testing
- Better notes (Sebastian - WIP)
- make "Note" blocks larger and maybe multi-line
- (maybe) add the option to annotate blocks (show note text beneath), e.g. for examples
- Integrate OOT project development (unassigned)
- The Idea here is the ease the development for projects with custom blocks by adding some some OOT project handling. This includes:
- Identify a GRC file with a OOT module (by its path)
- Auto (re-)load block definitions for the blocks of this module (local blocks)
- GUI for modtool to extend the module (Code exists)
- Allow local blocks to be used w/o install in the generated flow-graph
- Multi-page flow-graphs (unassigned)
- split blocks over multiple pages
- add off-page connectors
- Group parameter and variable blocks (unassigned)
- visual those blocks for better overview
- Better-handling of GRC-produced hier-blocks
- Dynamic flow-graph configuration (unassigned)
- Allow run-time block enable/disable
- Perhaps only at init time, and based on command-line params
- add some way to add code to auto-generated flow graphs
- Details? Use-case?
- Maybe Balint's 'Any Code' block already covers this.
Others / Uncategorized¶
- show 'make' command in tool-tip of blocks
- better-handling of GRC-produced hier-blocks
- allow blocks to be in more than one category
- Should be already possible
- provide a safe method for blocks object handle to be passed into "helper code"
- Details? Use-case?
- Change settings for currently active flow graph, e.g. debugger output level (e.g. if standard log level is ERROR, switch it to INFO for testing)
- Hide some 'expert' settings which are rarely used (e.g. core affinity). Make them accessible through another click, then add more expert options, such as set_tag_propagation_policy()
- Make drop-down menu for examples
- Importing a fg with invalid blocks gives a greyed-out block instead of nothing at all
- Snap-to-grid allowing easier alignment of blocks and connections