Hi Suryasaradhi, Thanks for reaching out!
I agree with Marcus' comments here, they seem like nice features that I consider suitable for GRC. Please feel free to open a (draft) PR if you already have some working code, it will probably get you more feedback than having it spread across a few commits on your fork :) Are you planning to implement any other features as your GSoC project? Looking forward to reading your proposal! Best regards Håkon Vågsether On Wed, Mar 18, 2026, 17:22 Marcus Müller <[email protected]> wrote: > 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 > >
