Add 'core/input/keyboard' to exports

[und3f]

Allow noVNC users to use Keyboard utility: it is useful it required to grab events from other then canvas element

[CendioOssman]

We want to be conservative in what we expose as a stable API. What specifically is it you'd like added?

[und3f]

I need specifically class Keyboard https://github.com/novnc/noVNC/blob/master/core/input/keyboard.js#L17 to allow binding other's components keyboard events to VNC.

Beside exporting Keyboard, other option is to extend RFB constructor: add keyboard events component property (default would be as in this._canvas https://github.com/novnc/noVNC/blob/master/core/rfb.js#L269).

[CendioOssman]

The Keyboard class is a compatibility layer that does things that are fairly specific to our internal needs. Using it in other places isn't obvious how it's done correctly.

Could you give an example of how you use it? Perhaps a link to the code?

[und3f]

I am using it to forward keyboard events from the whole page:

    const keyboard = new Keyboard(document)
    keyboard.onkeyevent = (keysym: number, code: string, down: boolean) => {
      novnc.sendKey(keysym, code, down)
    }

    const onRfbConnect = () => {
      keyboard.grab()
    }

...

[und3f]

Hello, a kindly reminder about PR

[CendioOssman]

I'm not sure about what the use case you have here. Is there something preventing the normal method of the noVNC element getting focus and keyboard events the regular way?

[und3f]

I have couple of UI menus that helps user to interact with the remote machine. But after clicking on the menu VNC focus is lost, so I overcome it by setting Keyboard class on the document.

[CendioOssman]

Ah, I see. That is more cleanly supported by simply switching focus back to the RFB object. As an example, we do this in our own application after using some of the buttons on the toolbar:

noVNC/app/ui.js

Lines 1702 to 1707 in 44b7489

	sendCtrlAltDel() {
	UI.rfb.sendCtrlAltDel();
	// See below
	UI.rfb.focus();
	UI.idleControlbar();
	},

[und3f]

That makes sense, but the example designed for the buttons case. I have nested menus with many options, and beside click actions themself there are also cases when user navigated menus and then closed it. Or even when user opened a menu but then decided to type something to the VM.
There are simply to many corner cases when VNC focus is lost, so listening to key events on the document level was my solution.

[CendioOssman]

Don't you want users to be able to navigate the menus using the keyboard? If so, then I don't see any clear way of avoiding having to define specific points where focus is forced back to the RFB object. E.g. whenever a menu item is selected.

If you want to make the menus mouse only, then you might be able to get what you want by redirecting the keyboard events as-is. Perhaps something like:

1. Listen for all keyboard events
2. When an event arrives, move focus to the RFB object
3. Get the real HTML object by checking where focus got moved to
4. Resend the keyboard event to that object

[CendioOssman]

If the RFB object was a proper shadow DOM, then you could probably have sent the keyboard event directly there. But it's not something we have in place yet.

[und3f]

I've tried to implement such scenarios, but did not non succeeded:

• I can't remove focus during nested menu navigation as focus loss is an actual even which mean that user tried to closed menu (clicked outside the menu)
• I've tried to forward keyboard events to the specific element, the problem is they are still getting back to the document even with bubbling off. Maybe it is because I didn't focused VNC before forwarding keyboard event

[und3f]

Having an API to parse keyboard event and send it to VNC really did job great. I could copy-paste class from the Keyboard, it is really simple. But I would prefer to reuse utility classes from noVNC