@Jim-G
I am a big fan of Qt, having used it for years, but not so much of the Designer part of Qt Creator. It can be arcane. But it is what it is, and if you want to design your UI visually you have to work with it.
Unfortunately you picked to start your experience with a QMainWindow (which many people do) and that does have a wrinkle making it confusing/unintuitive. You would indeed expect to place a layout on the centralWidget and that is what you do from code. But for some inexplicable reason Designer forbids that and you are supposed to know/guess you need to do it there on the MainWindow rather than the centralWidget. Even though it then applies that to the centralWidget. I only discovered this recently where I was stuck on just this issue. Read through my https://forum.qt.io/topic/164873/creator-cannot-set-layout-on-qmainwindow-centralwidget and you will see! This particular problem only arises on a QMainWindow with its centralWidget.
A couple of useful tips for Designer:
Look at the object hierarchy for "red no-entry" signs. If you see one it means that widget does not have a layout. It will need one, else you won't be able to position/resize properly etc. (Don't be tempted to use absolute coordinates/positioning, unless you have a special case you always want to use layouts.)
In general (say starting from a plain QWidget) you (I at least) would expect to place the widget, then add a layout, then add any child widgets. Common-sense, right? And how you would do it in code. In Designer you have first place at least one child widget on the parent widget, only then can you go back and place a layout (which you need) on the parent widget. You can even delete any child widgets afterwards if you wish and the layout will stay, but you need a child widget to place it initially.
Don't be afraid to look at the generated .ui file. It is XML and you can understand fairly intuitively where it puts what relating to your design. (Don't edit it though as it will get overwritten). For example, in your case of having to place the layout on the QMainWindow you would see that it actually places it on the centralWidget in the .ui file!
Question: Is there a canonical example of how to accomplish this with a Desinger-generated .ui dynamically loaded, and QMainWIndow? Or, is that just the wrong approach?
loader = QUiLoader()
ui_file = QFile("../../../qtTest/test.ui")
self.ui = loader.load(ui_file, self)
My strongest recommendation would be NOT to do it this way. Being able to load the .ui at runtime is really only useful in specific, unusual circumstances. C++ does have this approach too, but it is even harder to use than from Python.
# (Assuming you have a button named 'submit_btn' in Qt Designer)
self.ui.pushButton.clicked.connect(self.on_submit_clicked)
Correct me if I am wrong, but when you type that line into your Python editor IDE you get no "help" at all on the self.ui.pushButton, right? The editor does not know about it, cannot offer you completion and it would error at runtime if it turns out your .ui file does not have a push button named pushButton. This is because at design-/edit-time it has no idea that you are loading a file into ui nor what that file contains.
Read (again?) through https://doc.qt.io/qtforpython-6/tutorials/basictutorial/uifiles.html. You have taken approach Option B: Loading it directly. Don't :) Get yourself working with Option A: Generating a Python class there. That does mean you will need to run something like pyside6-uic mainwindow.ui -o ui_mainwindow.py each time you change the .ui file but I think you can have that done automatically from Creator for Python, you certainly do for C++. Once you have a class for each .ui file you can work with it and its members/widgets fully at edit time. You also do not need to distribute/have in existence your .ui files at runtime. (You can also examine the generated ui_....py files and see/learn how the .ui content is turned into Python/PySide2 code which can be helpful.)
When I increase the running window height (by dragging the resize handle), the group box resizes and the radio buttons spread out, but at least I can see everything.
That means a QGroupBox is set by default to grow when the window/parent grows. If you don't want this behaviour do something like set it to have a fixed size.
