Installation

>I took a look at tkbiff and it looks very nice.  For the novice user, the
>configuration file looks a bit overwhelming.  If somehow the code could be
>stripped out and just leave the user to change the real important things
>would be nice.

I actually wrote another biff which was vastly simplified. But simplicity has substantial drawbacks. Not only is flexibility hindered but users were frequently confused about what certain options did. In the current version, the code is all there so users can see exactly what will happen.

To take a simple example, in other biffs, a frequent question is "if a message matches multiple patterns, will one sound play or will multiple sounds play?" and the frequent followup was "how can I get the other behavior?" and then "but only on some names". Can you see where this is going?

You can think of an infinite set of refinements "Only play sound on the weekends... and do animations during the weekdays.... from 9 to 5... but only if I'm not running a full-screen game..." There is just no way to think of all the possible things people want to do.

And some people think the sounds aren't at all important, that the font sizes are important; others think keyboard and mouse bindings are important. Everyone wants something else. The power of tkbiff's approach is to let users have freedom rather than trying to guess in advance what they might want to change. And with this freedom comes complete knowledge - so they no longer have to guess why it works the way it does or if it can be made to work differently.

Lest you think I've forgotten your original observation, yes, I agree a person could feel overwhelmed. But that will pass momentarily if you just give it a chance. The configuration file is structured so that most people need only look at the very beginning of the file. More demanding users will find the configurability they want after that. And for the folks who want total control, the whole thing is there so that any aspect of the GUI can be modified.

Run tkbiff once for each mailbox to be monitored. On UNIX, just add an -mbox flag to identify the particular mailbox. On MacOS, create a tiny file that says:

  set mbox "fromSusie"
  source tkbiff

... and then turn that into a clickable icon in the usual way and name it after your mailbox. On Windows, you can take either approach.

There are lots of other possibilities. For example, you could have the script prompt for a mailbox.

This may not seem as graceful as biffs that understand multiple mailboxes directly. However, there's little to be gained by such an arrangement - because there is essentially no relationship between different mailboxes.

> ...
> I think I tend to favor having one window to monitor multiple mailboxes.
> If for no other reason it avoids using so much screen real estate.  Any
> chance of this being added or are you still pretty much in favor of
> starting multiple copies of tkbiff?

Just speaking for myself and the way I use tkbiff, I take quick looks at messages as they come in (or pretty soon after) and then click the appropriate button to make them disappear from the main window. (I also have the tkbiff window itself disappear when there are no messages to show.) So running multiple tkbiffs doesn't consume screen space - since there are almost never any tkbiff windows - unless I'm really not watching the screen in which case it doesn't matter anyway.

Packing a bunch of folders into a single window sounds fine, too. It shouldn't be hard to modify the config file appropriately. I'd use multiple tkbiffs and just have them all write to the same window. Although, it's not obvious to me how you want the multiple mailboxes to actually appear on the screen.

I would like to change the background color and I notice in
the config file that you had tk_bisque for the default one. I tried
putting white and rgb:f/f/f and so on and those did not work. How do I
change what the color is and what might my options be?

You could replace the call to tk_bisque with calls like this:

  tk_setPalette coral
  tk_setPalette #7f3

tk_setPalette adjusts all the widget highlights around that new color. Read the tk_setPalette doc for more info. If you want to choose colors individually, you can do it either through "option" commands (best if you want to affect several types of widgets) or -foreground (and -background and similar flags) to control specific widgets.

To run without the GUI, use tclsh instead of wish to execute tkbiff. Then to customize so that it just count messages, use the following configuration:

	set count 0

	proc announce_new_msgs {} {
	    global count new_list
	    incr count [llength $new_list]
	}
    

This code just maintains the count of course. If you want to print it out or stick it in a window, that's up to you.

Do a little customization to your config file:

Copy the show_msgwin proc and rename it popup (or whatever you like). In popup, Change the 1st arg from y to id and delete the line that computes the id since you'll be passing it in by arg. Also, remove the [info exist show_list] test near the beginning.

In announce_new_msg, add calls to popup (just like the audio play commands). It will look like this:

    ....if {[string match "you have won the lottery!" $subject]} {
	popup $id 0 1
    }

The 0 indicates you don't want extra headers displayed. The 1 leaves it up until you dismiss it with a button click.

configure tries to figure out what kind of machine you are on. Alas, configure sometimes isn't up-to-date on the very latest vendors, machine types, OS versions, etc. If you encounter this problem, try choosing a host type that is similar but more well-known. Here's an actual example - someone was seeing this message:

configuring Tkbiff 3.11.0
checking host system type... Invalid configuration `hppa2.0w-hp-hpux11.00': machine `hppa2.0w-hp' not recognized

He solved it by calling configure with an explicit --host flag.

configure --host=hppa2.0

This worked because configure recognized the more basic host type of hppa2.0 (without the "w").

Thanks to Ullas Gargi (ullas@hplug.hpl.hp.com) for this example.

Your Tcl installation is misconfigured.

For multi-user sites, the best solution is to compile Tcl from the source (rather than copying a Tcl binary as you must've done).

If you don't want to recompile and just want a quick workaround, you need to set your LD_LIBRARY_PATH (or equiv) to reflect where Tcl's .so file is. If this doesn't mean anything to you, LD_LIBRARY_PATH is an environment variable, usually set with a command like setenv in one of your login scripts. The variable should contain the name of the directory (such as /usr/lib or /usr/local/lib that contains libtclXXX.so where XXX is the version number in the error message).

When tkbiff tries to play an audio, it says:

tkbiff_audio: error at line 19: `\}' unexpected
child process exited abnormally

Your system is treating the tkbiff_audio script as a shell script, probably because the 1st line is invalid. That line should look like:

#!XXX

Another program may have turned off the speaker or headphones or whatever interface to which you're listening. Obviously, tkbiff cannot guess which one that might be, so it assumes you are controlling that yourself.

To check the status of where sound is going, run audiocontrol and then, for example, if you want sound to come out of the speakers, click on Speaker.

Sounds like a mismatch between the tkbiff and your personal config file possibly because your config file is just so old that the interfaces have changed enough. Try moving your config aside, then rerun tkbiff and it will automatically recreate a new config file.