GRC Roadmap

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 - done)
    • 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

Block management

  • Multi-page flow-graphs (unassigned)
    • split blocks over multiple pages
    • add off-page connectors
  • Group parameter and variable blocks (Sebastian - WIP)
    • visual those blocks for better overview
  • Better-handling of GRC-produced hier-blocks
  • Make blocks declare requirements* (Sebastian - done)
    • 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
    • Status: implement using the block label (unsafe) and a new tag <flags> in the xml.


  • 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.
  • run flow-graphs remotely (Sebastian - done/need work on GUI integration)
    • bundle them with hier_block2
    • check remote GR version

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)
  • Make drop-down menu for examples
  • recently opened files menu
  • auto generate depending hier blocks from file in the same directory