Re: GSoC 2026 Proposal Feedback Request -"Graphical interoperability between CyberEther and GNU Radio"
Amith Biju <[email protected]> Sun, 29 Mar 2026 19:22:50 +0530
| Newsgroups | gmane.comp.gnu.radio.general |
|---|---|
| Message-ID | <CAFvtwg8SBX_nqhMn=hcrwDYOoXqzrt-7XDu7xQ7a-+9H742XmA@mail.gmail.com> |
--000000000000789761064e2a0d48 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > > Yes, I=E2=80=99m aware of that. > > Since I picked this idea from the GSoC idea page, I mainly focused on > designing CyberEther-powered visualization sinks for GNU Radio, so I didn= =E2=80=99t > go too deep into those limitations in the proposal. > > From what I understand, existing solutions like gr-fosphor are highly > optimized but mainly focused on waterfall and frequency domain plots. > With this approach, the goal is to support multiple types of > visualization sinks using CyberEther. > That said, I do recognize there are limitations in this approach, and I= =E2=80=99m > aiming to build a practical and extensible integration that makes > CyberEther useful within the GNU Radio ecosystem. > > And I also saw recent GNU Radio Conference talks (2021=E2=80=932023) on > CyberEther, where future plans to integrate CyberEther with Qt for use in > GNU Radio were discussed, and with that consideration I made the proposal > in this direction. > > Also, regarding the MSVC/clang-cl compatibility issue, I understand this > could be a limitation for full integration into GNU Radio. For now, I was > mainly considering a Linux based environment where CyberEther is supporte= d > and focusing on building a working pipeline first. Cross platform support > can be explored later depending on feasibility . > > Would like to know if this approach is reasonable for the project scope. --000000000000789761064e2a0d48 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_quote gmail_quote_container"><blockquo= te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px = solid rgb(204,204,204);padding-left:1ex"><br>Yes, I=E2=80=99m aware of that= .<br><br>Since I picked this idea from the GSoC idea page, I mainly focused= on designing CyberEther-powered visualization sinks for GNU Radio, so I di= dn=E2=80=99t go too deep into those limitations in the proposal.<br><br>Fro= m what I understand, existing solutions like gr-fosphor are highly optimize= d but mainly focused on=C2=A0 waterfall and frequency domain=C2=A0 plots. W= ith this approach, the goal is to support multiple types of visualization= =C2=A0sinks using CyberEther.</blockquote><blockquote class=3D"gmail_quote"= style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p= adding-left:1ex"><br>That said, I do recognize there are limitations in thi= s approach, and I=E2=80=99m aiming to build a practical and extensible inte= gration that makes CyberEther useful within the GNU Radio ecosystem.<br><br= >And I also saw recent GNU Radio Conference talks (2021=E2=80=932023) on Cy= berEther, where future plans to integrate CyberEther with Qt for use in GNU= Radio were discussed, and with that consideration I made the proposal in t= his direction.<br><br>Also, regarding the MSVC/clang-cl compatibility issue= , I understand this could be a limitation for full integration into GNU Rad= io. For now, I was mainly considering a Linux based environment where Cyber= Ether is supported and focusing on building a working pipeline first. Cross= platform support can be explored later depending on feasibility .<br><br>W= ould like to know if this approach is reasonable for the project scope. </blockquote></div></div> --000000000000789761064e2a0d48--