Tilix: Unsure how startup works

[jaromero]

I can't seem to figure out exactly how the starting directory is determined when opening a new terminal. I'd like to be able to start in my home dir, as (xfce4|gnome|pantheon)-terminal do. Sometimes terminix starts in a directory I've used recently, but I have no idea what exactly makes it do so, instead of starting at home.

I've tried these things to attempt to control the starting directory:

• Enable/disable 'run command as a login shell' (so whether vte.sh loads or not doesn't seem to be an issue)
• Use /usr/bin/byobu as a command, as login and non-login
• cd or cd ~ before exit
• cd to home before closing terminix by using the close button
• Open a split, cd to home in one of the splits, exit both splits in any order
• Doing the same as above, but with tmux/byobu splits
• Doing the same, but running random commands before or after cd, before exiting (e.g. gulp). This _sometimes_ works but I haven't figured out exactly what makes it work.

In addition, doing things like running this script, even outside of terminix, makes terminix start in ~/bin/sublime_text_3 on the next startup, but not if terminix was already open and a new session or split is open:

#!/bin/bash

SUBLIME_DIR=$HOME/bin/sublime_text_3

$SUBLIME_DIR/sublime_text "$@" & > /dev/null 2>&1

The things I've found that consistently make terminix start in my home dir are either explicitely open my home directory with it from nautilus, or open any other terminal _first_ (which opens at ~) and then opening terminix.

[gnunn1]

Sometimes I wonder that myself, I'll spend some time tomorrow documenting this.

However, one thing to make sure is that the VTE is configured correctly so it returns the CWD of the shell to terminix. You can tell if it's not configured correctly if you cd to a new directory, split a terminal and the new terminal doesn't use the directory of the terminal it was split from.

[gnunn1]

So I reviewed my code and in a nutshell it's a bit confusing. There are actually different scenarios in play with subtle differences between them as follows:

1. Pass the workingDir explicitly. If you pass the working directory explicitly, it always uses this
2. First time running app, no command line parameters. Uses the PWD envrionment variable
3. First time running app, command line parameters but not workingDir parameter. Uses the current CWD.
4. Running a new instance of the app. Passes remote CWD to current instance and uses it when creating new window, session, etc

I might look at simplifying this and essentially make the rules as follows:

a. Use workingDir parameter
b. If PWD environment variable is available, use that
c. Use CWD as last recourse

This should work for the problematic edge cases (Unity, Nemo) as well as everywhere else and provide a more consistent approach. I'll review what gnome-terminal is doing in this regard as well.

[egmontkob]

I think 2 & 3 (or b & c) should be swapped. Typically apps don't change their directory, they just go along with whatever they receive, in the sense of the OS's current directory (e.g. getcwd()). This directory is actually a location in the file system, not a pathname leading there.

PWD is used by apps (e.g. shells) that display the pathname of this directory. It allows to display paths containing symlink components, rather than always figuring out the canonical path.

Quoting get_current_dir_name(3): "If the environment variable PWD is set, and its value is correct, then that value will be returned", whereas "correct" means that it points to the same directory object. If PWD points somewhere else then it is ignored and the actual working directory's canonical path is constructed.

That is, PWD is only a weak hint in resolving ambiguities in the current working directory's pathname.

[gnunn1]

If you swap 2 and 3 you would never use PWD because the app always has a CWD AFAIK. I have it in this order because as I recall when Terminix is launched in Unity the CWD is set to root but the PWD is set to the users home directory. I do want to go back and double check this though.

Having said that, I completely understand your point. I really need to figure out what g-t is doing and emulate it since it is the defacto standard.

[egmontkob]

in Unity the CWD is set to root

I cannot confirm this.

If it was so, pretty much all apps would work with their cwd being the root dir.

I think the defacto standard is get_current_dir_name(3)'s behavior (as I described above), and both g-t and terminix should follow that. (If g-t doesn't then that's a bug in g-t.)

I admit my wording was incorrect: you shouldn't _swap_ 2 & 3, but go with CWD as the actual directory object, and prefer PWD's path representation if it's not contradicting.

[gnunn1]

The unity thing is based on #214. It's possible this was caused by something else, your point about other apps is a good one.

[gnunn1]

@egmontkob So I added some logging to Terminix and it does look like the CWD is being set to the root directory. I need to investigate some more, maybe there is a bug in the D getcwd function or something else is going on.

2016-05-05T08:35:05.265:app.d:main:28 CWD = /
2016-05-05T08:35:05.265:app.d:main:31 PWD = /home/gnunn

[egmontkob]

@gnunn1 How do you _exactly_ start up terminix? What happens if you start xterm the same way? Where does /proc/(terminix's PID)/cwd point to?

[gnunn1]

@egmontkob I start it my clicking on the pinned button in the Unity Launcher or by searching for it through the Dash. If I check the cwd in proc, it is pointing to the root directory. xterm starts in the user directory.

One thing I noticed is that Unity is launching terminix as a dbus service, a ps -ef shows the following:

/usr/bin/terminix --gapplication-service

If I modify the desktop file to set DbusActivatable to false, it works as expected:

2016-05-05T09:03:56.562:app.d:main:28 CWD = /home/gnunn
2016-05-05T09:03:56.563:app.d:main:31 PWD = /home/gnunn

[gnunn1]

Also, Gnome Shell doesn't start Terminix as a dbus service as far as I can tell.

[gnunn1]

Finally, an interesting factoid. In Ubuntu gedit has two desktop files in /usr/share/applications, one of which, gedit.desktop, doesn't have the DBusActivatable line while the other, org.gnome.gedit.desktop, does.

[egmontkob]

Interestingly, for me terminix's /proc/xx/cwd points to my home if I start it via Unity's Alt+F2.

gnome-terminal-server's cwd is also my home, even if I start the first gnome-terminal instance from another directory. No clue whether g-t does anything for this, or it just activates the server via dbus which defaults to my home.

Alas, I don't know anything about dbus.

Since terminix (similarly to g-t) is a single process handling multiple terminals, and typing "terminix" connects to the already running instance (if any) and opens a new window within that, the CWD of terminix itself should actually not matter at all.

What matters is, whenever you type "terminix", the CWD and PWD of the context where you launch it from gets transferred to the terminix process and it launches the shell there. This works fine with current terminix.

I think the problem is: Why does your dbus launch it with cwd=/, whereas my dbus launches with cwd=/home/egmont?

What's your initial directory if you start gnome-terminal in the same manner?

I guess we'd need a dbus expert :)

[gnunn1]

gnome-terminal starts in my home directory as expected, however note if you cat gnome-terminal.desktop it does not have DbusActivatable either. I don't really understand the relationship between gnome-terminal and gnome-terminal-server though.

Like you I find it very interesting that you have the right cwd and I don't. I wonder if my install of terminix is somehow borked because I also don't get the icon showing as expected either. Did you install terminix using the install.sh or by expanding out the binary? I've been using install.sh exclusively.

[egmontkob]

I don't really understand the relationship between gnome-terminal and gnome-terminal-server though.

I don't either :) g-t is never persistent, it's always g-t-s that's running and showing UI and stuff. g-t is the one that fires up g-t-s and/or connects to the existing instance to open a new terminal. I guess.

I've been using install.sh exclusively.

Me too:
dub build --build=release --force
sudo ./install.sh

[jaromero]

Here's some more data points (from Arch, gnome-shell 3.20, terminix from the AUR):

• Running terminix from the gnome-shell dock, the overview (both of which show as /usr/bin/terminix --gapplication-service in the process list), or the alt+f2 dialog (which shows as just terminix in the process list), CWD for me is $HOME
• Running terminix from xfce4-terminal or gnome-terminal or even xterm: terminix's CWD becomes the directory where I ran terminix from. Doesn't matter if I pass it a different directory with the -w flag (although it does start there)
• Running xfce4-terminal, gnome-terminal or xterm from inside terminix: CWD of those becomes terminix's CWD, whatever it ends up being
• Running xfce4-terminal, gnome-terminal or xterm from anywhere else: CWD of those always seem to be $HOME, no matter if I pass them a different working dir via flags

[gnunn1]

@jaromero Thanks for taking the time to do that, interesting how you see it with the --gapplication-service when running from gnome dock but I don't here, I'm on Arch and 3.20 as well.

Note that there is a difference between the CWD of terminix the application and the CWD of the shell hosted in terminix. The terminix application CWD is constant and generally will not change, the CWD of the shell is variable. When you pass the workingDir flag, that sets the CWD of the shell but has no impact on the terminix application CWD you see in proc//cwd

The discussion here is when terminix is started, how best to convert the terminix application cwd and environment into the starting cwd for the shell. After all this discussion, I agree with @egmontkob the right answer is the CWD if workingDir is not set, but I need to figure out why in Ubuntu the CWD is being set to the root dir for me, there's something weird going on here.

I also want to ask on the GTK+ IRC channel how that --gapplication-service flag works and the impact it has on this discussion.

[gnunn1]

I've spent some time tonight looking into the Unity issue and I'm still stumped as to why Unity has the CWD set to the root directory. I was thinking maybe I was missing something in the sense that the DBus message used to activate Terminix contained the directory to start, i.e. maybe via an open files message. I tried adding a handler for it but no luck. I also used the dbus-monitor to see the messages being passed and didn't see anything that had a directory or tweaked me that I was missing something.

What I have done for now is implement a workaround that is much cleaner then what I was doing previously and hopefully provides a more consistent experience. As of now, as per @egmontkob suggestion, terminix uses the CWD only to derive the initial shell path when the workingDir parameter is not specified. Since the CWD is derived by calling g_get_current_dir this should handle the issue with cwd/pwd and symlinks as per the docs for this function.

What the workaround does, in app.d, is look if the command line switch --gapplication-service is passed and if cwd != pwd it sets the cwd for the terminix process to be pwd. This happens at the very bringing of application execution which is much better then my previous hacky way of dealing with it way down in terminal.d. This way the workaround carries down to everything from a code perspective.

At the moment I consider this an improvement but it's still just a workaround, I still really want to understand what is going on here so I haven't closed the issue. I'll ask about this on the gtk+ irc channel on Monday when some of the more knowledgeable folks are around and see if I can get some advice. Depending on what I hear fromthem, I'll open a bug for this against Unity.

[gnunn1]

I have opened a bug with Ubuntu Unity for this:

https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1580673

[gnunn1]

@jaromero Are you finding things better with the new release, can I close this?

[jaromero]

So far so good. I had modified the .desktop file to comment the DBusActivatable line to work around this issue temporarily, but I enabled it again and have been trying it for a few hours without issue.

[jaromero]

Wait, false alarm. This is what still happens for me (without the .desktop file workaround I mentioned):

• Open terminix, cd to anywhere and then exit: the next Terminix session starts at $HOME (or rather, wherever you initially started at)
• Open terminix, cd to anywhere, then open a new split or tab, then exit both splits in any order: the next Terminix session starts on that other directory

The key part is opening a new tab or split. Seems like the path gets remembered at the time you open a new tab or split.

[gnunn1]

@jaromero I'm not sure I'm following you, can you lay out what you are doing in precise steps, i.e. Step 1: With no terminix instances open, start Terminix, Step 2: cd to directory, etc.

The new session is supposed to inherit the directory of the currently active terminal, that's actually a feature that was added for #246. However I'm not sure if this is what you are experiencing because you mention exiting terminals and it sounds like starting a whole new Terminix instance, is that correct?

[jaromero]

That's correct, in both cases I'm starting a new instance without other instances running.

To clarify, this is what I did, straight from a clean boot. I'm just going to say "open a new tab"/"close the tab" but it seems to apply to both tabs and splits:

1. Start Terminix. It starts in ~
2. cd to, say, ~/Desktop
3. exit
4. Start terminix again. It should also start in ~
5. cd to ~/Desktop again
6. Open a new tab. This one opens in ~/Desktop, which is probably the feature from #246
7. exit in the new tab, then exit again in the initial tab (therefore exiting Terminix completely)
8. Start Terminix again. This time, it starts in ~/Desktop, which is not what I'm expecting.
9. Close and start Terminix again
10. cd to a different directory (e.g. ~/Documents)
11. Open a new tab (opens in ~/Documents)
12. exit this new tab, then exit the initial tab
13. Start Terminix again and see how it opens in ~/Documents

If you repeat steps 10-11, each time picking a different directory, and then closing all tabs, the next time Terminix starts it'll start in the last directory you picked. Or to be more precise, it'll start in the pwd of the terminal from where you last opened a tab (if you switch back to, say, the second tab, and open a new tab from there).

Agh. I apologize, I didn't test so thoroughly, I'm finding that everything in my original comment still happens. All the way down to the "opening another terminal emulator makes terminix start in ~ again" bit.

And once again, none of this happens if I run /usr/bin/terminix directly, or if I disable the DBus part in the .desktop file (except for the feature from #246, that one still works just fine)

[jaromero]

Quite a shot in the dark, but since this seems to be related to DBus...

I have a file at /etc/x11/xinit/xinitrc.d/50-systemd-user.sh with the following content:

#!/bin/sh

systemctl --user import-environment DISPLAY XAUTHORITY

if which dbus-update-activation-environment >/dev/null 2>&1; then
        dbus-update-activation-environment DISPLAY XAUTHORITY
fi

It seems it's just part of standard Arch systemd, but I wonder if it has something to do with this issue.

[gnunn1]

@jaromero Thanks for the detailed information, I'm just heading out to catch a plane but I'll work on this tomorrow night.

[gnunn1]

@jaromero I'm not able to reproduce following your steps, a new instance of Terminix (without one already running) always opens in $HOME for me regardless of what I've done previously. Like you I'm on Arch Linux and gnome-shell 3.20.

It almost sounds like to me like something is remembering the shell CWD and restoring it, I'm not familiar with byobu but is there any chance it is doing this? It can't be Terminix because I'm not saving any state between stopping one instance and starting another assuming Terminix is completely shut down.

[jaromero]

I don't think it's byobu, these last tests were done with a clean profile, and none of the other terminals with which I do use byobu don't behave like this.

[gnunn1]

Can you do paste here what ps -ef | grep terminix shows when Terminix is running.

[gnunn1]

To elaborate, you are probably right it's related to DBus, on my system though Gnome Shell doesn't launch Terminix with DBus activation, on yours it probably does which I can see with the output from PS -ef

[jaromero]

[nsdragon:~]$ ps -ef | grep terminix
nsdragon 31991   824  3 17:47 ?        00:00:00 /usr/bin/terminix --gapplication-service
nsdragon 32491 31995  0 17:47 pts/0    00:00:00 grep --color=auto --exclude-dir=.bzr --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg --exclude-dir=.svn terminix

[gnunn1]

So I figured out why Terminix wasn't starting using Dbus, I had an extra desktop file in some directory called .gnome/apps that was od. Once I removed it Terminix started launching with the Dbus as expected.

Unfortunately I still cannot reproduce your problem. I did fix one bug associated with starting terminix manually with --gapplication-service but it wasn't causing the issue you described.

When you run your steps, between steps 7 and 8 can you do a ps and confirm that terminix is not running which is what I expect to see at this point.

[jaromero]

It's definitely not running, the process ends as soon as the window closes.

[gnunn1]

@jaromero Well I'm a bit stumped as I cannot reproduce it. If the process has ended then Terminix isn't keeping any state which implies something external is causing the change in directory.

If you are willing, I'll build a version that outputs a trace log to a file for you to try, that should give me more information about what is happening on your system.

[jaromero]

Sure, I'd be willing to try it out

[gnunn1]

I've uploaded a debug binary here:

http://www.gexperts.com/files/terminix.zip

Just unzip and replace /usr/bin/terminix with this one. This will create a file /tmp/terminix.log, just run through your steps then e-mail me the log file.

[jaromero]

I put it in a gist here: https://gist.github.com/jaromero/684a06583a5eb17f2f648fa1617f1df8

I followed exactly the same steps I listed above. But also as a final test, I started terminix again and repeated steps 10-11 three more times in the same terminix window before doing exit in all the tabs, and restarting terminix one final time to get the startup in the log.

[gnunn1]

Thanks, I see exactly what the issue is. For some reason, the PWD environment variable is different then the CWD at lines 181-182:

2016-05-17T21:52:35.817:app.d:main:33 CWD = /home/nsdragon
2016-05-17T21:52:35.817:app.d:main:36 PWD = /home/nsdragon/Desktop

To work around an Ubuntu Unity bug, where the CWD is set to '/' and PWD to the home directory, I check for this situation when DbusActivation is used and change the CWD to match the PWD at line 186. Obviously I am being a little over-aggressive about this fix.

I'll try to narrow this check down to just being applied for Unity but I'd give my left arm to know why these differences in PWD and CWD exist under DbusActivatable. I've done some googling but nothing obvious has come up.

[gnunn1]

So doing some reading, it definitely sounds like I should be ignoring PWD sinc eit only gets set by the shell. By I still have that annoying issue with Ubuntu and Unity. As a secondary check, I tested with baobab (the disk usage analyzer) which also uses DBusActivatable and it has the same problem as Terminix, it gets started in the root directory:

gnunn@gnunn-VirtualBox:/usr/share/applications$ cat org.gnome.baobab.desktop 
[Desktop Entry]
Name=Disk Usage Analyzer
Comment=Check folder sizes and available disk space
Keywords=storage;space;cleanup;
TryExec=baobab
Exec=baobab
Icon=baobab
Terminal=false
Type=Application
StartupNotify=true
MimeType=inode/directory;
Categories=GTK;GNOME;System;Filesystem;X-GNOME-Utilities;
NotShowIn=KDE;
X-GNOME-Bugzilla-Bugzilla=GNOME
X-GNOME-Bugzilla-Product=gnome-utils
X-GNOME-Bugzilla-Component=baobab
X-GNOME-Bugzilla-Version=3.18.1
DBusActivatable=true
X-Ubuntu-Gettext-Domain=baobab
gnunn@gnunn-VirtualBox:/usr/share/applications$ ps -ef | grep baobab
gnunn    14590  1097  0 22:40 ?        00:00:00 /usr/bin/baobab --gapplication-service
gnunn    14598  2126  0 22:40 pts/5    00:00:00 grep --color=auto baobab
gnunn@gnunn-VirtualBox:/usr/share/applications$ ls /proc/14590/cwd
bin  boot  cdrom  core  dev  etc  home  initrd.img  lib  lib64  lost+found  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var  vmlinuz
gnunn@gnunn-VirtualBox:/usr/share/applications$ 

[gnunn1]

@egmontkob Can you confirm something for me, if you launch Terminix from the dash (launcher or by searching), is the CWD still set to your home directory or is it set to /? If I launch Terminix with Alt-F2 like you did, the CWD is set to my home directory. It only gets set to '/' if I launch it from the left toolbar or by clicking on the icon after searching for it in the Dash.

[gnunn1]

@egmontkob Actually can you confirm this with baobab, since I'm checking for this situation and automatically changing CWD in terminix to deal with it you can't check it with Terminix.

[egmontkob]

With baobab can I see the current directory somewhere, or would I have to dig into /proc? For convenience, I rather went with xterm instead, is this okay?

I'm not sure I got exactly the use cases you asked for, here's what I did:

1. Alt-F2, type xterm, press Enter
2. Alt-F2, type xterm, click on its icon under the Results section
3. After either of the previous, right-click on the left-hand launcher's xterm icon and choose Lock to Launcher. Quit xterm, and then use this icon in the launcher to launch it.

In all three cases it starts in my home dir.

(Note that it's an installation and home directory, settings etc. since the Precise Pangolin days IIRC, upgraded every half year. A new user or a new Ubuntu installation might differ.)

[gnunn1]

@egmontkob Sorry you would have to check proc, I don't think xterm is a valid example because the app has to have DBusActivatable in the desktop file which xterm does not. However baobab does which is why I tested with it. I just wanted to confirm the problem with Unity is not confined to my VM.

Also, Alt-F2 works fine on my VM, the problem really looks related to when it is launched from the Dash directly by clicking on the icon.

Basically:

1. The app has to have DBusActivatable set to true in the desktop file
2. The app has to be launched from the dash (bar or search) but not by typing in the command in Alt-F2 dialog.

[egmontkob]

Okay, apparently I don't know what Unity's "dash" is :) (I recall disabling a hotkey a long time ago, not sure).

So, I'm clicking on the Launcher's topmost icon (tooltip: "Search your computer"). Type baobab. Under the Applications section there's a Disk Usage Analyzer. Click.

The process is "/usr/bin/baobab --gapplication-service", and its cwd is, tadaaaa, as you expect: the root directory.

[gnunn1]

Thanks @egmontkob, that's perfect and what I was looking for. I modified the workaround to only take effect when Unity is the DE so hopefully that will fix @ jamomero problem.

I'm not an Ubuntu user si sorry about the terminology, I thought the button at the top of the launcher and the launcher itself was called Dash but I'm probably wrong.

[gnunn1]

@jaromero I have upoaded a new release, 0.60.2, that has a fix for your issue. Please test when you get a chance and if the issue is persisting re-open this issue.

[jaromero]

Now that I've been actually using it in my daily workflow this time, I have yet to run into this issue again. Thank you!

[gnunn1]

@jaromero I had to tweak this workaround again for #337, if I build another test binary would you mind giving it a go again to make sure you're problem stayed fixed?

[jaromero]

I can test, yeah (sorry for the delay)

[gnunn1]

@jaromero You can download the updated version here:

http://gexperts.com/files/terminix.zip

Thanks again for doing this.

[jaromero]

I think something went wrong.

~ $ terminix
2016-05-27T09:10:22.920:app.d:main:34 CWD = /home/nsdragon
2016-05-27T09:10:22.921:app.d:main:38 PWD = /home/nsdragon
2016-05-27T09:10:22.921:app.d:main:44 UHD = /home/nsdragon
2016-05-27T09:10:22.921:app.d:main:46 Starting terminix with 1 arguments...
2016-05-27T09:10:22.921:app.d:main:48 arg[0] = terminix
2016-05-27T09:10:22.921:app.d:main:65 No terminix UUID found

(terminix:5635): Gtk-WARNING **: Theme parsing error: gtk.css:4176:43: 'gtkalpha' is not a valid color name

(terminix:5635): Gtk-WARNING **: Theme parsing error: gtk.css:4189:31: 'gtkalpha' is not a valid color name

(terminix:5635): Gtk-WARNING **: Theme parsing error: gtk.css:4190:41: 'gtkalpha' is not a valid color name

(terminix:5635): Gtk-WARNING **: Theme parsing error: gtk.css:4194:32: 'gtkalpha' is not a valid color name
2016-05-27T09:10:22.952:app.d:main:87 Creating app
2016-05-27T09:10:22.953:app.d:main:91 Running application...
2016-05-27T09:10:22.955:application.d:onAppStartup:399 Startup App Signal
2016-05-27T09:10:22.955:resource.d:findResource:44 looking for resource /usr/local/share/terminix/resources/terminix.gresource
2016-05-27T09:10:22.955:resource.d:findResource:44 looking for resource /usr/share/terminix/resources/terminix.gresource
2016-05-27T09:10:22.955:resource.d:findResource:48 Resource found and registered /usr/share/terminix/resources/terminix.gresource
2016-05-27T09:10:22.955:application.d:loadResources:142 No specific CSS found /com/gexperts/Terminix/css/terminix.Arc-Darker.css
2016-05-27T09:10:22.956:application.d:onAppStartup:403 Monitoring shortcuts

(terminix:5635): Gtk-WARNING **: Theme parsing error: gtk-dark.css:4174:43: 'gtkalpha' is not a valid color name

(terminix:5635): Gtk-WARNING **: Theme parsing error: gtk-dark.css:4187:31: 'gtkalpha' is not a valid color name

(terminix:5635): Gtk-WARNING **: Theme parsing error: gtk-dark.css:4188:41: 'gtkalpha' is not a valid color name

(terminix:5635): Gtk-WARNING **: Theme parsing error: gtk-dark.css:4192:32: 'gtkalpha' is not a valid color name
2016-05-27T09:10:22.976:application.d:applyPreference:459 Default menu accelerator is F10

(terminix:5635): GLib-GIO-ERROR **: Settings schema 'com.gexperts.Terminix.Settings' does not contain a key named 'background-image'
[1]    5635 trace trap (core dumped)  terminix

[gnunn1]

My mistake, I must have accidentally commited the background image stuff to the stable branch at some point. I've reverted that commit, re-built the binary and updated the file on my site. Please try downloading it again from the same location as previously, my apologies for the extra work.

[jaromero]

No problems with this new build so far from what I've seen.

[xgenvn]

This issue happens to me after I upgrade to stable version. The last beta was working very well. If I follow the VTE configuration wiki, powerline will be broken. I'm looking into this issue and will provide more details if I can.

[gnunn1]

@xgenvn I think this has been fixed, I just need to do a new stable release. I'll take care of it later today.