Re: Variables and messages - never the twain shall meet?

[Vitt Benv]

Good afternoon David and list!

Recently I had your same problems developing an application ( a SDR transceiver, mainly for satellite ops, based on ADALM Pluto).

The main headache was " how I can *click* on the waterfall and *tune* there?...", clearly invoking some variable interaction.... then yor same problem!

Next, studying much deeper how manage messages I found a nice solution: a block that "manipulate" the input message and send several different messages ( RX chain / TX chain) around the flowgraph.

Please, take a look to https://sourceforge.net/projects/qo100-pluto/ . Please use the last version.

It isn't currently finished but it's working!

Actually this work has another goal: "split" the transceiver in two parts: a REMOTE, low noise site + antennas + PA + allthestuff connected via LTE link to a LOCAL where all the magic happen ( demod / tuning /voice compressor and so on). The main effort is related to minimize the request bandwidth on LTE link ( $$$$$ )

Hope that could help!

73's de I3VFJ, Vittorio

Il giorno lun 20 apr 2020 alle ore 02:27 David Hagood <address@hidden> ha scritto:

It seems to me that there is a fundamental design flaw in how the UI
elements of GnuRadio Companion work.

Several modules, like the Qt Frequency blocks, can output messages when
you click them, to inform *somebody* as to where you clicked. This would
be great for setting a new frequency, but...

All the Qt UI elements, like ranges and check boxes, only work on
variables, and cannot accept nor generate messages. So if you want your
UI to have a range box to set center frequency, it has to modify a variable.

BUT: Since there seems to be no way to have a message be received and
update a variable, there is no way to have the Qt Frequency display
message update a variable that is controlled by a Qt Range object.


I've tried to write my own block to handle the messages and update the
variable, BUT:

1) You cannot access variables inside the block from the UI elements -
they all fail with a "type null is unacceptable for the variable", so
you cannot save the flow graph.

2) If you do an ugly thing and pass "self" (the flowgraph object) to the
block, you can access the variables in the flowgraph, but setting the
variable directly does not call any update functions (i.e. the
set_<variablename> setter method is not called).

3) If you have the block call the set_<variable> function directly, and
if the update manipulates any Qt object (which is needed so that the UI
will update), it fails because the message handler is in a different
thread from the flowgraph UI, and Qt won't allow the call to happen.

4) There is the function probe, which

4a) is ugly because it is polling code

4b) does not seem to be able to set a flowgraph level variable to the
return value of the function, making it useless for this purpose anyway.


Now, if ALL UI elements could handle messages, then you could at least
write a block that could parse the messages from UI elements, and create
new messages as needed to "make things happen". Or if there were a way
to add a message handler to the flowgraph and specialize it's code, you
could handle messages that way. Or if there were a block that would
accept messages and set variables at the flowgraph level based upon the
message (with any callbacks happening correctly), that would work.


I don't see how a non-trivial application can be created without having
some solution to this, so am I missing something? or is this something
that will be fixed sometime in the misty future with all the UI elements
have been re-written to handle messages?