(Please try to not miss answering any of my questions :) you often do when I ask many :))

From what I can gather from your screenshot and a quick glance at the code, you are fixing the issue that with Keyboard > Show VK disabled, there was no way to get the VK to show up (to input foreign scripts chars for example) on MultiInputDialog (&co, even a simple InputDialog to do a dict lookup?), right ? And only that? (Which wasn't really my main issue :) more on it below.)

I initially felt it a bit odd that any mediumly heavy UI stuff would happen in InputText itself (low level widget), felt it would rather be InputDialog (upper level).
But after a bit of thinking, it feels alright, it is fine being a feature of an individual InputText itself. (And InputDialog is already busy with heavier UI stuff, so best to not overpower it.
So, fine with that.
Hoping it won't conflict with the fullscreen and non-fullscreen (ie. highlight note editing) of InputDialog with a large InputText.

My main issue with the current state is with the fullscreen InputDialog (ie. Book style tweak editing), which already has a button to popup the VK (which reduces the InputText height when the VK shows up):

• if VK disabled, tap on this button doesn't do anything
• if VK enabled, it shows on launch - but has focus and any cursor/arrow keys moves in that VK - and I think the simple (maybe not the best) solution to that could be to just, on devices with touch, to lose most/all the focus navigation (not sure if that means exactly: restore the previous behaviour), so we never leave the InputText (as we can use touch to use the buttons or the VK), even when reaching top or bottom lines. (On devices without Touch, I don't really care, but that's what @Commodore64user must have make work perfectly).

So, I hope these last points are on your roadmap :)

there was no way to get the VK to show up (to input foreign scripts chars for example) on MultiInputDialog

this is not true though, shift+home has always been an option

I still don't believe @poire-z has a valid reason to request having vk on be treated differently. I also don't understand how you have gone from, it annoys me to have a vk to, I don't want to live without it, alas that is irrelevant.

the facts are, vk is always ready on demand via shift+home. isTouch should not get preferential treatment simply because one feels is nicer not to have to deal with one's own choices (having it there). The main problem has been solved, all of @NiLuJe's concerns were addressed even if

I initially felt it a bit odd that any mediumly heavy UI stuff would happen in InputText itself (low level widget), felt it would rather be InputDialog (upper level).

you know this was the reason for all those problems, and I am happy you realise

But after a bit of thinking, it feels alright, it is fine being a feature of an individual InputText itself. (And InputDialog is already busy with heavier UI stuff, so best to not overpower it.

that this was the right approach ;).

From what I can gather from your screenshot and a quick glance at the code, you are fixing the issue that with Keyboard > Show VK disabled, there was no way to get the VK to show up (to input foreign scripts chars for example) on MultiInputDialog (&co, even a simple InputDialog to do a dict lookup?), right ? And only that?

No, the issue I'm fixing is that the virtual keyboard annoyingly pops up constantly while merely navigating around, whether by keyboard or gamepad, unless you disable the virtual keyboard completely. For the end result the distinction might not matter.

Hoping it won't conflict with the fullscreen and non-fullscreen (ie. highlight note editing) of InputDialog with a large InputText.

Whether it conflicts or not is merely a matter of what we tell it to do, but I'm not sure what you mean by conflicts exactly. Afaik it simply works everywhere but of course I haven't tested every individual textbox while it's still in the poc phase. There may be some focus-related events in some widgets that need some minor adjustments. For highlight note editing that currently means it looks like this:

if VK enabled, it shows on launch - but has focus and any cursor/arrow keys moves in that VK - and I think the simple (maybe not the best) solution to that could be to just, on devices with touch, to lose most/all the focus navigation (not sure if that means exactly: restore the previous behaviour), so we never leave the InputText (as we can use touch to use the buttons or the VK), even when reaching top or bottom lines. (On devices without Touch, I don't really care, but that's what @Commodore64user must have make work perfectly).

You're pretty much just describing this PR? Please just try it to see the behavior, otherwise I'd have merely posted a recording. ;-)

the facts are, vk is always ready on demand via shift+home. isTouch should not get preferential treatment simply because one feels is nicer not to have to deal with one's own choices (having it there).

The fact that we lose focus when reaching the top or bottom lines to get to the buttons above or below, it is odd as hell, I've never seen that (ie. in this here web browser textarea box). It may be the only solution on non-touch devices, but it shouldn't be there when they are other ways to get to them.
On fullscreen InputDialog, there is a button to show the VK, one doesn't have to know about Shift-Home (which is not a natural shortcut to that on a PC).

The main problem has been solved, all of @NiLuJe's concerns were addressed even if

Great, so you solved your main problem.
Let us fix the new ones you introduced.

and I'd like to stress one more thing, whether isTouch or not, the thing needs to be fully functional just with keys... mouse input going mad is a real thing #15019, koreader/koreader-base#2154

one doesn't have to know about Shift-Home (which is not a natural shortcut to that on a PC).

I'm sorry, it needed to be keys that all supported devices had, blame the k4

it is odd as hell, I've never seen that (ie. in this here web browser textarea box)

most places use Tab to move that kind of focus.

It may be the only solution on non-touch devices, but it shouldn't be there when they are other ways to get to them.

In that case I misunderstood. I'm not sure if I want to change that in this PR though.

the thing needs to be fully functional just with keys...

Yup, that's exactly what this PR is about. I don't find it to be entirely usable on master right now with just keys, and with this PR I do.

OK, trying it.

(The pencil icon feels a little odd taking some room, but ok.)
But here, when I press it and have the VK shown:

• I can't click my mouse in the text to move the cursor there, nor can I move that cursor with the keyboard arrow keys, I'm stuck with focus on the VK - having focus navigation is annoying
• if I then discard the VK, I can move with arrow keys, but still can't move the cursor with mouse click
• if I move to the first char or the last char and away, focus moves to the pencil icon

Some minor observations (just to keep track them, I understand it's a POC :))
When moving to the pencil icon, and back to text, both have the focused border:

The change of geometry/size, inducing a change of where text wraps, is a bit odd (I'd rather keep the button visible if there is no way to have it elsewhere):

Hoping it won't conflict with the fullscreen and non-fullscreen (ie. highlight note editing) of InputDialog with a large InputText.

Whether it conflicts or not is merely a matter of what we tell it to do, but I'm not sure what you mean by conflicts exactly.

I guess I meant this :):

(Same display issue if I hardcode show_keyboard_button = false.)

So, nothing against the idea of that button, but we need to be sure that the new option it adds to the already many possible combination (VK setting disabled/enabled, VK shown/unshown, hasKeys, fullscren, ... now that button active/not) don't make it all harder to grasp and some combinations (whose number has now doubled) don't fail :/

and I'd like to stress one more thing, whether isTouch or not, the thing needs to be fully functional just with keys... mouse input going mad is a real thing #15019, koreader/koreader-base#2154

Well, then we'll fix mouse input. No need to throw as most users without mouse problem that when he reaches first line with arrow keys, he needs to lose focus because users with mouse problem might need a way out :)

one doesn't have to know about Shift-Home (which is not a natural shortcut to that on a PC).

I'm sorry, it needed to be keys that all supported devices had, blame the k4

And it's just fine it being available, but if a most obvious way works the better.

So, nothing against the idea of that button, but we need to be sure that the new option it adds to the already many possible combination (VK setting disabled/enabled, VK shown/unshown, hasKeys, fullscren, ... now that button active/not) don't make it all harder to grasp and some combinations (whose number has now doubled) don't fail :/

Conceptually I see two primary viable approaches (yes, I'm ignoring Shift+Home):

1. This approach, meaning a button somewhere. It could be drawn on top instead of taking up space, but that seems annoying. Showing them all in advance is quite ugly and a bunch of work went into exactly not doing that. But as far as multiline goes I haven't given it any thought yet. Mind, the current visuals are also just to illustrate the concept. My question was really just about the FocusManager behavior since everything else is details, but I now understand you're not fond of that at all since that was already there. :-/
2. An explicit enter/exit. I tried this already but I wasn't fond of it because it kills enter to search and such.

But as far as multiline goes I haven't given it any thought yet. Mind, the current visuals are also just to illustrate the concept. My question was really just about the FocusManager behavior since everything else is details, but I now understand you're not fond of that at all since that was already there. :-/

Well, you indeed got that I'm annoyed by the focus navigation getting in the way of cursor moving :)
But for small (one-line) (multi)InputDialog, focus navigation can be good (ie. to switch fields, but as mentionned above, Tab / ShiftTab might be better when we have that key, ie hasKkeyboard()), and your Pencil icon could make sense .
It's for single multi-lines InputText that it should probably be disabled (explicitely, or the InputDialog deciding it depending on existing other properties) (or accessible with Tab or Touch).

ie hasKkeyboard()

It will require some architectural changes for gamepads, but that's not urgent. When you're using a gamepad you don't always want to grab a keyboard even though you can. SDL is currently always defined as hasKeyboard, which is usually true, but SDL can also be used to run on devices that technically don't have one (i.e., Linux phones/tablets.)

Tab / ShiftTab might be better when we have that key

That should be fairly easy to adjust and it would align with how those already work elsewhere. I'll close this draft and I'll start a new branch based on this one to do the adjustments, because I really enjoy how well it currently works with a gamepad, but getting regular keyboard behavior right has higher priority.

@poire-z But while tab doesn't make much sense in a single-line TextInput, what about the multiline one? Currently it seems to insert a tab (or is it 4 spaces). Maybe multiline would need the enter/exit logic regardless, since the other logic I wrote here doesn't work on it very well.

But while tab doesn't make much sense in a single-line TextInput, what about the multiline one?
Currently it seems to insert a tab (or is it 4 spaces). Maybe multiline would need the enter/exit logic

It might matter in multiline inputtext. Maybe not in a "Add note" one (although I don't know, people may like it), but in Text Editor or Book style tweak, one may want to use Tab for text indent.

Maybe multiline would need the enter/exit logic regardless

I'm not sure I get what you mean by "enter/exit logic" (you already mentionned that above), is it different from the current focus/unfocus ?

It means focus on the field doesn't automatically enter editing mode. @Commodore64user had implemented something like that in an earlier version.

For simple text input that's an inconvenience that can be avoided, but if things like tab are overloaded it's unavoidable for multiline.

Also I'd like to point out that the tab user experience is significantly worse than the FocusManager user experience.

The spatial navigation standard is shift+arrow keys. I'll implement both.

It means focus on the field doesn't automatically enter editing mode

So, once focused, you'd need to press Enter to be able to use the keyboard ? Feels odd :)
And then, how will you implement toggling the VK ? or does this "Enter" auto-popup the VK ? Were you just annoyed with the VK popup while you were focus-navigating , and you are just fine with it always poping up when "Enter" ?
Then I guess if "Show VK" is disabled, you won't have that popup, but we still need to allow getting it to popup (so, only Shift-Home it is?)

Well, then we'll fix mouse input.

that is not quite the point though. You should always be able to control everything without needing to reach for the mouse.

I actually quite like the up/down behaviour @Frenzie came up with, even if it slightly feels punishing, one is always one key press away from returning to the input box.

I am not entirely sure what exactly @poire-z expects from having a virtual keyboard up? and no, disabling all events is not the answer...

So, once focused, you'd need to press Enter to be able to use the keyboard ? Feels odd :)

I don't see how else you intend to use tabs both for text input and for navigation. You need a mode switch for that.

Were you just annoyed with the VK popup while you were focus-navigating

Yes, that automatic popup is the problem, or the immediate focus on the virtual keyboard to be precise. It makes the program very hard to use, and I don't find disabling the virtual keyboard satisfactory. It needs to be both out of the way and easily and intuitively accessible. This PR provides a solution to that problem that I think works rather well with both keyboard and gamepad. The primary alternative to me is to change nothing except to assign Left and/or Right Trigger to the same action as Shift+Home. It's much less intuitive but otherwise about the same.

and you are just fine with it always poping up when "Enter" ?

I'm not sure if that necessarily follows, but either way that's a far cry from interfering with basic navigation.

I am not entirely sure what exactly @poire-z expects from having a virtual keyboard up?

Being able to access other keys/layouts that are not available on your physical keyboard (arabic, chinese, all the symbols and punctuations we get on long-press on the digit keys), which might be useful in notes:

It's not that I personally often need it, it's just that it is/was there, sacrificying its availability on the altar of NT usability it a bit much.

that is not quite the point though. You should always be able to control everything without needing to reach for the mouse.

I'd say that when you are in a InputText, arrow keys should just move the cursor. You could use Esc to... escape that InputText prison :) - hitting you head/cursor against the walls and magically getting out is nice, but a bit too SciFi :)

I don't see how else you intend to use tabs both for text input and for navigation. You need a mode switch for that.

I'm not insisting on the Tab idea, I was just saying it's what usually used everywhere (even in this textbox, and it is annoying :)).
It feels it would be intuitive in a MultiInputDialog (where you would hardly need TAB) to switch fields.
But not welcome in a single multiline InputText (although probably ok in small ones like "Add note") - but you would need another way to get out of it for focus navigation to the Cancel/OK buttons.
But for technical multiline InputText (mostly the fullscreen ones), TAB and arrows key should be left to InputText, and I would sacrifice focus navigation if there is no solution (Esc could be one) and have to resort to touch to get out of it.

sacrificying its availability on the altar of NT usability it a bit much.

this, in my opinion is your problem right here. You see this as a non-touch thing, when in reality, all of this has nothing to do with NT and all to do with hasKeyboard. Yes, I am the NT guy, but none of these vk changes have anything to do with that and all to do with the fact that we shouldn't have to have a virtual keyboard up for a real keyboard to function properly.

I do like @Frenzie's idea because it requires less effort from the user, you don't have to remember shift+home.. but I feel @poire-z keeps coming up with obstacles that can be reworded simply as, but I don't like the change...

this, in my opinion is your problem right here. You see this as a non-touch thing, when in reality, all of this has nothing to do with NT and all to do with hasKeyboard.

Indeed. While Kindle NT does have some unique properties, nearly all improvements to d-pad/arrow keys + enter apply to any device that has those available. Which even includes touchscreen Kobos if you hook up a gamepad or keyboard over BT or USB OTG.

sacrificying its availability on the altar of NT usability it a bit much.

this, in my opinion is your problem right here. You see this as a non-touch thing, when in reality, all of this has nothing to do with NT and all to do with hasKeyboard

Well, I use "NT usability" because I hope these latest changes are at least an improvement in that context - which I have no experience with.
If you say it's all rather some "haskeyboard" improvements, well, I can't agree :)
So, "focus navigation" rather than NT and haskeyboard?

So, I rephrase: sacrificying VK availability (and arrow keys in-text navigation) on the altar of focus navigation is a bit too much.

But may be you're both too focused on the navigation between small input texts (which I happen to rarely meet) and I'm too concerned with the fullscreen editors (where the changes do feel like a regression in usability).

I do like @Frenzie's idea because it requires less effort from the user, you don't have to remember shift+home.

If Enter is just to get the VK after focus - but if once you get focus we can start typing with the physical keyboard, I guess I'm fine with that.

but I feel @poire-z keeps coming up with obstacles that can be reworded simply as, but I don't like the change...

I have tried to explain why I don't like the changes. Mostly to give you some food for thoughts. You're probably be on a diet.

and I'm too concerned with the fullscreen editors (where the changes do feel like a regression in usability).

This poc isn't about those. I haven't paid attention to them because otherwise it wouldn't be a poc. ;-)

where the changes do feel like a regression in usability

"but I don't like it" strikes again... having a vk there wasn't a feature, it's wrong. Name any other software where people need to have both a virtual keyboard and physical keyboard in order to function properly

but I feel @poire-z keeps coming up with obstacles that can be reworded simply as, but I don't like the change...
"but I don't like it" strikes again...

I don't feel like it, continuing discussing that with you, if that's what I shall get.

but explain to me, how is it exactly a regression to remove something that took half the screen for no real reason? but remember the argument that odd symbols were much easily accessible won't cut it because that was just wrong to begin with, no other programme requires a vk to function properly, you know that.

for what is worth, I just checked how kindle 3 handles cursor/focus when adding notes (which is the only large-ish text box I could find) and it does the same, arrow keys move the cursor around until you reach the last line where it jumps focus to the button row. it doesn't loop around but then again that is consistent with their whole system wide no loops.

can you @poire-z name an example of how this disrupts your adding of tweaks? like at worse you'd be a key press away from getting back to the text input box

And that's probably perfectly fine on Kindle, as there are probably no other easy way to get out of the text box.
But on a PC where touch or tab is available (like in this web browser input text box), this never behave that way.
Disruption (that has happened many times just this weekend testing CSS): I may hit ↓ quickly multiple times to get on the last line, or ← to get to the start. If one hit too much, I'm out of the text box.
(Getting back may a few key-presses away - and I was rather getting back with a mouse click - after the few seconds to realize what happened, but that is currently a bad experience.)

But on a PC where touch or tab is available (like in this web browser input text box), this never behave that way.

That's not entirely true. Spreadsheets for example behave exactly like that, and that's one of the reasons people (ab)use spreadsheets as databases. They're just much simpler to use than awkward tab/shift+tab.

(Getting back may a few key-presses away - and I was rather getting back with a mouse click - after the few seconds to realize what happened, but that is currently a bad experience.)

For the near future I'll interpret that as the general approach is fine, but it might need some tweaks for multiline usage. While I don't quite agree with the above, the simple fact is that [in a multiline textinput] it's too difficult to reach the previous/next input and that requires a solution.

Spreadsheets are even worse: I don't know how to focus (with keys to get my cursor in the cell - I need to use mouse double-click), arrows AND enter switch cells.

(So, maybe there are 2 kinds of people: those who like spreadsheets, and those who go to sea.)

This behaviour may be good for multiinputdialog, with many one-line inputtexts. But not on single inputtext (ie. Add Note) where you may multiline and navigate around and would rather have a captive cursor.

Anyway, go ahead and make that release.