When opening the user menu during a question/having the menu open prior to a question being asked FPSci can enter a state in which the cursor isn't drawn despite the application asking for an answer to a mouse-based question. Specifically this is reproducible when clicking the Resume button in the menu as opposed to closing it with the menu key bind.
You can reproduce this issue by waiting for a question to be asked in any experiment, opening the user menu (with its key bind), then closing the user menu by pressing the Resume button. This results in the question still being drawn, but the mouse mode reverting to MOUSE_FPM.
We should test exhaustively for ordering here, but perhaps we should move to a unified call to set the mouse mode that checks whether a dialog is present as is done in FPSciApp::toggleUserSettingsMenu() before changing the mouse mode.
It may also be worth noting that answering the final question of a set closes the user menu and reverts to the MOUSE_FPM mode, but this seems less bothersome than hiding the cursor while a question is asked.
When opening the user menu during a question/having the menu open prior to a question being asked FPSci can enter a state in which the cursor isn't drawn despite the application asking for an answer to a mouse-based question. Specifically this is reproducible when clicking the
Resume
button in the menu as opposed to closing it with the menu key bind.You can reproduce this issue by waiting for a question to be asked in any experiment, opening the user menu (with its key bind), then closing the user menu by pressing the
Resume
button. This results in the question still being drawn, but the mouse mode reverting toMOUSE_FPM
.We should test exhaustively for ordering here, but perhaps we should move to a unified call to set the mouse mode that checks whether a
dialog
is present as is done inFPSciApp::toggleUserSettingsMenu()
before changing the mouse mode.