There is quite a bit of "different" looking code between the two methods so I wasn't sure if there were other intended differences. I know create_menu_action() is a new addition as part of these changes - I just want to figure out when I should be using which?Īhhh - () is the magic trick, thanks. Which has a differing behaviour - if no shortcut is specified they will still appear in your Keyboard dialog. However as you mention above the Calibre plugins are calling create_menu_action(). Which means that they will only appear in the Preferences->Keyboard dialog if at the time I call create_action I am setting a shortcut value. This could well be intentional but it would be good to hear your intentions with these?Ĭurrently my plugins all call create_action(). I'm seeing different behaviour from the "InterfaceAction.create_action" versus "create_menu_action" functions. To genuinely set a shortcut to none, you choose "Custom" and click Done - but visually you cannot see the difference of "None" until you close and come back into the dialog?Īnyhow, back to the main challenge - plugin shortcuts. When in actual fact it is really still the default shortcut.
Firstly I think there is a minor bug - if you go to Preferences -> Keyboard, click on an existing shortcut, don't change anything (so radio button of default is set) and click Done, then it shows "Shortcuts: None". Ok, so I'm just starting to look into this again. Got any ideas as to what this means for plugins with keyboard shortcuts? And your screen would not be able to allow configuring shortcuts for plugins for functions not yet assigned a shortcut, since it doesn't know about them. So I can see a conflict happening if a user were to attempt to change a shortcut in your new dialog (as my plugin would try to register at startup its "known" shortcut that it has persisted). Search the Internet or Open With, where a user can assign any number of shortcuts to "rows" of data. In other cases they are truly dynamic - e.g. next/previous result for find duplicates.
In some cases these are relatively simply defined being static - e.g. For instance since this functionality did not exist previously, all my plugins have had to have their own ability to both define and persist a shortcut. However I forsee a number of potential issues/conflicts. I am imagining how this works is that because my plugins are registering keyboard shortcuts, you are then able through Qt to do some kind of "currently hooked in shortcuts" to display in the new dialog. You seem to have some kind of discovery going on, so I see some of the shortcuts for "Find Duplicates" and "Goodreads", "Open with" etc appearing in the new preferences screen. My question concerns what does it mean from a plugin perspective? I see you have a shiny new preference for editing keyboard shortcuts.
0 kommentar(er)
