wsl-windows-toolbar 0.5.0

Adds linux GUI application menu to a windows toolbar

WSL Windows Toolbar Launcher

This script will create a Windows toolbar launcher for an underlying WSL install which can be used to fire up linux native applications directly from Windows via the standard Windows toolbar, like this:

It's particularly cool because WSL 2 is coming which is unlocking unprecedented performance and compatibility improvements, so this will literally bring the full suite of Linux GUI applications directly to Windows UI.

Prerequisites

The script expects to be run within the WSL execution environment with:

• A complete WSL install ready with bash and python3 installed.
• An X11 Server running on your windows host (e.g. X410, Xming etc). This server must be reachable from your WSL env (test with something like wsl.exe -- source ~/.bashrc ; xterm"). If this fails, check your DISPLAY variable (more details in troubleshooting).
• A desktop environment which has a freedesktop menu installed (e.g. gnome / xfce).

And optionally (but recommended):

• An installation of cairosvg if works on your distro (pip install cairosvg)
• Imagemagick installed (sudo apt install imagemagick / dnf install imagemagick etc)

Installing and Running

To install:

python3 -m pip install git+https://github.com/cascadium/wsl-windows-toolbar-launcher#egg=wsl-windows-toolbar

To run:

wsl-windows-toolbar

After installation, right click on your toolbar, go to Toolbars -> New toolbar... and select %USERPROFILE%\.config\wsl-windows-toolbar-launcher\menus\WSL as the target folder (unless you selected an alternative directory).

Note there are many options available with --help if you'd prefer to use alternative locations.

Updating

If new software has been installed in the WSL environment, simply run the script again from the WSL environment to pick the new GUIs up.

Notable changes:

• Change in 0.3: Command is now wsl-windows-toolbar without the trailing .py.

Advanced Usage / Options

$ python wsl-windows-toolbar.py  --help
Usage: wsl-windows-toolbar.py [OPTIONS]

Options:
  -i, --install-directory PATH   Install the launcher targets to this
                                 directory (<target> will be suffixed to this
                                 location)
  -m, --metadata-directory PATH  Install the launcher targets to this
                                 directory (<target> will be suffixed to this
                                 location)
  -d, --distribution TEXT        WSL Distro to generate shortcuts for (will
                                 use default distro if this parameter is not
                                 provided)
  -u, --user TEXT                WSL Distro's user to launch programs as (will
                                 use default user if this parameter is not
                                 provided)
  -y, --confirm-yes              Assume the answer to all confirmation prompts
                                 is 'yes'
  -f, --menu-file FILENAME       The *.menu menu file to parse
  -w, --wsl-executable TEXT      Path to the WSL executable relative to the
                                 windows installation
  -n, --target-name TEXT         Name to give to the created installation
                                 (will be displayed in toolbar menu)
  --help                         Show this message and exit.

Launcher Templates

The loader process involves using wscript to launch a batch file (to keep the shorcut command length down). There is a jinja template which defines this script which defaults to wsl-windows-toolbar-template.j2 and accepts the following possible variables passed through from the script:

• distribution: The distribution selected in the script
• user: The user selected in the script
• command: The individual command for each launcher entry in WSL environment (e.g. xterm)
• wsl: The wsl executable discovered
• rcfile: The rc file (e.g. .bashrc) to source prior to launch selected in the script

Troubleshooting

No applications launching

If no applications are launching at all, it's most likely an issue with either:

• DISPLAY not being set correctly
• DISPLAY being set fine, but its destination is not accessible from the WSL environment
• The X11 server isn't set up to allow access from external hosts (how to configure this will depend on your X11 server so please refer to their documentation)

Note that for this section, you can check which version of WSL you're using with:

wsl.exe -l --verbose

Check WSL1 $DISPLAY variable

If you're running WSL1, the DISPLAY variable for WSL1 should simply be localhost:0.0 if this is the default distribution.

Check WSL2 $DISPLAY variable

Unfortunately for WSL2, it's a little more complicated for now, though I think they're planning on fixing this. You'll need something like this to extract the correct host:

export DISPLAY=$(grep -m 1 nameserver /etc/resolv.conf | awk '{print $2}'):0.0

Firewall Rules

Then you need to worry about the firewall. WSL comes up as a public network, but I wouldn't recommend allowing all public network traffic to access your X server. So instead, you can go ahead and select defaults when this sort of prompt comes up:

Now, irritatingly this will actively add a block rule (rather than simply not add an allow rule) for public networks which you will need to disable for the next step by going into Windows Defender Firewall -> Inbound Rules and disabling this block rule for TCP on the Public Network.

If you don't do the above step, the Block rule will take precedence over the Allow allow rule and you won't get through.

Now, right click on Inbound Rules and select New Rule..., select TCP port 6000 (most likely) and select defaults. This will open up your public network for this port... which is also not what you want. What you want is to only allow traffic from the WSL subnet. So refresh the list, scroll to your recently created name, right click and go to properties. Now under Scope, go to Remote IP address, Select These IP addresses and add in 172.16.0.0/12 to limit the subnets which can access this port to the WSL subnet. It should look something like this:

Alternatively you could just disable the entire firewall for WSL, but that adds a firewall warning that constantly irritates me:

powershell.exe -Command "Set-NetFirewallProfile -DisabledInterfaceAliases \"vEthernet (WSL)\""

Application X not working

Does the application use dbus? If so, it's recommended to put something like this in your .bashrc to satisfy the many applications which depend on dbus to function:

dbus_status=$(service dbus status)
if [[ $dbus_status = *"is not running"* ]]; then
  sudo service dbus --full-restart
fi

Also check that the .bashrc tweaks are added before any nastiness like this in your .bashrc which would prevent DISPLAY from being set:

# If not running interactively, don't do anything
[ -z "$PS1" ] && return

You can do similar with docker or any other service which you will need access to, but won't necessarily already be running in a vanilla WSL installation.

To debug further, you can run the shortcut directly from the command line from a cmd shell:

wsl.exe -d <your-wsl-distro> -u <your-wsl-user> -- source ~/.bashrc ; env; xterm

Replacing xterm with whatever command you're trying to launch. Note the env command will print out all environment variables set before running xterm in this example, so this should help you double check if DISPLAY is really set correctly.

Raising Issues

Issues may be raised in github issues. Before raising an issue though:

• Verify that you have an X Server running on windows 10. Popular options include X410 or Xming.
• Verify that you can actually launch X applications from a WSL terminal (e.g. try running xterm).

If an issue is to be required, please prepare the log output from the command and details on your execution environment. Ideally try and find the .desktop file relating to the failing software as well.