PrimaryAction/SecondaryAction system is a pain point. Within the code base this is separate from the shortcut system, but that is not something users need to think about - in fact, they should not even see or hear the terms Primary Action / Secondary Action, because they don't mean anything. If we write the configuration dialog again, it should provide options like, "What do you want control modifier to do when you are using the line tool?"
This is a big clunky job, and unfortunately the payoff is smaller than fixing other parts of the shortcut system. It gets my engineering blood boiling that the internals are so messy mess, but in the end they get the job done for the most part. This whole task is low priority, depending on how much the rest of the shortcut system can be separated from the tool system, perhaps this does not need to be considered as blocking T946.
The two steps here are:
- Refactor the internals
- Get rid of KoToolBase, no need to play charades any longer.
- Never pass QEvents to tools, it's useless.
- Get rid of the incorrect PrimaryAction/SecondaryAction "abstraction." Instead, design a system that allows each tool to be configured individually.
- Add a new configuration dialog for the refactored code.
- Create a mock-up.
- Make it happen.
- Merge the XMLGUI shortcut handling code with the KisShortcutsConfiguration code.
- This means basically merging all of the meaty configuration saving/loading code from KActionCollection, KStandardAction, etc. into Krita's code.
- Merge all of the shortcut options into a single file.