FR: New Button gestures

[Silther]

I would like to be ably to remap the Buttons of my Pocketbook Inkpad Color.

1. Make it possible to rewind 10 or more pages with holding the scrollbuttons. The longer you hold the buttons, the faster the pages should turn. For convenience compare the turning speed with the build in PBReader.

2. ~Change the top menu so, that the bottom menu does not open as well.~ (EDIT: This is already implemented)

3. Add a setting that allows you to choose what you want to open with the menu button on the pocketbook reader (the 4th button on the far right). Either the top menu, or the bottom menu, or both.

4. Make it possible to close the menu with clicking the menu button again.

5. ~Add a button in the top menu to switch to the bottom menu and and a button in the bottom menu to switch to the Top menu.~ Edit: What was I thinking?

[pazos]

1. Nope (buttons are single action)

2. ---

3. Already implemented: https://github.com/koreader/koreader/wiki/Keymapping
4. Not sure if this is a good suggestion or a bad one. I can see its appealing.
5. Oh, god, no!

[Silther]

1. But why can the normal PB reader do it?

3. I don't really know how that should work.

4. Couldn't you add a setting for this? With a pocketbook reader you are able to deactivate the touch screen, once the menu is opened with the button, you can't close it without the touch screen.

5. Yes that would just be waste of space.

[pazos]

But why can the normal PB reader do it?

Because it is possible. I wasn't talking about some other software. I was talking about how key events work in KOReader.

Each button you press generates a key event. Each key event has an unique key code, which is mapped to a certain action. Keymappings are possible on the 99% of keys (probably all in pocketbooks except for the home key) so it is possible for the user to override defaults (following the link in 3).

Your request is not possible with our current key event handler.

Couldn't you add a setting for this?

I lack knowledge about the desired behaviour for Non Touch devices. The same behaviour should be preserved (ie: pressing the key mapped to the menu action when the menu is already shown should do the same in all devices). Pinging @comphilip about feedback.

[NiLuJe]

If this weren't PB, 1. would work (mostly[1]) out-of-the-box, assuming the hardware generates KEY_REPEAT events. But this is PB, so of course that's a no go (I assume) ;).

[1] By which I mean there's no inertia scrolling handled, it just skips pages as usual. Someone invested enough in the feature could make it work, though. That wasn't my case ;).

Keep in mind there are very few active contributors with a PB device, so any PB-specific queries are probably going to be met with a big "meh" ;).

[Frenzie]

If this weren't PB, 1. would work (mostly[1]) out-of-the-box, assuming the hardware generates KEY_REPEAT events. But this is PB, so of course that's a no go (I assume) ;).

That's what I was thinking.