"Kluge fur ein besseres heute. Kluge fur ein besseres morgen."

Who's On - Second beta release

Released 2/27/00

Welcome to the second beta release of Who's On! This took longer than I thought to get out, mostly because of some outside interference and schoolwork. A few new features have been added, and several buggy areas in the code have been cleaned up. Overall I think this release represents a major improvement over the original. More remains to be done, though, before the first version is ready for its final release, and there will probably be a third beta before then. Check back here every once in a while to see how things are shaping up.

What is Who's On?

Who's On is a Java program that checks any number of MUCKs you specify for any number of characters you're interested in finding. A report of who's on (see where the name comes from?) will be displayed in a window. This report is automatically updated every so often, so if you're on a dedicated net connection (such as a cable modem, DSL, or in-office ethernet) you can just leave Who's On running and it will save you the trouble of logging into MUCKs just to find there's nobody online you want to talk to. You can also have Who's On look for people you want to avoid- it's all up to you.
Visit the screenshots page to see shots of Who's On running on various platforms. Pictures of the program running on other platforms will appear there in the future.

What's new in the second beta:

File menu: Added to the menu bar, it contains three options:
- Reread config file: Reloads the configuration file. Any changes you've made to the config file will take effect in future updates, including the addition of new characters or new MUCKs.
- Update display: Reloads the configuration file and checks all MUCKs you've listed for the characters you're looking for, including new ones you've added to the file.
- Quit: Exits the program.
Update button: Has the same effect as "Update display" in the file menu, but I decided to add a button to the window to make this handy function a little easier to access.
Update prediction: The first beta would tell you when it last updated and how long it waited between updates, leaving you to do the math to figure out when it was going to update its display again. Now the program does that for you and displays when it will next update.

Bugs fixed:

Improved stability: The first beta had some code that would lead to NullPointerExceptions if it couldn't properly connect to a MUCK system for whatever reason. Quite often these weren't caught and would cause the program to crash. Those have been cleaned up, and exception handling overall has been improved. If something goes wrong there may still be all kinds of complaining dumped to stdout and stderr, but the program is a lot better about surviving these little hiccups and continuing to operate.
Closing the display window actually works: Now when you click on the widget for closing the window (whatever that is for your platform), the program exits. Previously, nothing happened at all.
Version number correct: Last but not least, the first beta should have identified itself as version 0.9b1, but I forgot to change that when I released it. It left the factory identifying itself as an alpha release, v0.9a, which was incorrect. The second beta has the correct version number displayed, 0.9b2.

Known bugs in the second beta:

Color change issues: Testing revealed that if you change the config file's entries for the foreground and background color of the display window, sometimes those changes won't take effect until you next restart the program. On some platforms even rereading and resetting the same colors (this kind of rereading of settings will happen every time a forced check is run) caused problems. Currently, resetting of color preferences on the fly without restarting the program has been disabled pending a fix. All other changes to the config file are known to take effect when the file is reread.
Accuracy issues: Sometimes if a MUCK is lagging heavily the program will incorrectly show no characters of interest connected, even if some that you are looking for actually are online. This seems to happen most frequently with FurryMUCK, though it's been known to happen with others every once in a while. This problem also affected the first beta and work on a solution is ongoing.

Planned additional features for the third beta or future versions:

Configuration editor: I plan to add a feature that will allow the user to create or edit a configuration file without having to open up a text editor and write one from scratch. Combined with this will be the ability to switch between config files without restarting the program. This may wait until sometime after v1.0, perhaps being added in beta releases leading up to v1.5.
Console beep: This feature will allow the user to specify that the computer beep (or in Windows and Mac, play the "Default Beep" or "Attention" sound) if certain names are found on certain MUCKs. This will let you know with sound if someone really important to you logs on, while the rest of your list is silently displayed.
MU* compatibility: Right now Who's On only works with MUCK systems, and systems that give the same kind of output format when "WHO" is entered on the login prompt. Eventually I hope to have support for common types of MUDs, MUSHes, MOOs, etc. as well.
Your time is my time too: Currently Who's On shows all times in 24-hour time. I plan to add the ability for the user to specify that times be shown in 12-hour time with AM/PM appended. Internally, the program will continue to use 24-hour time for its own purposes, regardless of what it displays.
User documentation: Right now there's little documentation for how to use Who's On. Eventually I want to get up a set of online documents that tell the user how to set up the program and use it effectively.
Programmer documentation: Who's On is a program that is intended to normally run on its own, but it is designed so that it can also be loaded into and called from called from another Java program. Right now the public methods and fields of the Who's On classes aren't documented, but I'd like to put up that information. This may wait until the 1.0 release, though, as the fields within each class are subject to change until then, and I'd rather not have to document everything twice.

Download and install

System requirements:

A Java Virtual Machine that can run standalone applications (this rules out Netscape, Internet Explorer, or any other web browser). Who's On was written to Java 1.0 specifications and thus should run on just about any standalone virtual machine out there. Check the system requirements for the JVM you plan to use to make sure it will run on your system.
A graphical windowing environment. Windows 9x/NT/2000, Mac OS, and Amiga users should be fine. Unix users will need to have an X server installed and running (using any window manager and/or desktop environment that will work with your JVM). DOS/Windows 3.x users... Was there a JVM ported to DOS? Well, if there was, I'm not sure you can run this unless your JVM can create windows in Windows 3.x. I'm interested in knowing more about this.
A text editor for creating/editing the configuration file(s) that Who's On will use to know who to look for on what MUCKs.

Files

You'll need to download the following files for this program to run.

whoson.class
muck.class
EventHandler.class
You'll also want to see a sample config file

Eventually I'll have all of these compressed into archives for various platforms... zip files, bin-hex files, gzipped tar files, etc. For now you'll have to download them individually. They're pretty small and shouldn't be a problem though; the largest, whoson.class, is about 10K. Just as a reference, this HTML file is larger than the combined total of all the Who's On binaries.

Put all the class files and the config file into the same directory or folder. Edit the config file with your favorite text editor so that it's got the MUCKs and characters you'd like to look for. Follow the same format as the example file, and read the comments in the file for more instructions. Feel free to delete the characters and sample MUCKs in the sample file once you've added your own.

Running Who's On

Read the section for your platform, then make sure to read the Notes section that follows. The information there applies to all platforms.

Windows 9x/NT/2000 and unix

By this point you should have your Java Virtual Machine installed and have it added to your path if it's not there already. To run the program in Windows 9x/NT/2000 and unix, open up a command prompt (DOS window, xterm, whatever) and change to the directory where you placed the program. If you've named the config file something other than whoson.conf, type

java whoson [filename]

and replace '[filename]' with the name of the new config file you've created. If the config file is titled whoson.conf, you can leave the filename out of the above command entirely. You may optionally specify the refresh rate as a number of minutes (integer values only) on the command line. This will override the update time specified in the config file (if any) and must appear after the filename argument (if any). For unix-minded people, the overall syntax of the program should look like

java whoson [filename] [refresh]

In Windows, you can create an icon to put on your desktop that will start a DOS session and run a batch file that will launch this program with whatever command line arguments you specify. Whether or not you can do this in unix (with a shell script instead of a batch file) depends on the capabilities of your window manager and/or desktop interface. Setting this up in either case is not documented here.
In the event something goes wrong during program execution, Who's On will write messages to stderr or stdout. Those may be viewed as they occur by looking in your command prompt window, assuming you haven't redirected the output.

Macintosh, System 7.x and 8(68k)

Here you'll need to use a Java 1.0 virtual machine, as to my knowledge no Java 1.1 interpreter has been ported to System 7.x. You may try running Mac OS 8 MRJ (see next section) on your OS 8-equipped 68040 Mac, but I'm not sure it will work. If you have a System 7.x machine, whether equipped with a 68k processor or a PowerPC chip, this section applies to you.
I'll assume you've installed the Sun Microsystems JRE for the purposes of this document. I will be checking with Sun to see if I can post a copy of their old 1.0 Mac JDK for download here. You should put all four of the files above into the same folder. The Sun Java Runtime should have come with a file titled Java Runner. Make a copy (not an alias) of this file and place it in the same folder as the .class files. Now you should be able to run the program by either double-clicking on whoson.class or dragging it onto Java Runner. A dialog box will pop up asking you to "Enter command line arguments:". If you just press return, the program will use the default filename for the config file (whoson.conf) and will use the default refresh rate if you didn't specify one in the config file. If you used a different name for your config file, enter it in that dialog box; if you want to use a different refresh rate besides one specified in the config file you may enter it (an integer, in minutes) in this box also. If you are entering both a filename and a refresh rate, the filename comes first, with the refresh rate second, separated by a space.
The only difficulty here is that Mac OS 7.x wasn't very intelligent about handling files that don't have resource forks. You may have to use a program like ResEdit or FileTyper to make sure that Mac OS knows that whoson.class should be opened by Java Runner. This should be less of a problem once I have created a Mac binary archive that will hold the resource forks for these files.
Since Mac OS doesn't have a console per se, anything that Who's On writes to stdout or stderr will have to appear in a window instead. This usually appears behind the Who's On window, and will only appear if there has been a problem of some kind. Once you've read what the program has to say, you can close that window without fear of closing the rest of the program. The Java runtime saves all that was written to that window in a buffer, though, so if you close the window and it appears again before the program is restarted, the old error messages will still be there.

Macintosh, Mac OS 8(PPC) and 9

For Mac OS 8 and 9 you'll need the MRJ (Macintosh Runtime for Java) that Apple has created. This can be downloaded at http://www.apple.com/java/. You can also find their Java "Software Development Kit" there (MRJ/SDK) that will allow you to compile your own Java programs. Once you have this installed and have all four files you downloaded from here are in their own folder, drag whoson.class onto the program called JBindery. This will launch the Java runtime environment and will present you with a dialog box. If you just press return, the program will use the default filename for the config file (whoson.conf) and will use the default refresh rate if you didn't specify one in the config file. If you used a different name for your config file, enter it in that dialog box in the section titled "Optional Parameters"; if you want to use a different refresh rate besides one specified in the config file you may enter it (an integer, in minutes) in this box also. If you are entering both a filename and a refresh rate, the filename comes first, with the refresh rate second, separated by a space.
You have the option to save your settings as an application, and if you do so that will create an application file that when double-clicked will allow the program to run on your computer without dealing with the dialog box I just mentioned, and it will allow the program to be run on any PPC-based Mac OS 8 Macintosh (not sure about 68040-based Mac OS 8 machines) even if the MRJ has not been explicitly installed, since 8 contains libraries and extensions that are designed to run these Java programs. I haven't posted such a file here as the program that JBindery generates seems to be path-dependent. That is to say, if I made one in a folder titled "whoson" and that folder was on my desktop at the time, you would need to create a folder with the same name, place it on your desktop, and keep the application and all other files there. Moving it elsewhere would cause the program to not be able to find its .class files. Until I find a workaround for this I don't plan on posting any JBindery-created application files.
Since Mac OS doesn't have a console per se, anything that Who's On writes to stdout or stderr will have to appear in a window instead. This usually appears behind the Who's On window, and will only appear if there has been a problem of some kind. Once you've read what the program has to say, you can close that window without fear of closing the rest of the program. The Java runtime saves all that was written to that window in a buffer, though, so if you close the window and it appears again before the program is restarted, the old error messages will still be there.

Macintosh, Mac OS X

Mac OS X is supposedly going to be a fusion of Mac OS and unix features... I'm not really sure how one will go about running this on Mac OS X. This section is going to have to wait until the end-user version of X comes out (Mac OS X Server has been out for a while now). Who's On ought to look cool with all those nifty Aqua widgets, though, provided Java runtimes for Mac OS X support them.

Amiga

If you can tell me how to properly run this on an Amiga, please let me know.

Notes- all platforms

When you force an update to the display, whether by using the button or the menu option, the display will show the time of the forced update as the 'last update' on the screen, but this will not affect when the next scheduled automatic update will happen, except as described in the next note.
If you force an update or reread the configuration file close to the next scheduled update time and your forced update/reread is still running when the scheduled time arrives, (for example, you hit the update button at 11:59:55 and the next update was scheduled for 12:00) the next scheduled update will not run, but the time for the next update after that will still be calculated and displayed. In this case, the program will consider the time of your forced update to have been "close enough for government work" and won't bother running another one immediately after. So in the case of the example above, if the program was set to update itself ever 20 minutes (the default setting), it would not perform an update at 12:00 but would rather reset itself to do one at 12:20, the "new" next scheduled update time. This is to prevent trying to run the same thread twice, which is also the reason why the program behaves as described in the next note.
If you attempt to reread the config file or force an update while an update (forced or scheduled) is going on, nothing will happen.
If you specified a refresh rate on the command line, it will override any such entry in the config file. It will also override any future rereads of the config file until such time as the program is restarted.
MUCKs will be checked and displayed in the order they are listed in your config file, but the order in which the individual characters are displayed is representative of the relative lengths of time each has been online, with the characters at the bottom being those who have been on the longest.
If a character shows up on your screen more than once, that usually indicates that they are connected to that MUCK more than once.
Laggy MUCKs will cause the program to appear to hang while doing its updates. Usually it's just waiting for the MUCK to send it back some data to read. After a while it should give up waiting and get on with its life. In any case, you're better off putting laggier MUCKs later in your config file.
This program causes some processor time and network bandwidth to be used on the MUCKs it checks. To be considerate to the owners and users of those systems, you should keep the automatic refresh rate something reasonable, like maybe 15 or 20 minutes (the default refresh rate is 20). If you really need to check the MUCKs between those intervals, you can use the refresh button.

Contact the programmer

I'll be happy to answer most questions you have about the installation and operation of this program. I can't provide support for the installation and use of the Java Virtual Machine required to run it, however; you'll have to talk to the people who wrote that to get help with their program. I'll also take suggestions for features in future releases of this program. I can be reached at otto@twu.net

Kluge Software home

Java is a trademark or registered trademark of Sun Microsystems. Apple, Macintosh, and Mac OS are trademarks of Apple Computer. Windows is a trademark of Microsoft. All other trademarks are the properties of their respective owners.