grandad @poire-z wake up from your nap, it's almost Friday now.

Continued from #14901 (comment)

I'm not fond of this hack. From the perspective of the text input the arrow keys don't work as you'd expect or anything; from the perspective of the VK the focus is completely random.

Just to clear up. Focusing on enter is as much a hack as deleting all key events. That is simply my suggestion but if there are others, happy to hear them, otherwise we can't have a working vk at all (with a keyboard), same as before

grandad @poire-z wake up from your nap, it's almost Friday now.

Sorry, I had to take a job at the grocery store... KOReader doesn't pay, and you kids eat (and shit PRs) a lot :/

in case anyone is wondering why the seemingly random QR change, Text Editor has a qr button, and pressing esc was triggering a close event ;)

Testing on Book style tweak editor:
I now always get the "You have unsaved changes" when hitting Esc.

With VK disabled:

• I can now click to move the cursor. No noticable problem when using Physical keyboard (except cursor keys when reaching top ot bottom that move your focus out of text :/)
• ↓⌨ button doesn't work (Shift-Home does)
• (before the previous PR, it was totally unusable, so that's still a lot better)

With VK enabled:

• when launched, I can type text (and Enter), but cursor keys move focus key into the VK (so, I lose the focus on the VK key Enter, and I input other things when I hit Enter :/). I agree that the "start VK with focus on Enter" is an ugly hack - and a volatile one. I think we really can't keep that idea.
• ↓⌨ button works
• some possible refresh on the "You have unsaved changes" when I get it and discard it with Esc:
• (before the previous PR, it was usable as I wished)

The most annoying things in both cases is that, to allow focus navigation, we make the experience quite a bit worse.
I don't know/remember if the emulator is différent from AppImage releases, as for developping we may want to get everything (phyisical keyboard, the virtual keyboard usable with taps/swipes, focus navigation to navigate buttons, and focus navigation on the keyboard to emulate NT).
But on a device with touch, keys and a keyboard, we wouldn't really need focus navigation everywhere (that you need to have on NT): the VK is useful to click on, a full keyboard experience with arrows that stop at boundaries instead of jumping out is welcome, and we can get out of it with taps/clicks elsewhere.

Just to clear up. Focusing on enter is as much a hack as deleting all key events. That is simply my suggestion but if there are others, happy to hear them, otherwise we can't have a working vk at all (with a keyboard), same as before

So, that hack of deleting all key events from focusmanager - I think this comment was about that, right?

        -- hadDPad() would have FocusManager handle arrow keys strokes to navigate
        -- and activate this VirtualKeyboard's touch keys (needed on non-touch Kindle).
        -- If we have a keyboard, we'd prefer arrow keys (and Enter, and Del) to be
        -- handled by InputText to navigate the cursor inside the text box, and to
        -- add newline and delete chars. And if we are a touch device, we don't
        -- need focus manager to help us navigate keys and fields.
        -- So, disable all key_event handled by FocusManager

was not a hack, but what was actually needed to get that experience.

If you indeed want to make the emulator (all devices with touch and keys?) a full NT emulator, I'm not sure it's really for the best (except for making us experience more the experience/torture of using a NT device :).

Yes, I agree it seems better without the VK ever taking focus (except in non-touch mode), making that comment not a hack but simply desired.

I don't know/remember if the emulator is différent from AppImage releases

We do distinguish a mere isSDL and isEmulator in some conditions but this doesn't seem like one where that distinction makes sense. It's mainly for doing things like fake sleeping/screensaver and fake frontlight/warmth dialogs.

I should mention, when the vk is up shift+up/down/left/right move the cursor inside inputtext

right so, I have delivered a system that works equally whether you have a vk on or not. I have consciously uncoupled the state of the vk to typing from. a physical keyboard. @Frenzie I hand over to you what you want to do regarding the issue of the vk on and focus, I trust you'll do whatever you consider best. I'll say one more thing, it is not unheard of, cases where people don't/didn't have a mouse and needed the whole thing to be usable with just the keyboard..

I hand over to you what you want to do regarding the issue of the vk on and focus

Was this PR ready to go besides that enter key hack?

I hand over to you what you want to do regarding the issue of the vk on and focus

Was this PR ready to go besides that enter key hack?

I believe it fixes all the concerns @poire-z had.

One possible concept could look something like this (ignore the styling; I should've probably just used words or an image editor).

That is, an explicit toggle on the element with focus. But maybe a simple Shift+Enter or some such would suffice.

#15055 is the result of peering at my code for probably over 20 minutes before realizing the problem already existed before I changed anything.

Anyway, as to this concept, simply overlaying the button would look something like this (except proper of course):

Interestingly, I didn't realize that that final space already seems to be unused. Trying to put a character there switches the display. That means I took an overly complicated approach to solve a problem that didn't quite exist.

Mind, the patch to switch to overlap is only a few lines so no effort wasted as long as this button concept is used:

diff --git a/frontend/ui/widget/inputtext.lua b/frontend/ui/widget/inputtext.lua
index a69413d83..bb4341fa1 100644
--- a/frontend/ui/widget/inputtext.lua
+++ b/frontend/ui/widget/inputtext.lua
@@ -11,6 +11,7 @@ local HorizontalSpan = require("ui/widget/horizontalspan")
 local IconButton = require("ui/widget/iconbutton")
 local InputContainer = require("ui/widget/container/inputcontainer")
 local Notification = require("ui/widget/notification")
+local OverlapGroup = require("ui/widget/overlapgroup")
 local ScrollTextWidget = require("ui/widget/scrolltextwidget")
 local Size = require("ui/size")
 local TextBoxWidget = require("ui/widget/textboxwidget")
@@ -554,9 +555,6 @@ function InputText:initTextBox(text, char_added)
     end
 
     local text_width = self.width
-    if text_width and show_keyboard_button then
-        text_width = math.max(0, text_width - keyboard_button_width)
-    end
 
     if not self.height then
         -- If no height provided, measure the text widget height
@@ -640,10 +638,9 @@ function InputText:initTextBox(text, char_added)
     }
     local input_row
     if show_keyboard_button then
-        input_row = HorizontalGroup:new{
-            align = "center",
+        self._frame_keyboard_button.overlap_align = "right"
+        input_row = OverlapGroup:new{
             self._frame_textwidget,
-            HorizontalSpan:new{ width = keyboard_button_spacing },
             self._frame_keyboard_button,
         }
     else

In the text editor that would look like this:

Here too it seems characters don't actually want to go in that space.

Here too it seems characters don't actually want to go in that space.

It's either because wrapping (try to input i + space + i + space), or because there's some area on the right reserved for the scrollbar (which is not shown until needed).

But for this InputDialog with some version of the bottom buttons, there is already a button to toggle the VK:
So, for these, no need to add your button (some bit of noise) inside the textbox.

(There is also long-press inside these textboxes that launches a dialot about the clipboard - which could have a Show VK if there's really no other way - but it might be a bit far fetched (I mean it literally :) away from the inputtext).

It's either because wrapping (try to input i + space + i + space), or because there's some area on the right reserved for the scrollbar (which is not shown until needed).

Yes, it seems an extra-thin character can indeed be hidden by this concept in this general form.

So, for these, no need to add your button (some bit of noise) inside the textbox.

It's just a generic multiline textinput. The only reason I used that particular one to take a screenshot is because you keep talking about it. 😄

Oops, I didn't intend to post any of that here. That was meant for #15051.

But for this InputDialog with some version of the bottom buttons, there is already a button to toggle the VK:

This button has no effect when VK disabled - while Shift+Home works and displays the VK (but over these buttons, without adjusting the geometry like this button used to do (and does on Touch devices).

@Commodore64user : can you have a quick look at InputDialog:toggleKeyboard(force_toggle) if you could make this button work on the emulator (it still works fine on my kobo).
I see you added Device:startTextInput() in there:

@poire-z not a fix but a start, maybe you can think about it as well...

diff --git a/frontend/ui/widget/inputdialog.lua b/frontend/ui/widget/inputdialog.lua
index fd5baa402..1785c5272 100644
--- a/frontend/ui/widget/inputdialog.lua
+++ b/frontend/ui/widget/inputdialog.lua
@@ -198,6 +198,7 @@ local InputDialog = FocusManager:extend{
     _buttons_scroll_callback = nil,
     _buttons_backup_done = false,
     _buttons_backup = nil,
+    _vk_startup_skip_done = false,
 }
 
 function InputDialog:init()
@@ -223,9 +224,11 @@ function InputDialog:init()
     if self.fullscreen or self.add_nav_bar then
         self.deny_keyboard_hiding = true
     end
-    if (Device:hasKeyboard() or Device:hasScreenKB()) and G_reader_settings:nilOrFalse("virtual_keyboard_enabled") then
+    if (Device:hasKeyboard() or Device:hasScreenKB()) and G_reader_settings:nilOrFalse("virtual_keyboard_enabled")
+        and not self._vk_startup_skip_done then
         self.keyboard_visible = false
         self.skip_first_show_keyboard = true
+        self._vk_startup_skip_done = true
     end
 
     -- Title & description

Looks like it just work :) (haven't looked why).
What are the caveats ?

Looks like it just work :) (haven't looked why).

What are the caveats ?

The caveats? It doesn't work properly, use the keyboard to toggle it.