filebrowser context

[kr-g]

the code base in plugins/files.py was refactored and some of the context menu related code has been moved to own "handler" classes. adding new handlers is simple and will not blow up the code base with additional spaghetti code in the main functions "add_first_menu_items" or "add_middle_menu_items"

the venv activation also moved to an own handler.

there are handlers for executing:

• shell scripts (.sh on linux and .bat on windows)
• requirements.txt (install and upgrade)
• python scripts
• python modules (when __main__.py is insíde a folder python is started with "-m" on that folder)

for execution in shell view the handler uses "magic" command (with "!", and after changing the folder with "%cd")

RFC

[aivarannamaa]

I agree that the filebrowser commands are currently a mess, but if I were to refactor it, I would go for the possibility to add commands via plug-ins (either built-in or 3rd party), just like the commands in the main menu (see thonny.workbench.Workbench.add_command).

I wouldn't make it too similar to the main menu, though. With the main menu I made the mistake of trying to update the menu widget right after each add_command. It would be easier to collect all items into a data structure and re-construct the menu each time just before showing it (like the filebrowser context menu).

What I do like in Workbench.add_command, are the group and position_in_group arguments, which allow flexible ordering and automatic separators between the items. In the filebrowser, the groups mechanism could obsolete the concepts of first, middle and last menu items.

At the moment I imagine adding method Workbench.add_file_command, which would take following arguments:

• command_label: str
• handler -- function taking List of pathInfo-s (kinds and paths of selected items), scope ("local" or "remote") and context ("button" or "item")
• visibility_tester -- function with the same arguments as handler
• enablement_tester -- function with the same arguments as handler
• group
• position_in_group

The method would store this info in a data structure, which can be queried by the file browser each time its menu is about to appear.

[aivarannamaa]

Regarding the new commands -- I like the command for installing requirements, but why do you need a command to execute a Python script from the file browser instead of running it via the editor?

[kr-g]

It would be easier to collect all items into a data structure and re-construct the menu each time just before showing it (like the filebrowser context menu).

so you mean that when the view elements changes (or get focused) that the visible/ focused (in addition with the other involved) elements do sort of registration (or get just flagged). and the top container (like workbench or filebrowser) collect and construct from those elements. also the generic event model (like save, update, load bindings) would be sort of listener model (or subscriptions) what works in cooperation where just registered (visible/activated) elements get notified. so that also in principle one menu entry could appear in the main menu as well as in the context menu just by changing the focus or enabling a view or pickable element.

one remark: but why then having the visibility_tester in addition? (when it's already dynamically build) or is this the main function what is called when focus changes ?

another remark: how about a command_nameproperty also for those menu items? so that a command-key could be assigned later also for those menu entries.

[kr-g]

Regarding the new commands -- I like the command for installing requirements, but why do you need a command to execute a Python script from the file browser instead of running it via the editor?

let me change this question to: why having "magic-commands" in shell view at all ?

because this feature just simplifies working with that.

of course opening a python script and running from the editor is an option. but think about additional "helper" scripts (for organizing the project itself). in the end the user has less open windows then, or don't need to switch to shell to run such helping scripts.

one remark: looking again on the current implementation i think that i have done it a bit too "tightly" coupled in the class hierarchy. but on the other hand: this could be changed also later.

[aivarannamaa]

I'll try to make the first attempt of the refactoring today, in a different branch and I'll invite you to review it.

[kr-g]

I'll try to make the first attempt of the refactoring today, in a different branch and I'll invite you to review it.

ok, fine. i will also stop working for now adding new handlers. the last 2 handlers (black and flake8) are probably already too much for the standard (since this could be also provided by an extra plugin)

[aivarannamaa]

I'm considering moving from Tkinter to wxPython. Therefore I'm postponing this topic for now.