discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Grid/Coordinate placement ('GUI hint' QY/WX) cont


From: CEL
Subject: Re: [Discuss-gnuradio] Grid/Coordinate placement ('GUI hint' QY/WX) control query
Date: Mon, 20 Aug 2018 13:46:22 +0000

Hi Mark,

don't think I can contribute much to your understanding of the hints,
since that seems to be correct and comprehensive:

The gui hint is (row,column, row span, column span). This is pretty
much a direct delegation of how the Qt Grid Layout [1,2] works.
So, Qt just looks for the highest row and column number you use
(including spans), then divides the overall area into a grid of that
many rows and columns, and places the elements in that.

Which means that yes, if you have a large element in the same row or
column as a checkbox, the checkbox will take the same height or width.
The idea would be to divide the height/width of large button mentally
into desired checkbox heights/widths, and let it span that many rows /
columns.

Generally, I'd argue that this way of designing GUIs is a bit of a
clutch – a manageable clutch, but still. What we'd want is the ability
to use Qt visualizations from GNU Radio directly in Qt Designer, do
your UI design there, and just somehow link the GRC blocks to these GUI
"placeholders".

Actually, you can do something close to that, namely:
design in Qt Designer, export a UI file (or python code), with empty
QWidgets in the places you want your GNU Radio UI interface parts to
be.
Then, take the GRC-generated python flowgraph program, load that UI
file (or python module) from there, and add the Qt Elements that your
GRC flowgraph contains to the placeholders in said UI.
But that requires modification of code after generation by GRC, and is
even more of a clutch, as GRC can't preserve such modifications, and
you'd have to do the very same the next time you modify anything in
your GNU Radio flow graph :/

That would, by the way, be an awesome project to work on. I envision
something like one being able to specify a UI file in the flow graph
"Options" block, and then in the individual Qt Blocks' properties,
allow one to pick a position to replace.

Best regards,
Marcus

[1] http://doc.qt.io/archives/qt-4.8/qgridlayout.html
[2] http://doc.qt.io/archives/qt-4.8/layout.html
On Sun, 2018-08-19 at 22:51 +0100, Mark wrote:
> This is perhaps a trivial query about the use of QT (or WX) GUI controls when 
> trying to design widgets (GUI controls) to position themselves on the runtime 
> workspace in GNU Radio.
>  
> For example, if I try to place a QT button control at ‘GUI hint’ coordinates 
> 0,0,1,1, I can never seem to get the button to span just a small width – the 
> button spans the take up the entire column workspace at runtime.
>  
> Furthermore when placing other widgets, despite trying to use the ‘GUI Hint’ 
> correctly, the placement and width of controls appear to interfere with one 
> another and get displaced into unexpected areas of the workspace when the 
> flow graph is executed at runtime.
>  
> I’ve tried to follow what little has been published about how the GUI Hint 
> function is suppose to work, but the widgets still appear to give odd 
> behaviours.
>  
> I shouldn’t compare this with say developing GUI’s in Visual Studio etc; but 
> it seems to me that despite being me being able to design flowcharts that 
> result in fully functional radio systems with GNU Radio and my USRP, I find 
> the frustration of working with ‘GUI Hint’ problematic when trying to design 
> a usable user interface from scratch.
>  
> Maybe there is no hard and fast rule how to use the ‘GUI Hint’ function but 
> if anyone can spare time to offer more detailed guidance on the ‘GUI Hint 
> ‘function and its usage then I should be very grateful for the clarification.
>  
> Thank you if you are able to help,
>  
> Mark
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Attachment: smime.p7s
Description: S/MIME cryptographic signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]