That's a QSplitter
You can also look a QDock - but it's a bit buggy.
SdrAngel Addons Rezise
Re: SdrAngel Addons Rezise
colleague of mine said it is the ui feature called docking, and most of the modern ui framework support it, including Qt
https://doc.qt.io/qt-6/qtwidgets-mainwi ... ample.html
https://doc.qt.io/qt-6/qtwidgets-mainwi ... ample.html
Re: SdrAngel Addons Rezise
As I said, there's QDock.
Docking is already implemented for workspaces - just use the button in the top right of the workspace to undock, then you can drag the workspaces around (or you can drag the workspace title bar). But currently the workspaces are using MDI.
Docking is already implemented for workspaces - just use the button in the top right of the workspace to undock, then you can drag the workspaces around (or you can drag the workspace title bar). But currently the workspaces are using MDI.
Re: SdrAngel Addons Rezise
okok I see, I do not understand well, but might be it needs some more debugging, but I prefer to have this in the workspace
Re: SdrAngel Addons Rezise
In that case, you might be better to pull latest of 6.x versions and start from there, because the behaviour you like, was default back then.
Moreover, it might be easier to port last/future developements to old GUI, than to 'dockify' current one.
In either case, you'll practically end up with maintaining your own fork, which is not an easy task.
Moreover, it might be easier to port last/future developements to old GUI, than to 'dockify' current one.
In either case, you'll practically end up with maintaining your own fork, which is not an easy task.
Re: SdrAngel Addons Rezise
hm, if the docking function was the default in the 6.x version why did you remove it?
do you think it is better or easier to use etc. this way as it is now?
what is your user experience and opinion on this ui feature? (docking) let me know your thoughts
do you think it is better or easier to use etc. this way as it is now?
what is your user experience and opinion on this ui feature? (docking) let me know your thoughts
Re: SdrAngel Addons Rezise
This is what Auto Stack will do more or less.
I think the application you mention just follows the default Qt placement scheme with a central widget and ancillary widgets all around. This is how the previous design (v6) was based on with the device spectrum widget at the center. As a consequence you could not have different devices in the same workspace. It took a lot of effort to move from a rigid widgets placement as you seem to like it to a fully floating one (a.k.a. MDI) in v7 that can fit more use cases and offers more flexibility like having Rx and Tx in the same workspace. I think overall this is a big improvement from the previous design. And with Auto Stack you can have some more rigid placement a bit similar to what it was before.
Brgds,
Edouard.
I think the application you mention just follows the default Qt placement scheme with a central widget and ancillary widgets all around. This is how the previous design (v6) was based on with the device spectrum widget at the center. As a consequence you could not have different devices in the same workspace. It took a lot of effort to move from a rigid widgets placement as you seem to like it to a fully floating one (a.k.a. MDI) in v7 that can fit more use cases and offers more flexibility like having Rx and Tx in the same workspace. I think overall this is a big improvement from the previous design. And with Auto Stack you can have some more rigid placement a bit similar to what it was before.
Brgds,
Edouard.
Re: SdrAngel Addons Rezise
In addition... I think you just don't realize that SDRangel is modular, multi-device, multi feature and the way the GUI is presented now (v7) better fits this nature than the previous one (v6). Of course if you use a single receiver with one or just a few channels and one feature you may not realize it. Just play with it a little bit more with more complex use cases and you may see the interest of it.
Not in any case will it revert to the previous design so if you don't like it as mentioned you can maintain your own fork.
Brgds,
Edouard.
Not in any case will it revert to the previous design so if you don't like it as mentioned you can maintain your own fork.
Brgds,
Edouard.
Re: SdrAngel Addons Rezise
Dear Edouard, thank you for sharing your thoughts, this absolutely makes sense. Yes I agree, MDI-like ui can deliver more freedom.
I am at the beginning of my journey with SDRA but it is looks very well architected and implemented.
Usually I am integrating systems and look to it from end user point of view and his ux expectations, which is not equal to engineering point of view
Yes I realized the in/out capability and it was a little bit confusing me as MIMO term is used for a TX/RX functionality.
Recent years devices with streaming in/out capability started to use Vector Signal Transceiver term in professional TnM industry,
and yes MIMO is usually used for noting multiple antenna capability (either input or output side)
So for me the devices we may use are: in/receiver, out/transmitter, inout/transceiver, and multiple interfaces are attribute of these devices.
Let me know your thoughts.
Instead or before any fork, I like to understand the thoughts of the core developers and contributors, who might be better than me
or/and try to help and add value to the community instead working alone on my fork.
br, /b
I am at the beginning of my journey with SDRA but it is looks very well architected and implemented.
Usually I am integrating systems and look to it from end user point of view and his ux expectations, which is not equal to engineering point of view
Yes I realized the in/out capability and it was a little bit confusing me as MIMO term is used for a TX/RX functionality.
Recent years devices with streaming in/out capability started to use Vector Signal Transceiver term in professional TnM industry,
and yes MIMO is usually used for noting multiple antenna capability (either input or output side)
So for me the devices we may use are: in/receiver, out/transmitter, inout/transceiver, and multiple interfaces are attribute of these devices.
Let me know your thoughts.
Instead or before any fork, I like to understand the thoughts of the core developers and contributors, who might be better than me
or/and try to help and add value to the community instead working alone on my fork.
br, /b
Re: SdrAngel Addons Rezise
Hello,
Re the MIMO stuff well... I don't find "Vector Signal Transceiver" particularly descriptive. They are all "Vector Signal" devices (i.e. I/Q) anyway and the transceiver capability is secondary so then you would end up in "Vector Signal Receiver/Transmitter/Transceiver" why not just "Receiver/Transmitter/Transceiver"? Quite frankly I will not go through the hassle of renaming everything so MIMO = "Multiple In Multiple Out" is fine for me and quite descriptive. By the way this is a generic term and relates to the fundamental capability of this type of plugin. If you notice since Metis has only one Tx capability the Metis plugin is called "MetisMISO". Also the MIMO devices came after simple sources and simple sinks were implemented so the Hack RF combined Rx/Tx support for example who could be named HackRFSISO does not exist. In fact the number of in and out channels is flexible so basically any device could be supported by this type of plugin. Its main interest is to be capable of handling synchronous channels.
Brgds,
Edouard.
Yes that's the preferred way. Forking out is only if you want to do something so radically different like going back to the v.6 main window scheme but I think this is not what you would like to do eventually.I know some people are critical about MDI but you don't have so many choices with Qt and the default Main Window scheme is what I think is old fashion....try to help and add value to the community instead working alone on my fork.
Re the MIMO stuff well... I don't find "Vector Signal Transceiver" particularly descriptive. They are all "Vector Signal" devices (i.e. I/Q) anyway and the transceiver capability is secondary so then you would end up in "Vector Signal Receiver/Transmitter/Transceiver" why not just "Receiver/Transmitter/Transceiver"? Quite frankly I will not go through the hassle of renaming everything so MIMO = "Multiple In Multiple Out" is fine for me and quite descriptive. By the way this is a generic term and relates to the fundamental capability of this type of plugin. If you notice since Metis has only one Tx capability the Metis plugin is called "MetisMISO". Also the MIMO devices came after simple sources and simple sinks were implemented so the Hack RF combined Rx/Tx support for example who could be named HackRFSISO does not exist. In fact the number of in and out channels is flexible so basically any device could be supported by this type of plugin. Its main interest is to be capable of handling synchronous channels.
Brgds,
Edouard.