I regret not naming this “consciously uncouple text input state from VirtualKeyboard visibility” ;)

InputText: explicit calls to Device:startTextInput and Device:stopTextInput are now made during focus and unfocus. This ensures the physical keyboard works whenever an input field is active, regardless of UI state.

I don't understand what this means. What UI state is there, except for focus?

InputText: explicit calls to Device:startTextInput and Device:stopTextInput are now made during focus and unfocus. This ensures the physical keyboard works whenever an input field is active, regardless of UI state.

I don't understand what this means. What UI state is there, except for focus?

FocusManager controls the buttons, so for the dictionary one for example, you have the buttons handled by FM and input text. what I am doing is simply locking keyboard inputs to input text only. so typing words when input text is not in focus should be ignored and/or swallowed by FM

Right, but surely that is making it obey UI state rather than regardless of UI state.

Right, but surely that is making it obey UI state rather than regardless of UI state.

all I am saying is, focus is exclusive, only one thingy can accept keyboard events at once... which solves all the issues mentioned in the long comment, is brilliant.

that start thing does need to go in init though... I just placed it in the wrong init which incidentally made it work which is why I hadn't noticed it was the wrong one

the last remaining question now is: what's the default? vk off or vk on?

that start thing does need to go in init though...

Hm, they actually share the problem. They both fire regardless if they have focus or not. This remains improper.

It'll do for now. For reference, the behavior I want would look something like this:

diff --git a/frontend/ui/widget/focusmanager.lua b/frontend/ui/widget/focusmanager.lua
index 4f7d3dffb..2f0cf83a6 100644
--- a/frontend/ui/widget/focusmanager.lua
+++ b/frontend/ui/widget/focusmanager.lua
@@ -337,6 +341,10 @@ function FocusManager:moveFocusTo(x, y, focus_flags)
         logger.dbg("FocusManager: Move focus position to:", x, ",", y)
         self.selected.x = x
         self.selected.y = y
+        if not self.focus_initialized_sent then
+            target_item:handleEvent(Event:new("FocusInitialized"))
+            self.focus_initialized_sent = true
+        end
         -- widget create new layout on update, previous may be removed from new layout.
         if bit.band(focus_flags, FocusManager.FORCED_FOCUS) == FocusManager.FORCED_FOCUS or Device:hasDPad() then
             -- If FORCED_FOCUS was requested, we want *all* the events: mask out both NOT_ bits
diff --git a/frontend/ui/widget/inputtext.lua b/frontend/ui/widget/inputtext.lua
index c4d3907b4..fd22e66e6 100644
--- a/frontend/ui/widget/inputtext.lua
+++ b/frontend/ui/widget/inputtext.lua
@@ -71,6 +71,10 @@ local InputText = InputContainer:extend{
 
 -- These may be (internally) overloaded as needed, depending on Device capabilities.
 function InputText:initEventListener() end
+function InputText:onFocusInitialized()
+    print("InputText:onFocusInitialized()")
+    Device:startTextInput()
+end
 function InputText:onFocus() end
 function InputText:onUnfocus() end
 

here's why vk won't work when touch is enabled

this is what I think it should be

  elseif key["Back"] then
      if G_reader_settings:nilOrTrue("virtual_keyboard_enabled") and self.focused then
          if self.parent and not self.keyboard:isVisible() then
              UIManager:close(self.parent)
          end
      elseif self.parent then
          UIManager:close(self.parent)
      end

lol, which is really just

        elseif key["Back"] then
            if self.parent and not self.keyboard:isVisible() then
                UIManager:close(self.parent)
            end

but it would require this block to go entirely

and also doing away with the removing of all FocusManager events as seen here #14901 (comment)

that would mean both touch and non-touch handle vk similarly

dialog+vk = vk takes priority and is in focus, first back closes vk and gives back control to inputdialog but physical keyboard continues to work fine... second back closes inputdialog
dialog+vk_disabled = magic, it works perfectly plus one can bring up vk with shift+home and it focuses and works

awaiting confirmation

Sounds good to me, but I can't check the code until at least tonight.

blimey, @Frenzie merging this so fast it reminds me of that cartoon bird that exits the frame so fast it leaves half his feathers behind. Tell me you hate the virtual keyboard without telling me you hate it. ;)

I already wanted to do the focus up/down thing years ago, but I forgot about it.

Something that may be was forgotten when testing: InputDialog as used in Text editor (or Edit book style tweak).
The VK gets the focus, and I can't type Enter to add a line: the char 1 (VK has focus on it I guess) gets outputed.
Previously, I could edit without issue while the VK was displayed. Now I have to reduce it to be able to edit freely.

yes, that is a sacrifice for the greater good. We had to remove that trick you @poire-z and @johnbeard implemented a while a go of removing all events when a device had a touch screen. Now it works the same everywhere which should be much easier to maintain, but furthermore, even though it is a slight inconvenience, you can hide the vk so should not be a problem. As far as I am concerned, good riddance virtual keyboard. ;)

yes, that is a sacrifice for the greater good. We had to remove that trick you @poire-z and @johnbeard implemented a while a go of removing all events when a device had a touch screen. Now it works the same everywhere which should be much easier to maintain, but furthermore, even though it is a slight inconvenience, you can hide the vk so should not be a problem. As far as I am concerned, good riddance virtual keyboard. ;)

I don't think you mentionned that sacrifice, if you knew about it ?
I guess you mean this?

        -- 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

I get that Up/Down, when reaching first line or last line, could change focus (it's a little inconvenience, but understandable).
But Enter ? It's an inconvenience that makes it unusable: you have to get rid of the keyboard (after witnessing that change of focus), or disable it entirely.
What would it cost to reintroduce it on multilines inputtext (if we can know about that) and/or on other conditions ?

I'm fine reverting the VK changes, but different handling for multiline is probably pretty simple (no time to look the next few hours).

It's not essential for the stable release, it would affect mostly us emulator developpers.
But I'd like we don't forget to give it a bit of thoughts.

You can also use the enter key on the virtual keyboard, is not unusable. I haven't try to hide anything btw, not sure why such allegations are being made when it is you @poire-z who has lately been covering your eyes in the hopes that the sun goes away ;)

But i don’t consider this a major problem given that, as soon as everyone is aware vk can now be hidden for good, no one will have this problem, perhaps what could be done is to focus on the virtual enter key when in those full screen modes..

There are other little issues.
Just playing with Book style tweaks.
With VK enabled: I can input from the physical keyboard (PK). If I use the ↓⌨ button to hide the VK, I can't input at all (but then, only Enter and arrow keys work :). (Feels a lot worse than before, going to disable VK so at least, I can go on testing style tweaks.)
With VK disabled, it's ok (it was really bad before this PR, looks like I couldn't input at all). Except that when I mouseclick into the text to reposition the cursor, the VK appears and it's a mess).
After 30 mn playing with style tweaks, with VK disabled, I can say that the experience is worse than before with the VK enabled (or maybe I got used over the years not using keys/buttons/clicks that caused issues).

Also, wheter VK enabled or disable, now, just hitting Esc quits the text editor, even if you have made changes. Before this PR, we always got that popup "You have unsaved changes".

@Commodore64user

But i don’t consider this a major problem given that, as soon as everyone is aware vk can now be hidden for good, no one will have this problem

Once non-VK mode works well enough (which is possibly now already) it can be hidden by default on hasKeyboard, except in isEmulator. The global setting will still override it in both scenarios.

[Edit:]Actually, that might imply extending the setting to on/off/auto to account for dynamic keyboard plugging.[/edit]

@poire-z

Also, wheter VK enabled or disable, now, just hitting Esc quits the text editor, even if you have made changes. Before this PR, we always got that popup "You have unsaved changes".

We'll look into it. I suspect @Commodore64user and I already landed on the solution earlier.

(Updated a few times my post above. I'm done playing, so hopefully no more live updates.)

Except that when I mouseclick into the text to reposition the cursor, the VK appears and it's a mess).

This sounds more like a failure in the previous PR where hiding the vk was introduced, there must be a function somewhere where we don't check for the vk_enabled setting so it simply pops it up. Something that perhaps went unnoticed.

After 30 mn playing with style tweaks, with VK disabled, I can say that the experience is worse than before with the VK enabled

Okay grandad, what exactly is "worse" not wasting half the scree on an unnecessary keyboard??

Actually, that might imply extending the setting to on/off/auto to account for dynamic keyboard plugging

We are quite careful as to how the setting works, even if on a touch device with a bt keyboard, if you set it to hide and then disconnect the bt keyboard (i.e., you have no physical keyboard anymore) we will show you the vk, all i'm trying to say is, i don’t know how detection should work but the dumb method shouldn't fail

I already landed on the solution earlier.

I believe asking the parent politely solves it

Okay grandad, what exactly is "worse" not wasting half the scree on an unnecessary keyboard??

Hey, I'm giving you feedback, I'm not being aggressive.
Yesterday, I tested it quickly without having any real thing to do, so not really seriously it seems :/
Today that I have to try it with real editing, I notice these annoying things: I'm just telling you.

Having some keys working, clicking in the text and getting the keyboard popup, and having nothing much working, and having to put it down each time - is more annoying than the natural editing without any annoyances (keyboard and clicks working) I had before with the VK shown. And on the few lines snippets of CSS, the VK isn't annoying at all.
May be solving the VK popup when it is disabled will solve the situation with VK disabled.
(But it remains that for CSS, having the VK enabled was fine, and it allowed for a quick swipe on , to get !important output'ed.)

It's good that you make simple inputtexts and focus navigations better for NT, but the "sacrifice" (anticipated or not) of a good experience with text editor on the emulator is a big price to pay.

(Haven't checked if the small InputDialog, ie. editing a highlight note, has issues.)

PS: Grandad trusts you kids will make it all better. Kisses.

We are quite careful as to how the setting works, even if on a touch device with a bt keyboard, if you set it to hide and then disconnect the bt keyboard (i.e., you have no physical keyboard anymore) we will show you the vk, all i'm trying to say is, i don’t know how detection should work but the dumb method shouldn't fail

Okay, so hide itself is already auto. That sounds good.

I believe asking the parent politely solves it

Yes, that's what I said, including that check in case the parent doesn't meet that assumption. ^_^

It's good that you make simple inputtexts and focus navigations better for NT, but the "sacrifice" (anticipated or not) of a good experience with text editor on the emulator is a big price to pay.

Like I said, I'm not attached to that change at all and it can presumably be delayed if we can't find a better solution within the next few days. I merely commented on the discrepancy because it caused me some momentary confusion, not as a silent hint that it should be fixed ASAP. ;-)

this seems to be the reason for the keyboard popping up regardless os state, the only worrisome thing is that comment though, as we DO need self:focus() for the keyboard to work, ideas?

What do you mean by "this" concretely? Since it says showKeyboard in a separate condition doesn't that simply imply changing the condition? In fact couldn't you just change those three lines to self:onShowKeyboard() because that already seems to include such a relevant check?

Ahem, it doesn't, or at least not exactly. I had added some code there earlier for testing and forgot about it.

function InputText:onShowKeyboard(ignore_first_hold_release)
    if (Device:hasKeyboard() or Device:hasScreenKB()) and G_reader_settings:isFalse("virtual_keyboard_enabled") then
        return true
    end
    if self.keyboard then
        self.keyboard:showKeyboard(ignore_first_hold_release)
    end

Edit:
I.e., like this (but this isn't a suggestion — I've barely given it any thought at all).

diff --git a/frontend/ui/widget/inputtext.lua b/frontend/ui/widget/inputtext.lua
index dae8cbd3c..492b9a0d6 100644
--- a/frontend/ui/widget/inputtext.lua
+++ b/frontend/ui/widget/inputtext.lua
@@ -142,9 +142,7 @@ local function initTouchEvents()
             if self.parent.onSwitchFocus then
                 self.parent:onSwitchFocus(self)
             else
-                if self.keyboard then
-                    self.keyboard:showKeyboard()
-                end
+                self:onShowKeyboard()
                 -- Make sure we're flagged as in focus again.
                 -- NOTE: self:focus() does a full free/reinit cycle, which is completely unnecessary to begin with,
                 --       *and* resets cursor position, which is problematic when tapping on an already in-focus field (#12444).
@@ -781,6 +779,9 @@ dbg:guard(InputText, "onTextInput",
     end)
 
 function InputText:onShowKeyboard(ignore_first_hold_release)
+    if (Device:hasKeyboard() or Device:hasScreenKB()) and G_reader_settings:isFalse("virtual_keyboard_enabled") then
+        return true
+    end
     if self.keyboard then
         self.keyboard:showKeyboard(ignore_first_hold_release)
     end

Edit 2: but regardless of the specific solution, the condition should probably be something along those lines.

this is my idea, during vk's init we do,

    if self.layout and #self.layout > 0 and Device:hasKeyboard()
       and self.inputbox and self.inputbox.parent then
        local last_row = #self.layout
        local last_col = #self.layout[last_row]
        self:moveFocusTo(last_col, last_row)
    end

Could you clarify what that does?

Sorry, when the vk is visible, it sets focus to the enter key, that way if you press enter on the keyboard (at least assuming you don’t move it) you get an enter press. It’s a hack as much as deleting all the key events was..