It would definitely be a great thing is GRC was slightly more language agnostic!
On Thu, Jul 30, 2015 at 6:21 PM, Tom Rondeau <t...@trondeau.com> wrote: > On Thu, Jul 23, 2015 at 4:06 PM, Volker Schroer <dl1...@gmx.de> wrote: >> >> Tom, >> >> thank you for your comments. >> >> I agree to your objection that android is java based. But I think most of >> the gnuradio users ( not developers ) are not willing (or not able ) to >> code in java. gnuradio is python based at least to glue blocks together. >> >> So my conclusion would be : either support python on android or to >> generate java code from grc. >> But I'm unsure which of the many approaches of python for android will >> win, if any. >> >> Nevertheless both would require gnuradio based on qt5. >> >> I just ported some other qt4 based projects to qt5 and it wasn't really a >> great problem. >> So I'd try contribute to migrate gnuradio to qt5. >> >> But some questions: Do you intend to use PyQt4 ( which should support qt5, >> too) or do you plan PyQt5 ? And which would be the best gnuradio repository >> to start from ? >> >> -- Volker > > > We plan on moving to QT5 and therefore support PyQT5. But this is the kind > of change that will happen only with a new API release (3.8) because it's a > change in the dependencies. We haven't made any moves on this, yet, but the > plan is to switch over. Having done some QT5/QT4 work recently, it looks > like the changes are fairly minimal and mostly semantic, so moving shouldn't > be a huge deal from that perspective. > > As for the Java/Python issue, we're working under the assumption that we > split the design process between C++ and Java. GNU Radio in this case will > exist in the C++ level and build using the Android NDK. The application is a > fairly separate piece that provides the user interface such as controls and > ways to visualize and interact with the radio. > > The benefit of this approach is that we provide two domains of expertise. > GNU Radio on one level and App development on the other level. App > developers will be more used to Java and all of the tools, techniques, and > libraries out there for Android are Java based. They need to know little to > nothing about radio, and the radio developers need to know little to nothing > about app design and development. This just needs a defined interface > between the two domains. Currently, my GrTemplate assumes everything is > going through the JNI. That's what my paper and demo at SRIF will be about > in September. > > However, we're moving to a new model to make this separation work better, > but that's still under development. We want all command and control to go > over ControlPort, and we'll be using ZMQ for any time we might need to > stream data. ControlPort is great for snapshots of data and setting and > getting of parameters in a flowgraph, but isn't designed for streaming. And > we have some plans in mind for streamlining all of this to avoid dependency > overload. > > I have a ControlPort client setup done in Java now for Android apps, and > I'll be pushing that out publicly soon (hopefully next week). This will > allow us to easily bridge between app-space and gnuradio-space. The extra > benefit of this is decoupling those two in general, not just for Android. > The example app that I'm working on is a Performance Monitor tool for > Android, so you can use your Android phone/tablet to connect to a running > flowgraph elsewhere for monitoring purposes. > > The main reason for this is to acknowledge that we're generally not the > right people to be designing apps and user interfaces. I'd rather people who > do that well work on that level, and so we are trying to remove for them the > burden of having to work with GNU Radio. All they will hopefully need is the > interfaces agreed upon between the radio designer and the app designer. > > One of the main things that I see we need to have happen here is to have GRC > produce C++ flowgraphs that will be able to fit into the model that the NDK > needs. > > Tom > > > >> >> >> Am 23.07.2015 um 15:43 schrieb Tom Rondeau: >> >> On Wed, Jul 22, 2015 at 4:47 PM, Volker Schroer <dl1...@gmx.de> wrote: >>> >>> Hi! >>> I watched the development of gnuradio for android. But I'm not very >>> familiar with java, so I searched for a way to run gnuradio python scripts >>> without or with little modifications on android. >>> >>> I detected the python_for_android project and wrote some recipes to run >>> gnuradio on android. >>> >>> For those who are interested , see: >>> https://github.com/dl1ksv/python-for-android >>> >>> At the moment I'm able to run things like >>> >>> dial_tone or an fm receiver using the rtl dongle. >>> >>> But there are a lot of things missing, in particular a gui, support of >>> fcd(pro+), etc. >>> >>> So my question: Where to go from here: Introducing kivy to gnuradio for >>> building gui's , or migrating qt5 ( a way I'd prefer ) >>> Or is this only a nice finger exercise and of no special interest ? >>> >>> Comments are welcome >>> >>> -- Volker >> >> >> Volker, >> >> This is awesome that you're working on this and sharing your progress. Two >> things. >> >> First, I think the QT5 way is where you'd want to go. We will be migrating >> there, anyways, likely for the 3.8 release. Having done some work recently >> on the gr_filter_design tool in QT4/5, it's not a huge amount of work to go >> between them. We'll likely do this work off the next branch for the next API >> version release. Anything you can contribute to this effort would be great. >> >> As to Python, I'm skeptical how fruitful this path really is. If it's just >> for your own stuff, that's one thing, but Android is Java, love it or hate >> it. Trying to work too far away from their structure of work is dangerous, >> since they can decide at any moment to just kill certain efforts -- I'm a >> little afraid of this myself with our reliance on the NDK, even. >> >> I'm in the boat of learning Java myself to work in this world. Easier that >> than trying to force other modes of operation onto this beast. >> >> Tom >> >> >> > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio