I would like to politely request permission to make an illegal move

to turn this:

into this:

function ReaderConfig:registerKeyEvents()
    if Device:hasKeys() then
        self.key_events.ShowConfigMenu = { { { "Press", "AA" } } }
        if Device:hasSymKey() then
            self.key_events.ShowConfigMenu = { { "AA" } }
        end
    end
end

What would you do with Press?

currently, three buttons call up the bottom menu on k3 press, enter and AA. that bothers me very much. btw press and enter are considered to be the same, even though they generate different key codes and are two separate physical keys.

What would you do with Press?

mmm, nothing? refresh the screen?

I don't understand how it could bother you to have a super convenient way to bring up the menu while navigating, but everything you wrote there screams user patch imho.

I don't understand how it could bother you to have a super convenient way to bring up the menu while navigating, but everything you wrote there screams user patch imho.

For a start there's three buttons, and two of them only do half the work, by that i mean they open the bottom menu but cannot close it (because now they have to work as select). Aa is only one that satisfies both opening and closing just fine.

Is not really any more convenient as far as i am concerned, as accidental triggers seem to happen (to me at least) sometimes. I understand why is needed on k4 (unless...) but on the other kindles is just not.

they open the bottom menu but cannot close it (because now they have to work as select)

Which is fantastic. You press, press, press exactly where you want to go. If you don't like it, user patch, don't mess things up for other people.

they open the bottom menu but cannot close it (because now they have to work as select)

Which is fantastic. You press, press, press exactly where you want to go. If you don't like it, user patch, don't mess things up for other people.

It isn't fantastic, particularly when is something you only visit maybe once per book. I'm not happy with the outcome, but I was kind of expecting this answer, so. ;-)

I tried building one but ended up getting that "no engine" error or whatever.

@Frenzie feel free to merge this. nothing else is happening here

I think I found a way to solve two problems in a reasonable way @Frenzie. Because I don't want it to look like I am trying to scurry around this previous discussion, I want to be upfront about it.

I do want to use "Press" for refreshing the screen albeit, I won't force it on anyone so instead, a user can decide to do just that. On k4, the bottom menu should appear as an extra icon at the top of the screen and on <k3 well, nothing as there is a dedicated Aa that would handle it.

I have this so far master...Commodore64user:KOReader_fork:refresh-screen if you want to have a look, however I still need to figure out why the FullRefresh event won't actually refresh the screen...

I suppose, though I have some fear that might be entering technical debt territory.

the other possible thing is to do the switcheroo. Basically have mod+press do the screen refresh (so everyone gets it either way) and move the current add location to stack to this setting. So it would be something like add location to stack with press key. And the point to doing this, is that eventually this would change to page browser with press key. essentially a placeholder for the time being.

That seems a lot less like a hack.

okay, I bit the bullet and, have been trying to get a "gestures" like plugin for shortcuts.

I've gotten the UI side of it, but still needs more stuff and I could use some help here, https://github.com/koreader/koreader/compare/master...Commodore64user:KOReader_fork:shortcuts?expand=1

any chance @poire-z or @NiLuJe are bored looking at flies passing by?

Not bored enough, sorry.
But you may want to name all this more specifically than just "shortcuts", which can have other meaning (folder shortcuts, book shorcuts...)
KeyShortcuts, KeyMaps...

What kind of stuff? (I don't really have time atm though)

Agreed on the shortcuts thing. Keyboard shortcuts?

What kind of stuff? (I don't really have time atm though)

well for one, matching the shortcuts with the actual key presses.

https://github.com/Commodore64user/KOReader_fork/blob/9f01cdc84a18b7b6f5f37ffad4eb56b2cbf83639/plugins/hotkeyshortcuts.koplugin/main.lua#L240-L249

I would prefer to table.insert ^ that ^ as well to the existing array but was not able either.

another thing, for some reason the shortcuts that use screenkb or shift show up fine but the ones with alt appear as %1 instead of using their names. In any case, it would be very helpful if someone could have a look at the whole thing because I won't certainly be able to continue without help. It's a kinda, pick a spade and start digging kind of situation here atm.

https://github.com/koreader/koreader/compare/master...Commodore64user:KOReader_fork:shortcuts?expand=1

https://github.com/Commodore64user/KOReader_fork/blob/fe0d49a52a5d175b5812af025ac187db684d0ada/plugins/hotkeyshortcuts.koplugin/main.lua#L27-L29
is a table/associative array (key => value).
Tables can also be a plain array (1,2,3,4 => values)
(Lua tables can be both, have integer indexes, and string keys, but it's not a good idea to mix them when not needed for some reasons.)
table.insert() only makes sense with plain array, to append values.

https://github.com/Commodore64user/KOReader_fork/blob/fe0d49a52a5d175b5812af025ac187db684d0ada/plugins/hotkeyshortcuts.koplugin/main.lua#L42-L45
is wrong: you are inserting at index 1 another associative array.

You probably want to use:

https://github.com/Commodore64user/KOReader_fork/blob/fe0d49a52a5d175b5812af025ac187db684d0ada/plugins/hotkeyshortcuts.koplugin/main.lua#L92-L95
I think here, you are just on each line overwriting the thing you set on previous line.
May be #9059 (comment) can help.

Thank you @poire-z, i'll have a look at merging the arrays later. Regarding the last bit of your comment though, yes i might be but that is not the real issue atm (they all just temporarily look the same, i know how to write them ;) ) the real issue is that i am not sure how to write the function that plugs both the key_events with the array in hotkeyshortcuts_path

Btw is the if self.ui ~= nil then correct? Is supposed to be used only whilst inside reader

but that is not the real issue atm

Looks like it was what you were asking :/

the real issue is that i am not sure how to write the function that plugs both the key_events with the array in hotkeyshortcuts_path

I guess (like in gestures.koplugin that you copied it from) that function HotKeyShortcuts:onFlushSettings() takes care of that. You just update self.settings.data (a datastructure of your choice) and this is called when leaving reader/fm and stuff is written to the file.

Btw is the if self.ui ~= nil then correct? Is supposed to be used only whilst inside reader

Probably not, all plugins, even in FM, gets a self.ui = reader or filemanager.
Not sure how other modules check that, may be if self.ui and self.ui.document.
self.is_docless might be just be doing that.

Looks like it was what you were asking :/

oops, sorry i was outside, so couldn’t read it properly then.

I guess (like in gestures.koplugin that you copied it from) that function HotKeyShortcuts:onFlushSettings() takes care of that. You just update self.settings.data (a datastructure of your choice) and this is called when leaving reader/fm and stuff is written to the file.

i am still not sure about the whole thing though, could you please provide an example relative to this particular case?

I'm still not sure about what you're asking. Anyway, the existing example is gestures.koplugin: follow what its self.settings.data is and how it gets updated when the user change things - I haven't followed, so don't ask me. I'm just telling you that the saving/writting is auto taken care of by this HotKeyShortcuts:onFlushSettings() (which is called by other parts of the code, don't worry about that).

If you put a plugin in our plugins/ alongside all the others, as long as we don't ship a plugin with the same dirname, it will persist. And anything menu it adds will be put in the plugin submenu, I think (or there is a hint/order = to tells a menu item to be put in another menu.

but wouldn't I also need to add it to reader_menu_order.lua and filemanager_menu_order.lua and technically speaking it also needs to add

if self.ui.hotkeyshortcuts then -- search and update the profile action in assigned keyboard shortcuts
   self.ui.hotkeyshortcuts:updateProfiles(action_old_name, action_new_name)
end

in the profiles koplugin

but wouldn't I also need to add it to reader_menu_order.lua and filemanager_menu_order.lua

Plugins can use a sorting_hint = ("more_tools") to tell in which menu/submenu they'd like their item to be put.

technically speaking it also needs to add in the profiles koplugin

You can user-patch plugins I think (may depend on the amount of tweak you need), I added something to make that easier, see #11838 (comment).

Plugins can use a sorting_hint = ("more_tools") to tell in which menu/submenu they'd like their item to be put.

I see, sorry I didn't understand it before.

regarding the user patch for the registerKeyEvents, is that a number 0 or 1? and the user-patch plugin, I am not really sure I understand what to do. I just need to add those three lines seen here #12372 (comment) to

regarding the user patch for the registerKeyEvents, is that a number 0 or 1?

You mean the number at the start of the filename ? 2-, like for most user patches.

and the user-patch plugin, I am not really sure I understand what to do. I just need to add those three lines seen here

Untested:

local userpatch = require("userpatch")
userpatch.registerPatchPluginFunc("profiles", function(plugin)
    local orig_updateProfiles = plugin.updateProfiles
    plugin.updateProfiles = function(self, action_old_name, action_new_name)
        orig_updateProfiles(self, action_old_name, action_new_name)
        if self.ui.gestures then -- search and update the profile action in assigned gestures
            self.ui.gestures:updateProfiles(action_old_name, action_new_name)
        end
    end
end)

You mean the number at the start of the filename ?

yes that was it. I'll try the other patch. Thank you!!!!

so I am running the plugin, everything seems fine except for one little thing. Every time I open the menu, a new pair of the settings introduced by the plugin are added to the menu, but I don't know why

so that is the third time, opening it, and as you can see, three sets of options. https://github.com/koreader/koreader/compare/master...Commodore64user:KOReader_fork:hotkeyshortcuts?expand=1

Dunno either.
Does it happen with and/or without the sorting_hint ?
Does it happen with and/or without the user patch plugin stuff ?

Does it happen with and/or without the user patch plugin stuff ?

I am only building it now, so not this.

Does it happen with and/or without the sorting_hint ?

without it, it does that weird thing where it puts the settings in the first icon (page and bookmark) as NEW: Use press... and NEW: Shortcuts since I am no longer telling it where to go, but it doesn't seem to multiply them as you revisit.

without it, it does that weird thing where it puts the settings in the first icon (page and bookmark) as NEW: Use press... and NEW: Shortcuts since I am no longer telling it where to go

That's by design and normal.

but it doesn't seem to multiply them as you revisit.

So, may be a bug with sorting_hint, @Frenzie ?

note about replication, open in FM first, open a book and then open the menu in reader (setting will be duplicated), close reader and open menu in FM (settings triplicated, as in screenshot).

If you only do it, in either FM or reader, subsequent attempts do not duplicate settings.

So, may be a bug with sorting_hint

I don't know what that means. Not multiplying sounds like a good thing though.

I tried replicating the behaviour you describe by hacking the autoturn.koplugin, but couldn't get its menu item duplicated :/

I don't think this could be the culprit, but sorting_hint = ("physical_buttons_setup") doesn't need any parens.
Also try with adding only one of your two menu items (in case multiple identical sorting_hints causes the issue).

I don't think this could be the culprit, but sorting_hint = ("physical_buttons_setup") doesn't need any parens. Also try with adding only one of your two menu items (in case multiple identical sorting_hints causes the issue).

not it either,

I tried replicating the behaviour you describe by hacking the autoturn.koplugin, but couldn't get its menu item duplicated :/

why don't you try the shortcuts plugin then? ;) just pushed the latest version I have available.

Did.
It doesn't happen if you use sorting_hints = "navigation".
So, I guess it is because our code uses self.menu_items.physical_buttons_setup = require("ui/elements/physical_buttons"), and it is always the cached require'd object that gets re-used and each time got re-added your items.
We probably didn't need to think about that case, before you came in (these were happy times :))

so essentially, what you are saying is, this is a: "is not you, it's me" kind of situation ;)

No, it is a "it's you, and it's @Frenzie" kind of situation :)
May be something like this could be added (seems to solve duplication, but not familiar with the whole menusorter stuff, and how this additional loop adds to the already complex processing)?

--- a/frontend/ui/menusorter.lua
+++ b/frontend/ui/menusorter.lua
@@ -179,6 +179,12 @@ function MenuSorter:sort(item_table, order)
         if sorting_hint then
             local sorting_hint_menu = self:findById(menu_table["KOMenu:menu_buttons"], sorting_hint)
             sorting_hint_menu = sorting_hint_menu.sub_item_table or sorting_hint_menu
+            for i=1, #sorting_hint_menu do
+                if sorting_hint_menu[i].id == v.id then
+                    table.remove(sorting_hint_menu, i)
+                    break
+                end
+            end
             table.insert(sorting_hint_menu, v)
         else
             table.insert(menu_table["KOMenu:menu_buttons"][1], v)

Or, better yet, just use dofile ;).

Or, better yet, just use dofile ;).

Mmm, what does that mean? 🤔

I have been running the plugin on both k3 and k4 for the last few days, seems to work absolutely fine, so I ask. Are you interested in re-opening that PR? I can't make the changes that were quickly piled up there. And, would certainly need to hack the keyEvent functions like in #12372 (comment), thoughts?

Is that a No?

That was addressed to NiLuJe?

Not sure what we're talking about, exactly ^^.

It was a question for all of you, in short:

There is shortcuts plugin, it works, is not perfect. I personally can't make it better at this moment in time but would like to make it available to all... it would require some concessions, more precisely, making ugly adjustments to the current key_events functions affected.

I'm pretty firmly in the "hell no" camp, then ;).

This thing is already fairly gnarly, nobody has touched it in years, we really really don't want to make it worse.

This thing is already fairly gnarly, nobody has touched it in years

What is?

btw here it is master...Commodore64user:KOReader_fork:hotkeyshortcuts if you want to have a look.

I meant the whole Key framework, pretty much from top to bottom ;).

I am with you, that’s why i am saying I would not want to change anything else for it (plugin). It is what it is. The only thing would be to hack the functions with current events like in #12372 (comment)

unless someone else wanted to provide a function that designates priorities ;)