Hi Suryasaradhi,
welcome to the community!
Thanks for being part of the GSoC candidates!
I'll very likely not be your mentor, but I think it's great you're reaching out to discuss
your proposal:
On 2026-03-18 2:21 AM, B Suryasaradhi wrote:
Both features are currently implemented as working prototypes in GTK and Implementation in
QT is happening.
great! We mostly try to focus our development efforts on Qt these days.
Context
I am exploring these ideas in the context of contributing to GNU Radio, potentially as a
GSoC project. Before proceeding further, I wanted to ensure alignment with the project's
direction and design expectations.
great! this is the way to go about discussing GSoC ideas :)
Questions
Would these features be suitable for integration into GRC?
I'll defer to Håkon on that, who tries to keep GRC together and moving in a consistent
direction :)
Generally, they seem to be nice features.
Are there existing efforts or design discussions related to sub-flowgraphs
or
navigation improvements that I should align with?
Sub-Flowgraphs: kind of! We used to have the ability to create hierarchical blocks fully
functional (I remember it having a few rough edges, though. Don't know its current state!)
You show the menu where you can create hierarchical blocks, so you're probably aware of
that functionality.
I think it would be a very good idea discuss in which ways the technical differences
between these two, creating a hier block or creating a subgraph, affect how people can use
them. I bet this will pretty much revolve around scope/visibility of objects! For example,
if you have a "Variable" in a GNU Radio flow graph and use a hier block in that flow
graph, the internals don't see (and interfere) with that.
That's a big plus for the hier block when it comes to "reusability", because all the
things you need to transport from the outside in need to be explicitly declared (as
"Parameters").
You might want to discuss how subgraph address that – as grumpy old bug-fixing dude, I'd
tend towards "make it very explicit to which variables the subgraph is sensitive; default
to 'none of them'!", but I think that's the extreme there, and usability indicates you
want something closer to "expose all external variables internally, but don't allow
objects from the inside to come out, as that would be confusing". But maybe it's
"everything is visible: inside to the outside, outside to the inside of a subgraph,
everyone needs to take care to look inside their subgraphs when a conflict appears".
As you can see, your proposed feature is interesting, and leads to a design discussion,
that I think should be part of what you need to do within or before GSoC.
What would be the recommended next step:
refining the prototype,
adapting it to GRC’s architecture,
or opening a draft PR for discussion?
Can't really tell you how confident you feel about your code. Point 3), a draft PR, would
imply part 2) has kind of already been done. But: Also a big fan of talking about actual
code instead of code we can't see, so if you feel like you would someone review your code,
then by all means, just go for it!
I have attached this is a demo video of subflowgraph and minimap. I would love to complete
this as part of GSOC.Since this idea is not listed in the idea list, I am looking for
mentors.I have adhered to maintain the code style mentioned in the contributors document
of gnuradio. If someone wants to take a look at the code the link is: github link
<https://github.com/thesunRider/gnuradio>
Then you should probably also start drafting a GSoC proposal! (In case you haven't,
please, read through, really from start to finish, of
https://wiki.gnuradio.org/index.php?title=GSoCStudentInfo )
Doesn't have to be polished (in fact, most of us would rather read bullet points than
overly polished, overly much text, at this stage), but list what you want to do, in which
weeks of GSoC.
Best regards,
Marcus
