Opening OverlaySheet while prompting takes focus away from prompter and does not return it

[Cuperino]

Describe the bug Opening OverlaySheet while prompting takes focus away from prompter and does not return it

To Reproduce

1. Start prompting
2. Open an overlay sheet such as "add named marker" or "set"
3. Close the overlay
4. Attempt to control prompter

Expected behavior Regain control of prompter upon closing overlay

Your Device

• Operating System: Linux
• QPrompt Version: 1.0.0-beta-003
• Qt Version 5.15.2 - 5.15.3
• KDE Frameworks Version 5.85.0 - 5.86.0

[Cuperino]

Plausible solution: Add onOpen and onClose signal events to: templates/OverlaySheet.qml.

[Cuperino]

Partial solution implemented. Take control over Esc key, restore focus upon closing overlays.

[videosmith]

I opened the top left and right menu panes...

Interesting how you can still drag the velocity slider or click on the <> buttons when not in Full Screen with the mouse and still control scroll speed...

Also noticed if not in Full Screen mode while prompting, keyboard control can be restored by clicking the mouse on the grey background area in the top menu bar for the ltop left pane, and the <> in the top menu to restore after using the top right pane

In Full Screen, the <> buttons still work

[Cuperino]

Interesting how you can still drag the velocity slider or click on the <> buttons when not in Full Screen with the mouse and still control scroll speed...

That's a feature I added in v1.1, where wheel inputs are routed from various locations to the Prompter component. In most cases, those locations would normally be dead zones, such as the editor toolbar's background (which can now also be used to drag the window around). The idea is you should be able to control the prompter's speed from almost anywhere in the program.

[Cuperino]

My bad, I think I misread what you wrote there in an attempt to reply quickly.

Interesting how you can still drag the velocity slider or click on the <> buttons when not in Full Screen with the mouse and still control scroll speed...

If you're talking about how the < > buttons can sometimes be pressed after leaving fullscreen, that is a bug in Kirigami or Qt. Those buttons are only supposed to be shown:

• While prompting in full screen mode
• On mobile devices
• While prompting with the reading region set to its topmost position

There are bugs in Qt versions 5.15.2 through 5.15.5 that cause them to show in other circumstances. These bugs are supposed to be fixed in KDE's Qt patch collection, which is included with all containerized versions of QPrompt. It may be that Debian's version of Qt doesn't have the latest Patch Collection patches applied. Or maybe there's a bug in Kirigami, or there remains a bug in Qt not covered by the patches.