Re: [Discuss-gnuradio] Mac gui

[Marcus Müller]

Hi Albin,

the point is that Sylvain is right, building your own visualization GNU 
Radio blocks is harder than using the data GR gives you in an 
application, only communicating the results in and out. That's basically 
because every GUI toolkit has its own idea of how to handle threading 
and needs to be the one that controls certain aspects of program 
execution (basically, GUI toolkits need to hog the main loop). Hence, 
the integration between for example Qt and GNU Radio needs to be quite 
tight in order to make it possible to run Qt visualizations; it won't be 
much easier with Cocoa.

Regarding IPC ringbuffer: try the gr-zeromq blocks that come with the 
recent versions of GNU Radio. They work reliably, and take any zeromq 
"URL", which includes shared memory IPC urls.

Best regards,
Marcus

On 15.07.2015 13:47, Albin Stigö wrote:
> Hi Marcus,
>
> Thanks for your reply.
>
> This is just hacking for fun and I plan to put any code I produce on
> github so im not really concerned about licensing at the moment...
>
> The idea was to make the instrumentation blocks work well and native
> on mac... I was also looking into hacking the gnuradio-companion to
> work better on mac (it doesn't work well on retina displays).
>
> I will look into fifos! I was also thinking about some kind of shared
> memory IPC ringbuffer...
>
> --Albin
>
> On Wed, Jul 15, 2015 at 1:10 PM, Marcus Müller <address@hidden> wrote:
> > Hi Albin,
> >
> > GUI interaction is usually a bit tricky. Generally, GNU Radio is also meant
> > to be used as a library that your main application uses for signal
> > processing, and you can get the raw samples in and out of your GNU Radio
> > flowgraph from any native application, but I don't really think that's what
> > you'd start off with.
> >
> > If I had a recommendation: start off with the guided tutorials and the Qt
> > visualizations in there. As a pretty easy, and in many cases performant
> > enough, solution, use sockets, named FIFOs or ZMQ sinks/sources to exchange
> > data between your Cocoa (or whatever) application and your (headless) GNU
> > Radio application, running as a separate process. That makes building,
> > modifying and debugging your signal processing separately from your GUI much
> > easier, imho.
> >
> > By the way, I think there might be some licensing issues if you link cocoa
> > code against GPL'ed code, but that's basically only relevant if you start
> > selling/distributing your program; if you just use a communication interface
> > (rather than dirtectly linking against GNU Radio) you'd have two separate
> > programs, which would inherently solve the licensing problem (you'd only
> > need to guarantee your customers'/ software receivers' freedom to get,
> > modify and distribute the source code for the GPL program).
> >
> > Best regards,
> > Marcus
> >
> >
> >
> > On 15.07.2015 12:43, Albin Stigö wrote:
> > > Hi,
> > >
> > > I'm pretty new to gnuradio so please bear with me if I have missed
> > > something.
> > >
> > > I finally managed to get everything up and running on my macbook pro
> > > yesterday (with funcube dongle pro+) and experimented with building an
> > > out of tree block.
> > >
> > > I'm interested in writing some instrumentation blocks using native os
> > > x gui apis (cocoa and opengl). I was wondering if anyone has
> > > experimented with this..? The way cocoa works makes it a bit difficult
> > > to load a gui from dynamic library. I was thinking about starting
> > > another process from the block and then supplying it with data via
> > > some ipc mechanism... Has anyone done some work in this area?
> > >
> > >
> > >
> > > --Albin
> > >
> > > _______________________________________________
> > > Discuss-gnuradio mailing list
> > > address@hidden
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> >
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > address@hidden
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio