GRCC No GUI?

GNU Radio
1

Is it possible to modify the GRCC tool to work on a system without a
display, or over SSH without X-forwarding?

I recently found that the GRCC tool which allows you to boil a GRC file
down to a Python file, only works on computers with a graphical display,
like a desktop. On servers with no GUI or over an SSH session with
X-forwarding, the command fails. I think Josh commented on a thread
that
made mention of this recently, but I wanted to bring it up again.

I deploy gnuradio to lots of remote machines and some of those systems
depend on hierarchical blocks. GRCC is awesome because it generates the
Hier block Py file and can be commanded to put a copy of the file in the
user’s .grc_gnuradio folder, and also allows you to generate the higher
level flow graphs that use the Hier blocks.

I am actually deploying the FGs and Her blocks to a desktop machine, but
over SSH without X-forwarding, since the configuration management tool I
am
using (ansible) doesn’t support X-forwarding yet. If you try to run
GRCC
over SSH with X-forwarding, everything is peachy.

Following up on a comment Josh made in the earlier discussion about
GRCC, I
tried to pull out all of the GUI references that the GRCC tool depends
on,
but I still ended up with an enigmatic error in the end. Unfortunately,
this was done two weeks ago and I don’t have any good info on where I
left
it.

2

On Fri, Jun 14, 2013 at 11:15 PM, Dan CaJacob [email protected]
wrote:

depend on hierarchical blocks. GRCC is awesome because it generates the
tried to pull out all of the GUI references that the GRCC tool depends on,
but I still ended up with an enigmatic error in the end. Unfortunately,
this was done two weeks ago and I don’t have any good info on where I left
it.

Hi Dan,

As you said, this was discussed a bit ago, and the conclusion at that
time sounded like it wasn’t going to be a straight-forward fix. Your
experience seems to confirm that. I’m not sure there’s been much
activity on this, otherwise. If you manage to get it to work, I’d
really like to pull in your solution.

Tom

3

Following up on a comment Josh made in the earlier discussion about GRCC, I
tried to pull out all of the GUI references that the GRCC tool depends on,
but I still ended up with an enigmatic error in the end. Unfortunately,
this was done two weeks ago and I don’t have any good info on where I left
it.

I think I had mentioned that GRCC could import the non-gui stuff, from
the grc/python directory, and that would avoid the import gtk statement,
which is messing up the ability to do non gui stuff.

So looking into grc/python

Param.py: gtk.FILE_CHOOSER_ACTION_SAVE,
(‘gtk-cancel’,gtk.RESPONSE_CANCEL, ‘gtk-save’,gtk.RESPONSE_OK))
Param.py: if gtk.RESPONSE_OK == file_dialog.run(): #run the dialog

It looks like only the Param.py would cause a runtime import issue with
gtk/pygtk. In this case, that imprt statement could be moved to the
indentation level where it is used (file dialog).

Did you notice other modules pulling gtk imports that should not have?
Or were you unable to rewrite the GRCC to completely avoid importing
modules from grc/gui?

-josh

4

I was able to get this working by simply catching an exception when
attempting to import Colors. This seems to be the source of the problem
and you don’t really need that module when running grcc. See attached
patch.

-Roy

5

Josh and Tom,

I’ll try to go back and look into where I left it. I had taken your
advice
and basically changed all the relevant classes to not inherit the GUI
stuff, but I still ended up with an untenable error in the end, that now
that you mention it, I think was related to Param.py… As I recall,
the
weird thing was that the error did not match up with the source file it
was
referencing.

Sorry, I know this is super vague. So, I’ll just dig back into it and
come
back with more specifics.

Thanks!

Very Respectfully,

Dan CaJacob