FR: Ability to disable virtual keyboard

[tarkeez]

Does your feature request involve difficulty completing a task? Please describe.

KOReader on non-touch devices where you have a physical keyboard could benefit from the ability to disable the virtual keyboard because it just takes up space on screens with input boxes (search etc).

Describe the solution you'd like

Setting to disable virtual keyboard

[Frenzie]

I think the main reason is for special characters, also see #8859. But perhaps that could go in two steps: first minimize, then unfocus.

[NiLuJe]

Back is already bound to close the VK, FWIW.

[tarkeez]

Yeah but from a quick test on PC, pressing back (esc) to hide the keyboard will unfocus the input field or something, as you can't input (edit: with physical keyboard) after that. And other things.

1. Open file search
2. Esc to hide virt keyboard
3. Typing isn't registered
4. Enter key doesn't search, but brings up virt keyboard again (as will clicking the input field with mouse)
5. Can only type with virt keyboard now
6. Esc will close the search box completely from here

I guess it's minor stuff, but hey. I like KOReader on PC (unified interface, highlighting synced across devices, dictionaries all set up, translate working well for multiling reading etc), so it would be nice to be able to contribute to improvements on PC/non touch.

[pazos]

I guess it's minor stuff, but hey. I like KOReader on PC (unified interface, highlighting synced across devices, dictionaries all set up, translate working well for multiling reading etc), so it would be nice to be able to contribute to improvements on PC/non touch.

SDL targets don't receive much love here. After all they're just repackaged emulators.

I think the people who like KO enough to run it on a regular desktop without touchscreen, myself included, takes "unified interface" over specific platform quirks :)

But I wouldn't mind an opt-in hide virtual keyboard option for such targets.

[ryanwwest]

In some issue last year I asked about how to hide it as well, though my request was about dynamically doing it according to keyboard detection and I think there were some challenges with detection. But @pazos 's opt-in idea is much simpler and easier to implement, I like it and would use it.

[Commodore64user]

having just installed KOReader on kindle keyboard (K3), yes please let us hide the virtual keyboard. the way stock works is that you press the Sym key and that way you get access to special characters, otherwise they are just hidden.

Also, kind of related too, the Del key does not actually delete anything.

[Commodore64user]

12078 includes a shortcut to hide the virtual keyboard without losing focus ("Shift" + "Home") albeit, on a case by case basis, so you will have to manually hide it every single time.

Question, is there an equivalent key for "Home" on normal keyboards?

[NiLuJe]

There's a ⇱ button in some widgets (most prominently anything based on the Text Editor).

[Commodore64user]

There's a ⇱ button in some widgets (most prominently anything based on the Text Editor).

Mmmm, i was thinking about actual physical keyboards (like 60% layout ones) that might not have a "Home" key. Is there another key that acts as "Home" there?

[Frenzie]

Ctrl + up/down is the same as Home/End, but why?

[Commodore64user]

Ctrl + up/down is the same as Home/End, but why?

Just making sure it could be used everywhere not just on readers with keyboards.

[Commodore64user]

no promises atm but if one were to embark on this somewhat tedious task, would something like this be acceptable or do you have any other ideas,

replacing all these instances: https://github.com/koreader/koreader/blob/7ebd067a95886392b3894bed0d4a0c50de475b59/frontend/apps/reader/modules/readersearch.lua#L273

with something like:

if Device:hasKeyboard() then
    if G_reader_settings:nilOrTrue("virtual_keyboard_enabled") then
        self.input_dialog:onShowKeyboard()
    end
    return
else
    self.input_dialog:onShowKeyboard()
end

[poire-z]

replacing all these instances:

Well, I'd rather see a single instance of that trick, and not have this in the ~50 places that call it. Are there contexts where you don't want it (readersearch) and others where you want it? If no, it's easier to fix it in the InputText/InputDialog:onShowKeyboard() themselves. If yes, your choices of affected contexts will probably be very personal and questionable :)

[Frenzie]

Setting aside what would be the desired behavior for a second, from a code perspective wouldn't it make more sense to put that general concept at the top of onShowKeyboard.

[Commodore64user]

replacing all these instances:

Well, I'd rather see a single instance of that trick, and not have this in the ~50 places that call it.

Are there contexts where you don't want it (readersearch) and others where you want it?

If no, it's easier to fix it in the InputText/InputDialog:onShowKeyboard() themselves.

If yes, your choices of affected contexts will probably be very personal and questionable :)

Well, that seems like the more reasonable approach, "idiot me" didn't think of it last night, at 3am in the morning 😅