Currently, all installer_omod popups except the readme are application-modal. Custom WinForms widgets created by C# OMODs, like DarNified UI, are thread-modal. The readme is non-modal. This imposes the following problems:
When a DarNified UI popup is displayed, the whole of the MO2 UI is still responsive. Presumably, things can get broken if someone presses buttons.
When a DarNified UI popup is displayed, clicking on any other part of MO2 will bring MO2 on top of the popup. This could be misinterpreted as the installation having finished, then the user might interact with the main window and break things as described above.
When any non-DarNified UI popup is displayed, the readme becomes unresponsive. We want the readme to respond in case the user needs to read it to see what the options they're being shown do or they want to read it while extraction is happening.
Whenever any non-DarNified UI popup appears, it will bring focus to itself and the (disabled) main window will be shown on top of the readme popup. It can be brought back on top, though.
For the DarNified UI popups, I don't know if we can do anything. We need to run the install script on a separate thread otherwise the extraction process will lock up the UI and we can't have a progress bar, and we have no control over the windows it creates. The only thing I can think of is having a Mod Organizer is locked while OMOD installer is running popup akin to when an application is running via the VFS, but I don't know if that would fight our other popups.
Qt's modality documentation isn't super-clear as I don't think they anticipated the readme popup use case. I believe that non-modal does what it sounds like, application-modal steals input from all Qt-managed windows in the application, and window-modal steals input from:
any window found by recursing up the Qt widget hierarchy into parents.
any window whose parent is one of those windows.
If I'm right, that means parents, (great-)grandparents and (great-)(aunts|uncles), but not cousins. This might mean that we can get the readme popup to display how we want by making its direct parent a dummy window so it counts as a cousin, and setting the other popups to be window-modal. I'm not sure, though. The documentation for modality refers to the concept of a window hierarchy, but every other bit of Qt documentation refers to widget hierarchy.
It might just be simpler to pass the generated HTML for the readme to the browser so it's totally out of MO2's hands.
Currently, all
installer_omodpopups except the readme are application-modal. Custom WinForms widgets created by C# OMODs, like DarNified UI, are thread-modal. The readme is non-modal. This imposes the following problems:https://github.com/AnyOldName3/modorganizer-installer_omod/pull/3 changes the
RtfPopupto aQMainWindowinstead ofQDialog. This separates it from the main window's window hierarchy so it's not locked out. The issues then become:For the DarNified UI popups, I don't know if we can do anything. We need to run the install script on a separate thread otherwise the extraction process will lock up the UI and we can't have a progress bar, and we have no control over the windows it creates. The only thing I can think of is having a Mod Organizer is locked while OMOD installer is running popup akin to when an application is running via the VFS, but I don't know if that would fight our other popups.
Qt's modality documentation isn't super-clear as I don't think they anticipated the readme popup use case. I believe that non-modal does what it sounds like, application-modal steals input from all Qt-managed windows in the application, and window-modal steals input from:
It might just be simpler to pass the generated HTML for the readme to the browser so it's totally out of MO2's hands.