[Plugin ContextMenuPlugin] 773-Feature-is-there-any-way-to-Hide-or-Sort-context-menu-i…

[vssdeo]

Context Menu Plugin

Note: Plugin affects core / basic features so up for testing, suggestions and tweaks.

-It's ready for review and comments but since it may require tweaks and other changes so putting up the changes.

Ref: For Testing and Details #773

• Adds a context menu (right click)

• Gives an UI under Preferences->Plugins with capability to organize items

• Supported by PluginEventRegistry which helps to add plugin actions to menu

• apart from other plugins using this, for eg. this context_menu_plugin can

• register its menu functions while itself creating a menu and so can other plugins

• Supported by KeyBindUtil for action key / desc matching

• Cleans and identifies common dependencies which can be further worked on

• Gradual removal of menuitems to be done with checking logic and removal of if

• based conditions. All cases are being compiled in class Filter below which have to be removed

• Menu Names are taken from keybinding name

[mattrose]

This is a pretty massive change to the context menu, something which was relatively simple up to now. I've been very careful not to add too many items to the context menu, for fear of it getting too big. I still don't think it's too big, when compared to other context menus, so I'm not sure what to do with this. I don't know that it's necessary today, but it might become necessary in the future. Also, GTK4 drastically changes signal handling, which seems to be a big part of this, and a lot of it might have to be thrown out.

I'm definitely not closing this right now, but I will continue to play with it.

I'm not sure if it's easy to break up into smaller, more manage-able chunks, but you might look at that as well.

[vssdeo]

Hi @mattrose, first thanks for taking your time and looking into this. All wise suggestions & helpful as always.Yes, playing around with this enabled would be a good idea.

Even I was under the idea that how to approach, so the thought process was to be consistent in approach and open things for discussion. For a brief idea I have listed down changes below, that helps to understand the code changes.

• I thought that if the change is submitted as a block people would be able to test with a single pull request & discard from their branch.
• I have kept the plugin functionality separate.
• The only thing that overlaps is the interface where keybindings are merged, which helps to simplify the prev code in prefseditor.py, this was also put in here so the change is visible and shows its integration and the change in terminal.py where we detect non core actions.

The point about not expanding the context menu is also wise. I will think more on this or may be in the plugin addition of new elements can be restricted to those defined in context menu plugin and those who are hacker itchy enough can enable in if needed :-P

I will further check if something more can be decoupled.

Code-Change-Summary

config.py - only adds actions to config to make things consistent

terminal_popup_menu.py - only old code commented out, nothing added

terminal.py - minimal changes to detect the keypress / short-cut

plugin.py - minimal changes to prev code for consistency
- new section for the context menu event
- new section for gui interface

prefseditor.py - added actions as per config
- changes made to clean up actions as per plugin.py
- new section for gui interface

plugins/PluginContextMenu.glad - new separate glade file
plugins/context_menu.py - new separate plugin file