Feature: Custom repository actions & keyboard shortcuts

[patriksvensson]

It would be super lovely if there keyboard shortcuts for the "open" actions, so I could open a project in Windows Terminal or Windows Explorer without using the mouse when a repository is selected. Perhaps something as simple as 1, 2, 3?

Happy to submit a PR for this if it's something that you see in the vision for your project.

[awaescher]

I wanted to refactor this for a while now tbh. At the moment, there are two action providers which return the available menu items to click in dependency of the user selection. One for Windows one for macOS.

Currently, these actions are not configurable. The providers decide what's possible (depending on the installed tools and the selection) and decide the order of the actions. The first action is also available per [Return] key, the secondary action can be triggered with [Ctrl]+[Return].

There are already GitHub issues to make these actions configurable (#105 & #108). So I really want this to be better for my users but at the same time I want to keep intelligent defaults to keep RepoZ as low-conf as possible. My credo is that even though this is a developer tool I don't want it to look like one 😊

I will look at this once I find some time. If you are willing to step in ... well ... I'd be very grateful for each task you'd grab.

[patriksvensson]

@awaescher Absolutely, I understand completely. I'll wait a bit so you'll have some time figuring out how you want it to work. Once you know and if you don't have any spare time, ping me and I'll happily donate some time to implement it 😄

[awaescher]

Oh, I already have an idea. But in my eyes it is not obligatory - I am open to any suggestion. Since this is a developer tool, I would actually have thought of a configuration file that can be opened easily via RepoZ. As I said, I want to keep the UI as simple as possible, but if someone wants to make adjustments, he should have as many options as possible.

What do you think about the idea that RepoZ ships with such a file by default and lets the developer make the necessary adjustments. The problem: If you can change all kinds of things yourself, it's a bit more difficult to validate and parse (e.g. the keyboard shortcuts) and keep supported in future versions.

# Define your context actions for RepoZ.
# To enable path probing, you can define multiple paths for the application executable to run.
# Try to avoid absolute paths if possible by using environment variables like %PROGRAMFILES% or %APPDATA%, for example.
# Use the placeholder {RepositoryPath} to build command line arguments. RepoZ will replace it with the given repository path.

{
  "name": "Open in Visual Studio Code",
  "paths":
  [
    "%LocalAppData%/Microsoft VS Code/code.exe", 
    "%ProgramW6432%/Microsoft VS Code/code.exe"
  ],
  "arguments": "{RepositoryPath}",  
  "keys": "Ctrl+1",
  "sort": 1,
  "visible": "true"
},
{
  "name": "Open in Windows Terminal",
  "paths":
  [
    "%LocalAppData%\Microsoft\WindowsApps\wt.exe"
  ],
  "arguments": "-d {RepositoryPath}",  
  "keys": "Ctrl+2",
  "sort": 2,
  "visible": "true"
},
{
  "name": "Open in PowerShell",
  "paths":
  [
    "%WINDIR%\System32\WindowsPowerShell\v1.0\powershell.exe"
  ],
  "arguments": "-executionpolicy bypass -noexit -command 'Set-Location '{RepositoryPath}''",  
  "keys": "Ctrl+P",
  "sort": 3,
  "visible": "false"
}

[patriksvensson]

@awaescher I think that's a great idea. Perhaps go the Windows Terminal way and specify a schema for the settings file as well. I would say, validate the best you can and if there's an error then show it and fall back to the default settings.

I would probably remove the sort property as well and just use the order that things are specified in the settings file.

Would be nice to have a Settings... menu that opens the configuration file in the default editor for JSON files.

(A lot of inspiration from Windows Terminal here, but it's worked well for them, and once you've stabilized the schema for the settings, you could even add a UI for it)

[awaescher]

Good point with the sort order, developer blindness 😄 I was inspired by WT as well as I thought about that file. VS Code was very successful with this approach as well (now they built an UI around it).

There's already a service to read/write local settings which puts files to %AppData%\Roaming\RepoZ. I think this would be a good place for the new context action settings file.

Would be nice to have a Settings... menu that opens the configuration file in the default editor for JSON files.

That's what I thought as well. We could place it either in the "main" menu like in the first image or in the context menu itself like in the second one.

The main menu may fit better for this menu item as it's a global thing to define these actions (thinking of "Settings ...") but the more I think about it, the more I like the second one because there you don't need to define the context "Repository Actions" (I even don't like that term very much 😊) because you're already in the correct context.

What do you think?

[henriksen]

I don't know about the settings file. I my mind, having it like that limits the context menu to simple "open this directory in this program" things. Of course, I might be biased, but I still think the context menu has the potential to be more powerful than that.

One idea might be to add internal commands to the context menu in addition to external apps? These commands could be picked up by code in the app to do more complex things.

[patriksvensson]

@henriksen The sole reason for this is to get a settings file for hardcoded stuff. Adding more types of commands or expanding the schema with new functionality can be done incrementally later on when the need arise and we know how we (primarily @awaescher) want stuff to work.

[awaescher]

I thought of this issue in here as I merged the PR from @henriksen as well. Just to make sure we're talking about the same ... I'd thought that the config file to define the "Open in ..." actions won't replace the whole context menu. We should keep the newly merged "Open Solution" area intact. As well as the basic git commands and the possibility to ignore repositories.

The stuff we were talking in here is indeed "Open the directory of a given repository with ...". In the sample file I added the placeholder for the {RepositoryPath}. But we could add more of these repository properties if they are useful. I did just not think of it yet.

Another thing I thought after I merged the PR: For us Windows Devs, *.sln is the most used file in our repositories. But we could also make this part dynamic by adding the possibilities to define the extensions one wants to be included into the menu.

This could be

{
  "name": "Open Visual Studio solutions",
  "extensions":  [  "*.sln"  ]
},
{
  "name": "Open Xcode projects",
  "extensions":  [  "*.xcodeproj"  ]
}

... to have a menu with submenus for the matching files:

We're going away from the initial simplicity, that's why I struggle. However, I think the features could be very useful if the defaults are chosen wisely, like 2-3 default "Open in ..." actions and the "Open Visual Studio solutions" sub menu.

[henriksen]

As long as it's not a "throw the baby out with the bathwater" kinda thing 😊

One good thing about having a settings file is that each user can reduce their own complexity by removing things they don't need. For instance, I'll never use the Command Prompt, Git Bash or Powershell options so I can just disable those in the settings. Another developer might use VS Code exclusively and prefer to drop the Visual Studio entry. Or someone might want to rename "Visual Studio" to "Rider".

It does increase the flexibility for those things that can be generalized!

[henriksen]

The "Open Whatever solutions/projects" concept is pretty generalizable and can benefit from an open customization. For instance, what file pattern to look for, which folders to in (in addition to root), how to start them (just open the file or a custom command line?), etc. Personally, I don't think it complicates things significantly. The UI stays pretty much the same (or less), some things get a submenu, but with keyboard shortcuts that's pretty fast to navigate.

[awaescher]

That's what I thought. I would like to remove some of the current actions as well. As you said, Windows Command Prompt & Git Bash are two candidates I'd add to the default config with visible=false so the user can add it easily if he or she wants.

[henriksen]

If I wanted to start on a config file and the structure needed to read the settings, would extending FileAppSettingsService and AppSettings be the place to do it, or would you prefer a separate structure? (or are you already working on this?)

[awaescher]

Hm, at the moment I'd say I'd go for an additional file. If the devs change that file manually and they mess up it any way, we have no problems with parsing the app settings.

No, I did not start yet.

[JKrag]

May I suggest a "smaller fix" that would go a long way as a temporary help for the originally posted problem?. Maybe just adding a simple hotkey that opens the right-click menu, and thus allows for the already existing keyboard navigation (up/down) would at least allow us to not have to reach for the mouse for that one click? Just opening the context menu instead of having fixed "1, 2, 3, ..." shortcuts would at least alleviate the issue of the dynamic nature of the action providers.

It would have to be something that isn't "valid input" for the typing field, (so unfortunately I can't suggest to use the same . as e.g. my favorite GitUp client for mac), but maybe something as simple as Right arrow could work? Assuming that our cursor is at the end of the typing field anyway, then right arrow might just work? While typing this, I just realized, that if/when I happen to be stuck on a Windows machine with a full "windows style" external keyboard, then it actually has a hardware "menu" button that works :-) But it would be really nice to have a keyboard shortcut that works on keyboards without this dedicated menu key, and on mac as well.

[awaescher]

it actually has a hardware "menu" button that works :-)

That's what I use all the time 😃. There's not other shortcut I remember for context menus ... but there's F4 (on Windows) to open drop down controls like ComboBoxes ... which could be a bit like a sub menu. I'm not sure if I'd like that.

[henriksen]

There's not other shortcut I remember for context menus

Shift-F10 opens context menus. Same keycode as the "Menu" button.

[awaescher]

Just a note to myself that Cmder could be a good addition for the "Open with ..."-gallery.

[awaescher]

I started to implement this feature a few days ago. Here's the task list I'm working with.

• [x] Define json files → see RepoZ-RepositoryActions
• [x] Deploy default configuration
• [x] Build the context menu from json file
• [x] Show the customization possibilities in the UI
• [x] Handle & show json parser errors
• [ ] Implement keyboard shortcuts
• [x] Translatable actions

(Please note that I only work on it from time to time, so progress can be slow)

[awaescher]

Pull-Request #153 has just been merged - however keyboard shortcuts are not implemented yet. Sorry for the delay, I am pretty busy atm 😬

[sboulema]

Just build master to try out the new features and wow! Congrats on an awesome job, completely in love with the new editable actions.

Inspired me to do a quick tool to open a solution in Visual Studio: https://github.com/sboulema/VSLauncher

[ZodmanPerth]

I've just installed v5.5 from the Windows installer and am looking for the feature to define my own "Open in ..." app. The repo actions look to be exactly what I need but I see they aren't released as part of a build yet.

Do you have an estimate for when this feature will be placed into a release?