Variables and messages - never the twain shall meet?

[David Hagood]

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?