Rtf popup QMainWindow

[Holt59]

Based on frednet, tested:

• Darnified UI - The README dialog is separate from the rest, which is pretty nice.
• new_omod_2 with DisplayText - The popup is modal as expected (had to add a QEventLoop).
• The other popups (yes/no, etc.), seem to be above the README, which is not very nice... I think that it is possible to avoid this by changing the parent of one or the other and switching to WindowModal.

[AnyOldName3]

Why do we still take the parent argument if we're always using nullptr?

[Holt59]

I kept the parameter and use it but now I pass nullptr explicitly when needed so that we can still pass other parents.

[AnyOldName3]

New set of questions now I've tried this out:

• Without the size grip, it's harder to resize the popup on my touchscreen laptop. Is it something that can be brought back?
• When the loading bar appears, it brings the main MO2 window on top of the readme, which is a pain. Can anything be done about it?

[Holt59]

New set of questions now I've tried this out:

• Without the size grip, it's harder to resize the popup on my touchscreen laptop. Is it something that can be brought back?

You can add a QStatusBar to the window, that will add a size grip. It's probably possible to do it without the status bar, but it looks like kind of complicated from Qt documentation...

• When the loading bar appears, it brings the main MO2 window on top of the readme, which is a pain. Can anything be done about it?

I think the problem is that the Rtf popup does not have a parent. As you mentioned in the linked issue, we would probably need to create a custom hierarchy (with a "fake" widget) to fix this. Maybe it's not a bad idea to have the "init" dialog show in permanence and use it as parent for all dialog but the Rtf popup?

[AnyOldName3]

If I'm reading things correctly, keeping the init dialog around would only fix the DarNified UI stuff, not the readme stuff.

[Holt59]

It would make the readme popup stay on top of the main window but other dialogs will be put on top of it (but not modal).

[AnyOldName3]

I don't see any reason why it would. Can you explain (or open another PR proving me wrong)?

[Holt59]

That's how I understand Qt documentation.

Currently, the readme dialog has no parent, and it's Window modal, so it does not actually block anything and when a new Window modal dialog (or application modal) dialog with a parent is shown, everything is put on top of the readme dialog (the new dialog + the parent).

If we set the parent of the readme dialog to parentWidget() or something similar and keep it Windows modal, then the readme dialog will never be behind it.

You want the readme dialog and the init dialog to be "cousin", which may require adding a fake invisible widget in the hierarchy, and then have the other install dialogs be children of the init dialog, something like (maybe we don't need both fake widgets):

Parent Widget
    Fake Widget 1
        Readme Dialog
    Fake Widget 2
        Init dialog
            Other dialogs

[AnyOldName3]

I think I see what you're driving at now. With extra dummy widgets in the hierarchy, what you're saying makes more sense, but I thought you were suggesting an alternative to using dummy widgets.

I don't think we want the readme dialogue to actually be modal, though. For example, at least one mod I've got in my test suite installs, but doesn't try to activate, several optional ESP files, and what they do is described in the readme. Users will probably want to be able to enable them in the plugins tab while they still have the readme open. I think the ideal outcome would be if it floated on top of MO2 without being modal, a bit like running task manager with Always on top on, except obviously we'd want to let non-MO2 windows cover it.

[AnyOldName3]

New question. The popup's constructor sets WA_DeleteOnClose, but it's stack-allocated here. Is there anything guaranteeing we don't end up with a double-free?

[Holt59]

I never encountered issues with this when testing but I did not manage to find a clear answer for this in Qt documentation so it's probably better to move the setAttribute outside of the constructor.