Rtf popup QMainWindow - Githubissues

AnyOldName3 / modorganizer-installer_omod

OMOD installer using https://github.com/erri120/OMODFramework

GNU General Public License v3.0

2 stars 3 forks source link

Rtf popup QMainWindow #3

Closed Holt59 closed 3 years ago

Holt59 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

Holt59 commented 4 years ago

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 commented 4 years ago

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

Holt59 commented 4 years ago

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 commented 4 years ago

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.