Re: [GSoC] GRC UI Improvements: Sub-flowgraphs and M ini-map Prototype – Request for Feedback
Håkon Vågsether <[email protected]> Sat, 21 Mar 2026 00:30:05 +0100
| Newsgroups | gmane.comp.gnu.radio.general |
|---|---|
| Message-ID | <CAOyNdBTt_QdocrTd91qPQZpzVAfM79bzeC=jEZRR31h8CAAZNQ@mail.gmail.com> |
--0000000000003a5523064d7d116c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=C3=A5kon V=C3=A5gsether On Wed, Mar 18, 2026, 17:22 Marcus M=C3=BCller <[email protected]> wrot= e: > 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 an= d > 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=C3=A5kon on that, who tries to keep GRC together and movi= ng 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 it= s > 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 i= n > 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 =E2=80=93 as grumpy o= ld > 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 conflic= t > 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=E2=80=99s 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 yo= u > haven't, > please, read through, really from start to finish, of > https://wiki.gnuradio.org/index.php?title=3DGSoCStudentInfo ) > > 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 > > --0000000000003a5523064d7d116c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div>Hi Suryasaradhi,=C2=A0</div><div dir=3D"auto"><br></= div><div dir=3D"auto">Thanks for reaching out!</div><div dir=3D"auto"><br><= /div><div dir=3D"auto">I agree with Marcus' comments here, they seem li= ke 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 y= ou more feedback than having it spread across a few commits on your fork :)= =C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">Are you planning = to implement any other features as your GSoC project?=C2=A0</div><div dir= =3D"auto"><br></div><div dir=3D"auto">Looking forward to reading your propo= sal!=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">Best regards= =C2=A0</div><div dir=3D"auto">H=C3=A5kon V=C3=A5gsether=C2=A0</div><div dir= =3D"auto"><br></div><div dir=3D"auto"><br><div class=3D"gmail_quote gmail_q= uote_container" dir=3D"auto"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, = Mar 18, 2026, 17:22 Marcus M=C3=BCller <<a href=3D"mailto:mmueller@gnura= dio.org">[email protected]</a>> wrote:<br></div><blockquote class=3D= "gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding= -left:1ex">Hi Suryasaradhi,<br> <br> welcome to the community!<br> Thanks for being part of the GSoC candidates!<br> <br> I'll very likely not be your mentor, but I think it's great you'= ;re reaching out to discuss <br> your proposal:<br> <br> On 2026-03-18 2:21 AM, B Suryasaradhi wrote:<br> > Both features are currently implemented as working prototypes in GTK a= nd Implementation in <br> > QT is happening.<br> <br> great! We mostly try to focus our development efforts on Qt these days.<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Context<br> > <br> > I am exploring these ideas in the context of contributing to GNU Radio= , potentially as a <br> > GSoC project. Before proceeding further, I wanted to ensure alignment = with the project's <br> > direction and design expectations.<br> <br> great! this is the way to go about discussing GSoC ideas :)<br> <br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Questions<br> >=C2=A0 =C2=A0 =C2=A0Would these features be suitable for integration in= to GRC?<br> <br> I'll defer to H=C3=A5kon on that, who tries to keep GRC together and mo= ving in a consistent <br> direction :)<br> <br> Generally, they seem to be nice features.<br> <br> >=C2=A0 =C2=A0 =C2=A0Are there existing efforts or design discussions re= lated to sub-flowgraphs or<br> >=C2=A0 =C2=A0 =C2=A0navigation improvements that I should align with?<b= r> <br> Sub-Flowgraphs: kind of! We used to have the ability to create hierarchical= blocks fully <br> functional (I remember it having a few rough edges, though. Don't know = its current state!)<br> You show the menu where you can create hierarchical blocks, so you're p= robably aware of <br> that functionality.<br> I think it would be a very good idea discuss in which ways the technical di= fferences <br> between these two, creating a hier block or creating a subgraph, affect how= people can use <br> them. I bet this will pretty much revolve around scope/visibility of object= s! For example, <br> if you have a "Variable" in a GNU Radio flow graph and use a hier= block in that flow <br> graph, the internals don't see (and interfere) with that.<br> That's a big plus for the hier block when it comes to "reusability= ", because all the <br> things you need to transport from the outside in need to be explicitly decl= ared (as <br> "Parameters").<br> You might want to discuss how subgraph address that =E2=80=93 as grumpy old= bug-fixing dude, I'd <br> tend towards "make it very explicit to which variables the subgraph is= sensitive; default <br> to 'none of them'!", but I think that's the extreme there,= and usability indicates you <br> want something closer to "expose all external variables internally, bu= t don't allow <br> objects from the inside to come out, as that would be confusing". But = maybe it's <br> "everything is visible: inside to the outside, outside to the inside o= f a subgraph, <br> everyone needs to take care to look inside their subgraphs when a conflict = appears".<br> <br> As you can see, your proposed feature is interesting, and leads to a design= discussion, <br> that I think should be part of what you need to do within or before GSoC.<b= r> <br> >=C2=A0 =C2=A0 =C2=A0What would be the recommended next step:<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0refining the prototype,<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0adapting it to GRC=E2=80=99s architec= ture,<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0or opening a draft PR for discussion?= <br> Can't really tell you how confident you feel about your code. Point 3),= a draft PR, would <br> imply part 2) has kind of already been done. But: Also a big fan of talking= about actual <br> code instead of code we can't see, so if you feel like you would someon= e review your code, <br> then by all means, just go for it!<br> <br> > I have attached this is a demo video of subflowgraph and minimap. I wo= uld love to complete <br> > this as part of GSOC.Since this idea is not listed in the idea list, I= am looking for <br> > mentors.I have adhered to maintain the code style mentioned in the con= tributors document <br> > of gnuradio. If someone wants to take a look at the code the link is: = github link <br> > <<a href=3D"https://github.com/thesunRider/gnuradio" rel=3D"norefer= rer noreferrer" target=3D"_blank">https://github.com/thesunRider/gnuradio</= a>><br> <br> Then you should probably also start drafting a GSoC proposal! (In case you = haven't, <br> please, read through, really from start to finish, of <br> <a href=3D"https://wiki.gnuradio.org/index.php?title=3DGSoCStudentInfo" rel= =3D"noreferrer noreferrer" target=3D"_blank">https://wiki.gnuradio.org/inde= x.php?title=3DGSoCStudentInfo</a> )<br> <br> Doesn't have to be polished (in fact, most of us would rather read bull= et points than <br> overly polished, overly much text, at this stage), but list what you want t= o do, in which <br> weeks of GSoC.<br> <br> <br> Best regards,<br> Marcus<br> <br> </blockquote></div></div></div> --0000000000003a5523064d7d116c--