# jinit.tcl

## Introduction

The jinit.tcl library is distributed as part of the jstools package. It consists of a procedure, `j:jstools_init`, that reads user preferences and initialises data used by the jstools libraries. Any application that uses the jstools libraries should either call `j:jstools_init` early on, or duplicate its functionality.

This document describes jinit.tcl version 4.0/4.0.

## Usage

### Accessing the Library

In order to use the jinit.tcl library, it (and any other libraries it depends on) must be in your Tcl `auto_path`, described in `tclvars`(n). Information about how to arrange that, and other conventions common to the jstools libraries, is in the Usage section of The jstools Libraries.

###

## Credits and Copyright

### Author

Jay Sekora

`js@calumet.org`

`http://shore.net/~js/`

### Copyright

The library is copyright © 1992-1995 by Jay Sekora, but may be freely redistributed under the conditions at the top of the file.

## Overview

### Procedure

`j:jstools_init` - common initialisation for jstools applications and libraries

## j:jstools_init

### Usage

`j:jstools_init` [app]

### Argument

app - name of the current application

### Description

This procedure performs common setup tasks for the jstools applications and other applications using the jstools libraries. Specifically, it does the following:

* It sets the Tk colormodel to colour if possible (even on displays with only a few colours). The Tk default is to use monochrome if the display supports sixteen colours or fewer, but many displays with as few as four colours have no trouble displaying Tk's 3D effects, so the jstools applications use colour if possible.

* It sets `NAME` and `HOME` global variables with the values of the corresponding environment variables.

* It sets the application's `client' and `command' properties for the use of X session managers.

* It reads in the user's global preferences. This is important, as many of the jstools libraries depend on the existence of variables created during this process.

* It tries to load the user's preferred language database for presentation of strings by library routines.

* If app was specified, it also tries to load an applicationspecific language database for presentation of strings used by the application.

* It sets up Text and Entry bindings to use the user's preferred editor emulation, and reads the user's ~/.tk/textbindings.tcl and ~/.tk/entrybindings.tcl, if any.

If you don't want to use `j:jstools_init` because there's something it does that you don't like, you should refer to the procedure itself to see what you need to do to initialise your application.

## Bugs and Limitations

* Some applications may not use text widgets, entry widgets, or both. Initialising text and entry mappings is a waste of time and I/O in that case. (On the other hand, any application which uses such jstools procedures as `j:fs` or `j:prompt_tcl` needs entry bindings, and an application which uses `j:more` might need text bindings.)

* While colour works well for displays with small numbers of shades of grey, it may not work well for all displays with small numbers of actual distinct hues. Ideally, whether to use colour or monochrome would be decided based on the kind of display (e.g. StaticGray vs. DirectColor) as well as on the number of colours, or perhaps it would be a user preference.

* It would be nice if`j:jstools_init` could handle setting up the `auto_path` variable to find the libraries. Since it is itself called using the autoloading mechanism, of course, it can't.

``