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.
- 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
- Make blocks declare requirements*
- A more sophisticated solution would be to make blocks declare requirements (such as "I need QT GUI"), which GRC then automatically applies.
- This would enable a static check to catch and highlight problems such as:
- WX GUI is selected, but a QT GUI Frequency sink is used
- Both WX and QT blocks are used
- 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¶
- 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() (Sebastian - done)
- Make drop-down menu for examples
- Importing a fg with invalid blocks gives a greyed-out block instead of nothing at all (Sebastian - done)
- Snap-to-grid allowing easier alignment of blocks and connections