
So I had a few requests for iTerm support, one request for xterm support, and one request for glterm support. And I thought about it, it would probably be easy, but I didn’t want to add preferences to my little one click mini application—it’s a little gratuitous. I also didn’t want to make a bunch of versions of the same program. However…
I then remembered there is a user interface in the get info window for enabling & disabling plugins inside a app package. So I thought it would be fun to create a use case in which someone actually would have a need to utilize this user interface in addition to fixing my issues with adding this features.
I created a very simple plugin interface, and “>cd to…” only checks the built in plugin folder (as that is the only directory that get info deals with — it also means that duplicate copies can have different behaviors enabled). So to get support for iterm or xterm you just have to enable the correct plugin while disabling the others (FYI though, if you have more than one plugin enabled it will open windows in each enabled plugin)
GLterm doesn’t look supportable for any automated directory change, at least as far as I can tell, so that’s why I only added xterm and iterm support.
Another small detail to note, about my xterm/X11 plugin, is that the script to launch the terminal is inside the X11_xterm.bundle’s resource folder. So you can add xterm flags or even change the X11 terminal without recompiling.
v 2.1
- Plugin archtexture allowing support for other terminals
- Default plugins for iTerm & X11/xterm
- Terminal plugin will try to avoid opening two windows on terminal.app’s launch