Provide Windows Terminal Fragment Extension

[Okeanos]

• I was not able to find an open or closed issue matching what I'm proposing

Details

With the latest stable release of Microsoft Terminal a new feature was rolled out called Profile fragments. This can be used by third party applications to let Terminal know they exist.

It would very cool if Git for Windows could (optionally) supply a fragment describing itself to Terminal so the Git Bash can be launched inside Terminal without additional, manual setup.

Based on prior experience with setting up Git Bash inside Terminal (and cross checking with Stack Overflow) I think a minimal fragment might look like this:

{
  "profiles": [
    {
      "name": "Bash",
      "commandline": "%PROGRAMFILES%/git/usr/bin/bash.exe -i -l",
      "icon": "%PROGRAMFILES%/Git/mingw64/share/git/git-for-windows.ico",
      "startingDirectory": "%USERPROFILE%",
    }
  ]
}

I assume this is contingent on the installer checking availability of the paths mentioned in the fragment documentation before asking the user whether or not to register a default profile.

[dscho]

@Okeanos since you seem to be quite familiar with this topic (and I am not at all familiar with it), would you mind opening a PR to add support to the installer? Here is how to get started with this project:

1. install Git for Windows' SDK,
2. sdk cd installer,
3. edit install.iss
4. build a new installer via sdk build installer
5. verify that that installer works as expected?
6. open a PR?

[Okeanos]

Well … I can look into it – no promises on anything that actually works, though.

[rimrul]

"name": "Bash",

That should probably be "Git Bash" so people can differentiate it from things like WSL bash, cygwin bash, ...

I assume this is contingent on the installer checking availability of the paths mentioned in the fragment documentation before asking the user whether or not to register a default profile.

According to microsoft, we should just create the directory if the user wants us to create a fragment and the directory doesn't exist.

if the Windows Terminal\Fragments directory does not exist, the installer should create it.

[Okeanos]

I had a very quick look at the install.iss file and must say that I am somewhat overwhelmed by it 😅 – I may still poke around in it but right now I am not sure I can contribute in a reasonable fashion.

[dscho]

I guess you could add the fragment as a file into the installer/ subdirectory and add it to the [Files] section. That would most likely be the quickest and most painless method to add support for this fragment.

[rimrul]

I had a very quick look at the install.iss file and must say that I am somewhat overwhelmed by it

I can see why. Let's give it a quick breakdown.

The file is divided into the following sections:

• An unnamed section at the top
  That section does a little preparation work for the following sections, but you can safely ignore it for now.
• The [Setup] section
  Some general config on how to build the installer, what compression to use, etc.
• The [Types] section
  This is just used so innosetup won't offer users a choice between compact install, full install and custom install.
• The [Components] section
  This section defines the components for the "select what to install" page of the installer. The Name: parameter here is an internal name, to reference that component throughout the installer. The Description: parameter is a description that the end user will see. You'll probably want to add an entry here with the MinVersion parameter set to 10.0.18362.
• The [Run] section
  This section specifies what the installer offers to start after the installation is complete. You won't need this for now.
• The [Files] section
  This section specifies the files to install. You might notice it's almost empty. That's because of the #include "file-list.iss" at the top of the section. Most files get included into this section via that autogenerated list. This specific file probably wont, because we'll need some non-autogenerated parameters here.
  One of them ist the Components: parameter to tell the installer to only install the fragment if the user corresponding component is selected for installation, the other one is the Check: parameter. I'll get back to the value for that one.
  You'll probably want to add two entries for the fragment file here, one for per-user installs, one for per-machine installs.
• The [Dirs] section
  This section defines directories for the installer to create. You'll probably want to add two entries here as well, since the installer should create the directories if they don't exist. They'll also need the same Components: and Check: parameters as the entries in [Files]
• The [Icons] section
  This section defines shortcuts, start menu and others. You can ignore this section.
• The [Messages] section
  This section is used to override some strings the installer displays. You won't need this section either.
• The [Registry] section
  The name is fairly self explanatory, this section specifies registry keys tha should be set in certain ways. You won't need to write to the registry, but remember those Check: parameters I mentioned above? You can see them in action here. There's a lot of entries here that exist twice and only differ in the value of their Root: parameter and the Check: parameter. There are entries with Check: IsAdminLoggedOn; for per-machine installs and others with Check: not IsAdminLoggedOn; for per-user installs.
• The [UninstallDelete] section
  This section defines what to delete on uninstall. You might want to delete the files on uninstall, too. The directories, probably not.
• The [Code] section
  This is where the magic happens. All the custom functionallity. Radio buttons, testing custom editors, the "Only show new options" checkbox, ... But due to this section being Pascal code and about 92% of all lines, it's probably also the section that's most overwhelming. But you probably won't need to touch this section for this feature.

[dscho]

@rimrul that is an incredibly good high-level overview of the installer definition. Maybe we could integrate this into the installer/ directory, say, as README.md?

[rimrul]

That's a good idea, but it's a little specific to this issue in some spots and leaves out some details like the *.inc.iss files, but then again those haven't been changed in years, so maybe they're more of an advanced topic. I'll try to edit this into a more generalized version for a README.md.

[Okeanos]

@dscho , @rimrul you guys are awesome! I'll definitely have another look at the installer file in the near future :)

[dscho]

As the PR was just merged, I'll close this here ticket.