Text editing on mobile

[emilk]

egui_web fails to bring up the virtual keyboard when editing text.

You would think a modern browser would have a function call for "show a virtual keyboard!" but of course nothing is ever that simple in web-tech.

Related issue: #8

[n2]

This problem also occurs on the browser on PC when input method(IME) is needed, it may be caused by the incompatibility of the IME. The virtual keyboard on the mobile device is also an IME window, too. The input candidate window on PC or virtual keyboard on mobile device will pop up only when the browser’s (or native app's) input control gets focus. As we know, from the perspective of the native app or browser, Egui's "text widgets" are nothing more than a set of triangles, not input controls, so there will be no input candidate window or virtual keyboard. Egui_glium can communicate with IME correctly (but not yet complete), because it's window handler, winit, can connect to the input method service of the system and exchange data with it. But as far as I know, there is no similar method on the browser.

[parasyte]

The only way (that I know of) to open an IME window in a browser is by interacting directly with an input element. Some projects like CanvasInput use a hidden input element on the DOM to work.

[emilk]

@parasyte thanks for that reference! The relevant code seems to be https://github.com/goldfire/CanvasInput/blob/master/CanvasInput.js#L125 and onwards. The problem for egui_web is that we don't want to always have a hidden input element on the canvas, or else we'd get the onscreen keyboard popup where-ever the user clicked. I guess we need something like "if the user is hovering over a text fields, add an invisible input element. If the user stops hovering, remove it" (or alternative move it offscreen or something).

This sounds exactly like the kind of hacky web code that I'd rather not have to write. If we can find some other option that would be great, but otherwise I guess this is the way. Any volunteers?

[jgrussell]

@emilk,

Can you give us some idea of your prioritization of this issue?

If not for this issue, egui would be my hands down pick for a Rust GUI framework.

Sadly, I do not currently have the Rust skills to tackle this issue myself.

Thank you very much for all of the work you have already done here. I am already very impressed with this project and hope to actually be able to contribute back in addition to utilizing it in my own projects.

[parasyte]

Honestly, this is mostly DOM/JavaScript work. The Rust parts are hooking into the egui event system so that clicking on a text field can trigger interaction with a hidden input element on the DOM, and allowing egui to receive events from the DOM itself.

If I read between the lines a bit, I believe @emilk is referring to this chunk of DOM and JavaScript work as the part he would rather have someone else work on. 😉

[jgrussell]

@parasyte,

Makes sense. Thank you for the clarification.

I would almost certainly be more hindrance than help with DOM/JavaScript since my last hands-on GUI work of significance was probably Visual Basic 5.0 era.

[n2]

I am on it, maybe some more filds must be added to epi::backend::AppOutput, like "cursorPosition: Option<Pos2>", indicating if egui's text field is focused, and the cursor position. Is it ok? @emilk

[emilk]

Thanks for taking a stab at this @n2 !

Feel free to add what you need! The cursor position shouldn't needed to be added though as far as I can tell, since egui_web already knows the cursor position (AppRunner has an input field where it stores the latest cursor position).

But I do understand egui needs to communicate whether or not the cursor is hovering over a text field. There is a hacky way egui already communicates this: If egui::Output::cursor_icon is set to CursorIcon::Text it is because the cursor is hovering over a TextEdit field. Maybe you can use that for now?

[n2]

Sorry, I did not express the two cursors clearly. In my post, I meant the text cursor in textfield(which is egui::widgets::text_edit::CursorPair), not mouse cursor (whos position is stored in AppRunner.input.latest_touch_pos), app should return position of CursotPair::primary. By having such position, egui backends can not only manipulate hidden input element, but also set IME candidate window to proper position. This is useful for both web and native.
Checking egui::Output::cursor_icon is a good idea, thank you. @emilk

[emilk]

Fixed by #247

[parasyte]

@emilk Should this be closed? Just stumbled upon your last comment while looking for something else.

[emilk]

Ah, yes - thanks for the reminder @parasyte