Change keyboard focus to Exclusive when dialog is open

[blackteaextract]

Pull Request

Motivation

When a settings dialog opens from the bar, PopupMenuWindow uses WlrKeyboardFocus.OnDemand. The problem with OnDemand is that the compositor doesn't transfer keyboard focus until the user explicitly taps the surface — so whatever was focused before (e.g. a browser) stays focused.

This breaks on-screen keyboards: Squeekboard auto-hides because it sees no active text input in the focused window, or - as also wvkbd - keeps routing input to the background app. Reproduces with any plugin/widget settings opened from the bar on a touchscreen; doesn't affect the general settings panel.

Switching to Exclusive makes the dialog claim focus immediately on open, which fixes both.

- WlrLayershell.keyboardFocus: hasDialog ? WlrKeyboardFocus.OnDemand : WlrKeyboardFocus.None
+ WlrLayershell.keyboardFocus: hasDialog ? WlrKeyboardFocus.Exclusive : WlrKeyboardFocus.None

Only affects when hasDialog is true, so menus and tray are untouched.

Note: a qt.qpa.wayland.textinput warning (Got leave event for surface 0x0) may still appear in logs during the focus transition. This is a pre-existing Qt Wayland quirk unrelated to this change and has no functional impact.

Known Follow-up Issues

This fix makes the OSK usable inside the dialog but exposes two remaining touchscreen UX gaps that are out of scope for this PR:

• Tapping the bar widget closes the dialog. The full-screen MouseArea in PopupMenuWindow catches the tap before the bar widget does, triggering close(). This means you can't toggle the OSK off while the settings dialog is open.
• Dialog doesn't account for the OSK's screen space. Controls at the bottom of the dialog (e.g. the Apply button) may be hidden behind the OSK with no way to reach them without closing the settings first.

Both require further changes to PopupMenuWindow / the dialog layout.

Just asking: If there is an interest in investigating more quirks with touchscreen input in a broader or general sense, would opening an issue to collect more about touchscreen behavior be an option?

---

Type of Change

• Bug fix
• New feature
• Breaking change
• Refactoring

Related Issue

• Related: Noctalia third-party plugins onscreen keyboard problem noctalia-plugins#758

Testing

• Tested on niri
• Tested on Hyprland
• Tested on sway
• Tested with different bar positions and density settings
• Tested at different interface scaling values
• Tested with multiple monitors (if applicable)

Checklist

• Code follows project style guidelines
• Self-reviewed my code
• No new warnings or errors (see note in Motivation about pre-existing Qt warning)
• Documentation or comments updated (if relevant)