Re: xwidget events

[Po Lu]

Aiko Kyle <aikokyle@gmail.com> writes:

> In emacs-webkit, I introduced an "insert" mode to allows one to pass
> keyboard events directly to webkitgtk's widget. This is done by
> focusing the webkitgtk widget so gtk passes input events directly to
> it and emacs does not receive them. I did this since I thought it was
> very bad UI to see one's cursor on a web text field, try to interact
> with it, and have nothing happen. I know xwidgets has this injected JS
> workaround that allows one to type in the emacs minibuffer and send
> the text to the html field. However this won't work to, say, tab
> between form fields or use arrow keys to make selections. I'm not sure
> how you'd extend the JS solution to handle all these cases generally.

BTW, I have already implemented something similar: a function
`xwidget-perform-lispy-event' to send Lisp events to an xwidget, and an
`xwidget-webkit-edit-mode' that sends self inserting characters and
arrow keys to xwidgets-webkit.

You can find a recent version of my changes somewhere in the discussion
around bug#51473.

> On keyboard events, there will always be a tension between the CUA
> keys that webkit is hardcoded to use and emac's keys. Someone could
> write the appropriate translation layer, but it'll be a nontrivial,
> likely manual, task and will require constant upkeep as these things
> evolve in webkitgtk. Personally as an evil and former exwm user,
> making keyboard focus a modal distinction is natural.

Yes, but in the meantime I added some items to the menu bar that could
help with tasks such as saving the selection.

> On mouse events, I'm not sure what you will gain by exposing such
> events to lisp first then passing them to webkit. Is there some use
> case this would enable? I can't imagine it being very helpful without
> lisp also knowing what DOM element the mouse event is associated with.
> I would also be worried about latency with the additional redirection.

I'm not particularly worried about input latency, but it would be a bad
thing to enable this for every xwidget.  WDYT about the ability to set
input event masks for individual xwidgets, so people who write Lisp code
can decide which events get passed through right after handling the X
event, and which events get passed through Lisp code first?

> Additionally, until emacs learns to handle xinput 2 type events, you
> might risk losing all the multitouch gestures that webkit supports
> including smooth two-finger scrolling.

Unfortunately, it's impossible to support XInput 2 devices in any GTK
widget running inside an Emacs process at present: it's disabled so GTK
doesn't set an XI2 event mask that prevents Emacs from handling Core
Input events.

I do have a patch that enables XInput 2 support in Emacs, but I don't
have time to work on it right now.

Thanks.