GRCroadmap: Difference between revisions

From GNU Radio
Jump to navigation Jump to search
(Imported from Redmine)
 
(Fix formatting - html entities)
 
Line 1: Line 1:
= GRC Roadmap =
= 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.
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.


== Usability ==
== Usability ==
Line 55: Line 55:
== Others / Uncategorized ==
== Others / Uncategorized ==


* provide a safe method for blocks object handle to be passed into "helper code"
* provide a safe method for blocks object handle to be passed into "helper code"
** Details? Use-case?
** Details? Use-case?



Latest revision as of 01:35, 21 March 2017

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.

Usability

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

Run-time

  • 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