Note that there the mainwindow.ui file --- same as your test.ui in that it has

 <class>MainWindow</class>
 <widget class="QMainWindow" name="MainWindow">

--- is the only occurrence of any QMainWindow in that code. It does not have another QMainWindow where you do and go self.ui = loader.load("test.ui"). PySide6 QUiLoader().load("test.ui") creates and returns a complete, new MainWindow/QMainWindow widget. So you won't want to create your own, separate MainWindow/QMainWindow.

If you want to persist with this, I suggest you start from the linked code and modify as desired from there.

• If I copy and paste your original code I get a visual window. It is a main window. It opens "small", but I can drag-resize it and it looks similar to what you showed in both screenshots. But note this whole code is quite wrong: you end up with two QMainWindows, one is your MainWindow and the other is a QMainWindow from your .ui file which has been set as the central widget via self.setCentralWidget(self.ui). You do not want a QMainWindow as the type of the central widget of a QMainWindow!

• If I replace just MainWindow's def __init(self) per your last post I get an empty MainWindow --- your title but no content. And the same whether loader.load(ui_file, self) has self as parameter or not. No "hang", no "no window displayed".

So if you really want to use, or have people investigate, you attempted use of QUiLoader(), I suggest you paste a new complete but minimal example of your code as it is, as I am guessing it is not just as you show/I have copied.

(I still don't think the new code can be right: self is your MainWindow, which is a QMainWindow, and when your __init() goes self.setLayout(layout) that sets the whole layout of a QMainWindow which you would never want to do. The point of a QMainWindow is that it already has its own layout with various widgets to produce menus and status bars. It has one area in the "middle" which is the "central widget" and you should only be setting that and its layout and content.)

(Also, if self.ui = loader.load(ui_file) or similar is used to create and load a QMainWindow, you would never want to call self.ui = loader.load(ui_file, something), whether something is self or any other QWidget. That would be a parent widget for the created widget, and you should only use a QMainWindow as a top-level widget/window, it would never have a parent.)

Personally I do not think you will gain much by persisting with QUiLoader()/loader.load(ui_file) since I don't think that is the best way to use Qt/Designer back-end code. As I have said I would abandon that approach and use the class-generation one instead. I have never used QUiLoader() so don't have much experience, but will look again at your code (if made to work) if you wish to continue with that.

I'm using the .ui file approach only while I learn Qt and prototype my application, and will switch to generating code once the user interface is stable.

There's a lot to digest in your response and I'll follow up on your reading suggestions.

Clearly there's still a lot wrong in my mental model of how things work. For example, since my last post I have whittled things down to this:

    def __init__(self):
        super().__init__()
        
        loader = QUiLoader()
        ui_file = QFile("../../../qtTest/test.ui")
        if not ui_file.open(QFile.ReadOnly):
            print("Cannot open ui file")
            sys.exit(-1)
        
        self.ui = loader.load(ui_file)
        ui_file.close()

        layout = QVBoxLayout()
        layout.setContentsMargins(0, 0, 0, 0)
        layout.addWidget(self.ui)
        self.setLayout(layout)
        self.setWindowTitle("My Qt Designer App")

This works and produces the minimum-size window from my previous post. Notice however self.ui = loader.load(ui_file), where don't specify the parent widget. If I change the code to self.ui = loader.load(ui_file, self) then the code hangs at app.exec() with no window displayed.

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.

Thanks for your quick reply. Sorry, but as a beginner with Qt, I'm not sure I understand your suggestions completely.

• In designer activate "Lay Out Vertically" on the centralwidget
  I don't see an option to "lay out vertically" (or just Lay Out) in the context menu nor in the property editor for centralwidget. There's a "Layout" section at the bottom of the property editor called verticalLayout_3 but it specifies only margins, spacing, stretch and size constraints.
• change the root of the .ui from QMainWindow to a regular QWidget
  In Designer or in my code? To clarify:
  • Question: Are you saying my Python MainWindow class should inherit from QWidget instead of QMainWIndow?
  • Question: Is it the case that since the Designer generates a QMainWindow in the .ui file, it is redundant to inherit from QMainWindow in the code?

Meanwhile, I got it working, but by a different change.

What I actually did was right-click in Designer on the MainWindow line in the object inspector, selected "Lay Out" and then clicked "Lay Out Vertically" (in MainWindow, not in the centralwidget object, which didn't have a "Lay Out" context menu entry). I then ran my existing code with no changes other than the new .ui file.

The result of that was a window containing all the controls, at the minimum possible size for those controls:

I still have a lot to learn... 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.

I'll be curious to see your answers to my questions above.