Re: [Discuss-gnuradio] Mac gui

[Albin Stigö]

Sylvain & Marcus,

I know about gqrx but at the moment I'm not looking into making a nice
polished app like that... What I'd really like is to make
gnuradio-companion work well on os x with native instrumentation...
I'm thinking about porting the companion to cocoa. Then thing is I
would need to write some blocks that call cocoa code.. And it's a bit
hard to put cocoa code in the blocks. Then I think it would be
somewhat easier to write a simple sink block that starts some cocoa
app and pushes data to it... So what I'm really looking for is what
IPC mechanism to choose I guess.

I will dig into the gnuradio runtime code as I can see I really need a
deeper understanding of it.

--A

On Wed, Jul 15, 2015 at 1:47 PM, Albin Stigö <address@hidden> 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