Hi Victor, am I interpreting this correctly: You have a device that you want to control via a GUI slider?
I think a relatively elegant way to have the control interface would be: 1. Making an OOT module; the Guided Tutorials[1], Chapter 3, explain how. 2. use gr_modtool add to add a python class of the "noblock" type 3. that class would mainly have a method, let's call it set_fx(value) that calls; edit the python file from step 2. to include that. Here's where your soft66-control program is being called 4. write a GRC XML descriptor; In essence, copy and paste over the XML file from one of the existing things, for example errrr the constant source. remove all sinks and sources, and only leave one <param> that has a <callback>, which calls your set_fx()! 5. install your module This way, you'd end up having an actual block you can use in GRC. I assume you're actually getting/sending samples to your soft66? How does that interface with GNU Radio? Maybe it would make sense to have a Sink/Source block (like, for example, the USRP sink and source blocks) that encapsulates both the sampling interface and the control interface? Best regards, Marcus [1] http://s.hostalia.de/gr On 31.03.2016 15:14, Vitt Benv wrote: > ... wrong click, I apologize! > > ...... > > def set_base_fx(self, base_fx): > self.base_fx = base_fx > > cmd_string = str(int(self.base_fx)) > # > print cmd_string > > exit_code = subprocess.call(["soft66-control","-t",cmd_string]) > > Qt.QMetaObject.invokeMethod(self._base_fx_line_edit, > "setText", Qt.Q_ARG("QString", eng_notation.num_to_str(self.base_fx))) > self.qtgui_freq_sink_x_0.set_frequency_range(self.base_fx, > self.samp_rate) > > > ....... > > this to set the center frequency of my old soft66 sdr receiver. > > So in future features with trust / hope...! > > tnx again, > so long. > > Victor > > 2016-03-31 15:11 GMT+02:00 Vitt Benv <vitt...@gmail.com > <mailto:vitt...@gmail.com>>: > > Right Marcus I'd found it and it's what I was looking for, tnx! > > About "Python modules", yes, it's a nice features that I'll explore. > > At present I edit top_block.py to paste my code ( only 2 lines...) as: > > ...... > > def set_base_fx(self, base_fx): > self.base_fx = base_fx > > cmd_string = str(int(self.base_fx)) > # > print cmd_string > > exit_code = subprocess.call(["soft66-control","-t",cmd_string]) > > Qt.QMetaObject.invokeMethod(self._base_fx_line_edit, "setText", > Qt.Q_ARG("QString", eng_notation.num_to_str(self.base_fx))) > self.qtgui_freq_sink_x_0.set_frequency_range(self.base_fx, > self.samp_rate) > > 2016-03-31 15:03 GMT+02:00 Marcus Müller <marcus.muel...@ettus.com > <mailto:marcus.muel...@ettus.com>>: > > Hi Victor, > > On 31.03.2016 14 <tel:31.03.2016%2014>:57, Marcus Müller wrote: > > I know there's the Qt Tab widget (look under "GUI widgets"), > but I > > haven't played around with that. > I sent that and realized that typing that took me as long as > it would > have taken me to play around :) > > So, yeah, it's pretty simple: You add a QT GUI Tab widget, > give it an ID > (instead of the default qtgui_tab_widget_0) that you can easily > remember, eg "tabber", and then in your graphical blocks, use > tabber@0, tabber@1 and so on for different tabs. > > If you want to have the widgets grid-layouted inside the tabs, > just > combine the two syntaxes; for example: > tabber@0:0,1,1,1 > > Cheers, > Marcus > > > > Regarding protected python code: > > Well, the problem is that the python code Generator class > re-generates > > the python code from scratch each time and doesn't even try > to read > > what's there already. That really makes debugging the code > generation > > easier; there's no chance some modification might damage the > "stub" code. > > However, it means that modifications don't survive, indeed. > > > > In many circumstances, there might be an elegant workaround: > If you've > > got a relatively recent GNU Radio, your GRC will contain "Python > > Module", which you can use to have python code that gets > automatically > > written to a different .py file when the Python code is > generated; that > > way, you can have your own functions that you can call e.g. > in your > > block properties. > > > > But I think your idea is pretty interesting, anyway. Maybe > there's > > already thoughts on that or similar concepts; I just don't > know :) > > > > Best regards, > > Marcus > > > > On 31.03.2016 14 <tel:31.03.2016%2014>:18, Vitt Benv wrote: > >> Tnx Marcus, you are right, I'm speaking about "graphical" > properties. > >> I was aware about "GUI Hint" and I tried this but only to > put widgets > >> in rows x columns positions.... but now I know about the > subsequent > >> parameter: I'll test those. > >> > >> Now I miss only Tabs as Notebook was used, but never mind, > I'll try > >> another way! > >> > >> About GRC I think it's a good "starting point" but then > some extra > >> code does the job. > >> > >> A useful feature in GRC could be to have some kind of > protection on > >> added code between builds... if I recall right there was an IDE > >> (WxGlade... maybe...) who understood a simple tag as: > >> > >> .... > >> ### PROTECTED CODE ### > >> > >> ... added code > >> > >> ### > >> .... > >> > >> so that in subsequent build that wasn't overwritten ( > actually it > >> happened several times, sgrunt!). > >> > >> Tnx again, ciao ^__^ > >> > >> Victor > >> > >> 2016-03-31 13:40 GMT+02:00 Marcus Müller > <marcus.muel...@ettus.com <mailto:marcus.muel...@ettus.com>>: > >>> Hi Victor, > >>> > >>> what specifically are you referring to when you say > "dimension" of your > >>> graphical sinks; do you mean the "logical" size (in points > of the FFT) > >>> or the "graphical" size (in pixels of the widget, or the > window)? > >>> > >>> You can specify the heights of the widgets manually, but > that would > >>> require you to interfere with Qt taking care of window > layout (and is > >>> not a good idea most of the time); if possible, prefer to > use a relative > >>> grid layout as explained below. > >>> > >>> The equivalent to WX' Notebook, there's the QT "GUI Hint" > property. It's > >>> pretty awesome, if you want to have a grid kind of layout; > its format is > >>> > >>> row,column, row_span, column_span > >>> > >>> So, if you want something like > >>> > >>> +-------+-------+ > >>> | Time | Freq | > >>> | Plot | Plot | > >>> +-------+-------+ > >>> | Slider | > >>> +---------------+ > >>> > >>> The GUI hints would be > >>> > >>> time plot: 0,0, 1,1 (first (=0.) row, first column, one > row high x one > >>> column wide) > >>> freq plot: 0,1, 1,1 (first row, second column, 1x1 ) > >>> slider: 1,0,1,2 (second row, first column, 1 high x 2 wide) > >>> > >>> Generally, it's possible (though not directly from GRC > without writing > >>> your own Python) to embed your Visualization into your own Qt > >>> Application; there's a few projects out there that do > that, but I don't > >>> think we really have a best practice guide for that just > yet :) > >>> > >>> Cheers, > >>> Marcus > >>> On 31.03.2016 12:45, Vitt Benv wrote: > >>>> Good morning, > >>>> I'm exploring QT graphical, to begin lo leave WX widget.... > >>>> I'm looking for good infos about resizing / fix the > dimensions of my > >>>> two graphical sinks ( frequency / spectrogram), Googled > around but no > >>>> clear infos :-( > >>>> Moreover in WX there's a Notebook container, very useful > with crowded > >>>> GUI.... there's an equivalent in QT? > >>>> Tnx in advance for any answer. > >>>> > >>>> Victor, I3VFJ > >>>> > >>>> _______________________________________________ > >>>> Discuss-gnuradio mailing list > >>>> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> > >>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >>> _______________________________________________ > >>> Discuss-gnuradio mailing list > >>> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> > >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >> _______________________________________________ > >> Discuss-gnuradio mailing list > >> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> > >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org <mailto: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
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
