Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow keyboard shortcuts to be customised #476

Open
14 tasks
derceg opened this issue Sep 6, 2024 · 3 comments
Open
14 tasks

Allow keyboard shortcuts to be customised #476

derceg opened this issue Sep 6, 2024 · 3 comments
Labels

Comments

@derceg
Copy link
Owner

derceg commented Sep 6, 2024

There are a few different ways this could be implemented:

  1. Allow a list of shortcut items to be updated, where each shortcut functions globally. This is essentially unworkable, since at least some shortcuts need to be scoped. For example, pressing backspace within a listview navigates up, but backspace needs to work normally elsewhere.
  2. Associate shortcuts with one or more scopes. This fixes the issue described in point 1 and is similar to the system in Visual Studio.
  3. Add a system more like the one in Visual Studio Code. There would be both custom command and when clauses. The big advantage here would be flexibility. For example, a shortcut could invoke a custom command only when a particular folder is opened in the current tab. The downside would be a potentially steeper learning curve. If implemented this way, the command and when clauses could be written in Lua and leverage the plugins API.

In any case, the implementation will require a number of changes:

  • Generate menu item shortcut text dynamically. At the moment, the text is fixed.
    • The text will also need to be updated whenever a shortcut is updated.
  • Handle scoped shortcuts in the same way global shortcuts are handled. At the moment, scoped shortcuts like backspace are handled by the control.
  • Allow custom commands to be invoked, likely via the plugins API, as described in [Feature Request] Add ability to associate a shortcut to a bookmark #292.
    • If the plugins API is used, the API needs to be documented first.
    • The API will likely need to be expanded - e.g. to add methods that allow the focused control and current tab to be retrieved.
  • Replace TranslateAccelerator. Using a custom method will make it easier to execute custom commands and check constraints.
  • Update the existing shortcut_keys functionality available to plugins.
  • Allow the user to update shortcuts dynamically.
    • As an initial implementation, it may be easier to allow only plugins to update shortcuts, since shortcuts wouldn't have to be saved and there wouldn't have to be any UI.
    • A UI will need to be added that lists existing shortcuts and allows them to be changed.
      • If going with implementation 3 above, it's likely that the UI will need documentation, to explain custom commands and when clauses.
    • Custom shortcuts will need to be saved. Either a list of all shortcuts should be saved, or a list of user-customized shortcuts. The advantage of just saving the user shortcuts is that user shortcuts and system shortcuts could be clearly differentiated, as they are in Visual Studio Code.
@derceg derceg added the feature label Sep 6, 2024
derceg added a commit that referenced this issue Sep 6, 2024
This is part of some broader work to make accelerators updatable. To do
that, the accelerator text on menu items will need to be dynamically
generated (rather than fixed in the .rc file). That then requires that
items that have multiple accelerators have the "default" accelerator
(the one shown on the menu entry) chosen in a deterministic way.

That isn't going to work with the .rc file, since entries there can be
rearranged incidentally, when adding or updating entries. Additionally,
I'm not sure that LoadAccelerators() makes any guarantees about the
order in which items appear in the loaded table anyway.

Fixed ordering is important, since without it, items that have multiple
accelerators could have different menu accelerator text generated in
different builds. For example, a search can be initiated using either
Ctrl+F or F3. Only one of those shortcuts should appear on the menu and
that choice should be explicit and deterministic.

By defining the accelerators in code, the "default" accelerator can be
set by the order in which accelerators are defined.

This is part of the work for issue #476.
derceg added a commit that referenced this issue Sep 6, 2024
This is part of the work for issue #476.
derceg added a commit that referenced this issue Sep 13, 2024
Previously, the strings were hardcoded into the .rc file. Dynamically
generating the strings is needed to allow accelerators to be updated.

This is part of the work for issue #476.
@AgentSam
Copy link

AgentSam commented Sep 30, 2024

Is the LUA plugin functionality still available though, while this is being worked on?

Just asking, because I have the following file/directory-layout for EPP (Version 1.5.0.2485, latest dev-build at the time of writing this):

C:\BIN\ExplorerPP\config.xml
C:\BIN\ExplorerPP\Explorer++.exe
C:\BIN\ExplorerPP\ExplorerPP with Plugins.lnk
C:\BIN\ExplorerPP\History.txt
C:\BIN\ExplorerPP\License.txt
C:\BIN\ExplorerPP\Readme.txt
C:\BIN\ExplorerPP\plugins\AcceleratorMappings.h
C:\BIN\ExplorerPP\plugins\Readme.txt
C:\BIN\ExplorerPP\plugins\update_accelerators\empty.lua
C:\BIN\ExplorerPP\plugins\update_accelerators\plugin.json
C:\BIN\ExplorerPP\plugins\update_theme_colors\plugin.json
C:\BIN\ExplorerPP\plugins\update_theme_colors\update_theme_colors.lua

So, as you can see I have the plugins folder inside the main installation directory, and inside that folder are the individual plugin folders, for both update_accelerators and update_theme_colors.

The shortcut ExplorerPP with Plugins.lnk executes C:\BIN\ExplorerPP\Explorer++.exe --enable-plugins.

The shortcut ExplorerPP with Plugins.lnk executes C:\BIN\ExplorerPP\Explorer++.exe -enable_plugins.

EDIT / UPDATE: According to: Load plugins on application startup the command-line switch is actually called -enable_plugins, and not --enable-plugins as stated in the Readme.txt

For testing, the file C:\BIN\ExplorerPP\plugins\update_accelerators\plugin.json contains:

{
  "name": "Update accelerators",
  "description": "Remaps the rename command accelerator and adds a new accelerator to switch the view mode to icons.",
  "file": "empty.lua",
  "version": "1.0",
  "std_libs_required": [],
  "author": "David Erceg",
  "shortcut_keys": [
    {
      "command": "auto_arrange",
      "keys": [
        "Alt+Shift+R"
      ]
    },
    {
      "command": "auto_arrange",
      "keys": [
        "Ctrl+NumpadAdd"
      ]
    },
    {
      "command": "view_mode_details",
      "keys": [
        "Alt+Shift+D"
      ]
    }
  ]
}

However, EPP just doesn't pick up any of this, and none of those accelerators defined in the plugin.json are doing anything. I've tried to reference C:\BIN\ExplorerPP\plugins\AcceleratorMappings.h to the best of my ability, but, sadly, no go with the keyboard shortcuts.

So, either I'm doing something wrong, or this functionality is not currently available in the latest dev builds.

Any help and additional tips on how to enable the plugin functionality for keyboard accelerators (keyboard shortcuts), would be greatly appreciated.

Cheers, Sam

derceg added a commit that referenced this issue Oct 1, 2024
derceg added a commit that referenced this issue Oct 1, 2024
As noted in #476, the command line option to enable plugins was out of
date. The option was changed in
2e2fca0. This commit updates the readme
so that it contains the correct command.
@derceg
Copy link
Owner Author

derceg commented Oct 1, 2024

Sorry, the command line in Plugins/Readme.txt was out of date. The relevant option was changed a year ago to make enabling non-default features more consistent. It should be:

explorer++.exe --enable-features Plugins

I've updated Plugins/Readme.txt so that it contains the correct command.

Is the LUA plugin functionality still available though, while this is being worked on?

I haven't done much work on the plugins system for a while, but it should still work.

Edit:

Just to add, you can also view a full list of command line options by running explorer++.exe --help in a terminal.

@AgentSam
Copy link

AgentSam commented Oct 1, 2024

Thanks! All of the above was super helpful!

I will take further plugin related discussion to the appropriate location, presumably either to the official "Explorer++" forums or to the Github sections indended for discussion or issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants