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.