back

Configuration & Customization/X

Index

Views automatically opened on startup

At startup time, Smalltalk/X reads (smalltalk expressions from) a file called "smalltalk.rc.
This file is responsible for setting up the system and starting application views for the user. The default "smalltalk.rc" file opens a Launcher and a Transcript .

You can add additional expressions to start any other view automatically; for example, if you like a System Browser to come up automatically, add a line such as:

    SystemBrowser open.
    !
somewhere at the end of this file.

In previous versions, all setup was done in this single startup file; however, for easier customization, all display specific startup has been extracted into a file called "display.rc and all host specific things are now found in "host.rc. Finally, a file called "private.rc" is read. This allows use of global startup files combined with per user private additional definitions. If you installed "smalltalk.rc" in a standard place, the changes made there will affect all ST/X users. Therefore, it is wise to add these private things to either a local "smalltalk.rc" or to your local "private.rc". (see installation).

Notice:

these files consists of smalltalk expressions in fileOut format - this means, that expressions have to be separated by period (.) characters. Also, groups of expressions (so called chunks) have to be separated by an exclamation mark (!) character.
Exclamation marks within such a chunk (also in strings or comments) have to be escaped by doubling them.

Keyboard mappings

In Smalltalk/X, all keyboard events are translated by a so called keyboardMap before passing them to the application program. This is done in the class which does all the display interfacing
(for the curious: it is done in DeviceWorkstation>>translateKey:).

Since keyboards are very display (-hardware) specific, different mappings are required for different workstation types. Therefore, the "display.rc" file tries to find out the type of display the system is running on (using the displays name) and dispatches to one of the "d_xxx.rc" files.
Both files manipulate the keyboardMap:

To create your own "d_xxx.rc" file, take any existing as a template and copy it to "d_displayname.rc". For example, if your display is marvin:0, you have to call your file "d_marvin.rc". (use echo $DISPLAY to find out what the display name is). If $DISPLAY is something like ":0", ":0.0" or "local:0", you should take your hostname instead.

In general, the keyboardMap is modified using expressions like:

    |map|

    map := Display keyboardMap.
    map bindValue:$[ to:#Alt8.
    map bindValue:#Find to:#Cmds.
    ...
    !
each "bindValue:mappedKey to:originalKey" adds a mapping to use mappedKey instead, whenever originalKey is pressed.
MappedKey can be a character or a symbolic functionKey name.
OriginalKey can be a character, or a symbolic raw key name. Keyboard modifiers (i.e. Alt, Cmd or Ctrl are included in the raw name, meaning that pressing the Alt-key together with the a alpha key will create an event Alta. If shift is pressed in addition, you will get AltA.
Take the expressions found in existing files as a template. If you are not certain, what the names of the raw keys are (i.e. what to use after to:), open an EventMonitor, which traces events and prints them on the standard output (give it some input and see).

national characters

The encoding of characters used internally is iso8859 by default. (although other encodings are possible, no support is currently being built in - for example, all text editing classes only handle 8 bit characters in this encoding.)
There is some rudimentary support for 16bit strings (the TwoByteString class) and drawing of 16bit strings is supported (in GraphicContexts) but currently, neither input nor editing facilities exist for these. This will change in future versions.

keyboard commands

All keyboard commands (also called accelerators) are internally handled as symbolic keys. For example, the search-forward command is performed whenever the #FindNext key event is recognized by a textView class.
The translation from physical key to this symbolic key is done by the keyboard map.
Thus, you need an entry for whatever key should be assigned to the #FindNext function. For example, to put this function on CTRL-F, add a line such as:
    |map|

    map := Display keyboardMap.
    map bindValue:#FindNext   to:#Ctrlf.
to one of your startup file (it is recommended to do so in your 'private.rc' file.

If you add new features to the text editing classes or want to add support for keyboard commands in your own classes, please do so using symbolic keys too. Never hardcode any control or meta sequences into your programs. This allows better use of the system for those lucky people owning many function keys (with keys labelled copy, cut, paste and so on).

The definition of such a translation translation can use combination keys, such as CtrlX, where X stands for the unmodified key - either upper or lower case. Thus, to specify Shift-Ctrl-f, use #CtrlF as second argument to the bindValue:to:. To specify unshifted Ctrl-f, use #Ctrlf.

You can use Control-key (Ctrl) or Command-key (Cmd) modifiers.
You may have to put the keys symbol in quotes; for example to define a mapping for control-underscore, use #'Ctrl_'. (this is pure smalltalk syntax; no magic at all).

On some keyboards, the command key is labelled Meta or Alt.

default keyboard command setup

The default setup is done in the file 'display.rc' and consists of: additional (keyboard specific) bindings are setup in 'd_xxx.rc'. Your personal settings should go into 'private.rc'.

function keys

To put functions on your functions keys (if your keyboard has them), use the same translation mechanism. For example, putting the again function onto the F1 key is done with:
    |map|

    map := Display keyboardMap.
    map bindValue:#Again   to:#F1.

Changing the view style appearance

Smalltalk/X supports very flexible style settings to allow customization of the look of your views.
To change to another style, execute:
	View defaultStyle:#styleName
where styleName is one of
#motif,
#'motif_light',
#'motif_red',
#'motif_blue',
#iris,
#next,
#normal,
#openwin,
#mswindows,
#rocky,
#greenPC.

Notice, that you need quotes around the symbol name for those which include nonalphanumeric characters (i.e. the underline).
Actually, there are more styles available; see below.

You can change the style setting at any time, but it will only affect new views. Existing views keep the style which was in effect when they were created. Therefore, it is best to set the style in one of your startup files - preferrabley in the 'private.rc' or one of the d_xxx.rc'files.

existing stylesheets

For every style, a so called styleSheet exists in the 'resources' directory. For example, the definitions for the motif style are found in 'resources/motif.style'.

Currently, there are styles for:

creating your own stylesheet

You can add your own styles and/or modify existing styles. (better add new ones - since upgrade packages may include new styleSheets. You otherwise had to add your changes again and again.)

StyleSheet files consist of name to value associations, with one entry per line. Lines beginning with a semicolon (;) are ignored and can be used as comments. For example, the foreground color of buttons is defined with:

    buttonForegroundColor    Color red
the first word is the name, everything after the first space or tabulator is evaluated as a smalltalk expression and taken as the value.
You may refer to previous definitions using the special macro =name (i.e. prefix the name to use with the equal (=) character. This allows definitions to be reused.
    myForegroundColor    Color red
    myBackgroundColor    Color yellow
     ...
    buttonForegroundColor   =myForegroundColor
    buttonBackgroundColor   =myBackgroundColor
     ...
    menuForegroundColor     =myForegroundColor
    menuBackgroundColor     =myBackgroundColor
     ...
    shadowColor             =myBackgroundColor darkened

It is possible to add conditional definitions; for example:

    #if Display hasColors
    buttonForegroundColor    Color red
    #else
    buttonForegroundColor    Color grey
    #endif
sets the value to a red color if the display supports colors; otherwise, grey is used.
The text after the #if must be a smalltalk expression returning a boolean value. Conditional expression may be nested.

StyleSheet files can include definitions from other files. Therefore, the easiest way to modifify styles is to create a new file (say 'foo.style') and include an existing one. Then add lines for those values which you like to have changed. Since styleSheets are read from top-to-bottom, later definitions will overwrite previous ones.
For example, a style based on the motif style, but with changed highlightcolor in menus is as simple as:

    ; this is a comment
    ;
    ; first, read motif style
    ;
    #include 'motif.style'

    ;
    ; the redefine highlightBackgroundColor of menus
    ;
    menuHighlightBackgroundColor    Color red
Have a look at existing styleSheets and the file 'generic.style' to get a feeling for what can be redefined and how it is done.

Color allocation strategy

On systems where a limited number of colors is displayed from a palette (i.e. 8bit PseudoColor Displays), the system may run out of available colors if too many of them are to be displayed simultanously. This can happen if (many) color bitmaps are displayed.

Smalltalk/X offers two color allocation schemes:

With the first strategy (which is the default), colors will be allocated as required until the display runs out of available colors. If Images are displayed and no more colors are available, the nearest colors will be used for all following requests. This may result in poor image display in some situations. For example, if two images are displayed, where the first allocated many slightly different red-toned colors, and there are no reasonable green colors left for the second image. In this case, the first image will look great, while the second image will look very ugly.
Also, this may take away required colors from other (non Smalltalk) applications.

With the second strategy, Smalltalk/X preallocates a number of colors right at startup time. These are equally distributed over the whole range of colors (i.e. the color cube). Later requests are satisfied using only these colors for image display (by taking the nearest and/or dither).
This will result in less of a display quality for the average image, but avoid the worst case, since there will always be 'nearby'-colors available with an acceptable error. Thus, the above two images can both be displayed with some less than perfect, but still usable quality.
Also, the total number of colors used can be controlled, leaving colors for other applications.

To enable the second strategy, add a line as:

	Color getColors6x6x4.
to your 'private.rc' file. The above will preallocate 6x6x4 colors from the color cube at startup time (i.e. 6 grades of red and green, 4 grades of blue; for a total of 144 colors). On an 8bit display, this will leave 112 colors for other applications.

Beside the 6x6x4 color cube, other combinations are possible and supported (see the getColors* methods in Colors class protocol)

Host specific setup

Host specific setup consists mainly of printer setup - read and understand the contents of 'host.rc'. Other host specific stuff includes the NNTPServer definition (for the newsReader). There may be more in the future.

printer setup

Smalltalk/X supports various printers - but currently, only for text printing (graphic printing for Postscript printers only).

Printers supported are:

For each printer type, a corresponding class exists. To define the printer, bind that class to the global variable Printer in your 'h_xxx.rc file.
Have a look at the existing 'h_xxx' files for more details.

Graphic printing on postscript printers is done using the public domain PSGraphicsContext package (from the manchester goodies).
The sources are found in the directory 'goodies/postscript'. These classes are not compiled in or loaded by default. You have to either manually load them, or add autoload definitions to the 'patches' file (see below).

However, this package is currently not fully functional - especially font handling is broken. Fixes are being prepared and will be included in the next release.

Other configuration settings

Most of the things described below are already reasonably configured. So normally, you dont have to care for these.

Autoloaded classes

Smalltalk/X supports autoloading of classes. This is done by installing a stub class initially, which will fileIn the real class whenever first used. Many demo and game applications are installed this way.
This means that all these demo classes do not eat up lots of memory space, but will come up slower (due to the compilation) when started the first time.
After the initial load, these should behave just like any other class.

Autoloaded classes are installed during early startup in the 'patches' script. You may want to add your own classes to the lists there.

To make sure, that the system will find your classes source afterwards, it must be found in the source directory. Your system as delivered will contain symbolic links to all existing sourcefiles in this directory.

Since no methods (and therefore no source information) is present before such a class is actually loaded, the SystemBrowser has no way to show any category or source information. You can force a class to be loaded by evaluating the expression:

	className autoload

Lazy loading

By default, autoloaded classes are loaded lazy; this means that the compiler does not compile the classes methods, but instead installs empty method stubs. These are unexecutable methods which are compiled when first executed.
Lazy loading results in somewhat faster startup of these classes (since no compilation is done), but leads to short delays later when executed.
Also, for classes consisting of many methods, only those that are actually called will be fully installed - resulting in somewhat smaller storage requirements.

(you may notice this short compilation delay, when playing with the DrawTool.
try to move an object and notice a short delay when doing so the very first time. After that, no more delays are noticed).

Lazy loading is enabled by a line:

    Autoload compileLazy:true.
in the "smalltalk.rc" file.
Remove this line or add "Autoload compileLazy:false" to your "private.rc" file, if you dont like this feature.

Compiler switches

By default, the Smalltalk/X incremental compiler is configured to output warnings when non standard (i.e. ST/X only) language constructs are used. This can be turned off by adding a line such as:
	Compiler warnSTXSpecials:false
to your 'private.rc' or 'smalltalk.rc' file.
(Of course, you can also evaluate this expression in a workspace at any time later).

If you dont like warnings at all, turn them off completely with:

	Compiler warnings:false

Up to ST-80 vsn 4, underscores where not allowed in identifiers. In new systems, underscores are accepted. If you want to fileIn code from PP's OVST vsn 2 or later, use:

	Compiler allowUnderscoreInIdentifier:true 
With the above, the compiler will still produce warnings if an underscore is encountered in an identifier. These can be turned off with:
	Compiler warnUnderscoreInIdentifier:false 

Logging doIt execution

All of your changes are normally logged in a file called "changes" in your current working directory (see using the ChangesBrowser).
However, to avoid having the changeFile growing too fast, expressions evaluated by doIt, printIt and are not logged by default.
You can turn on logging of them by adding:
	Smalltalk logDoits:true 
to one of your startup files (or by evaluating it in a workspace).

Changing Transcripts buffer size

By default, the Transcript keeps the most recent 300 lines. The number of remembered lines can be changed by:
	Transcript lineLimit:numberOfLines
Notice, that you cannot add this line to "private.rc", since at the time this file is read, the Transcript is not yet open. You have to add it in "smalltalk.rc" after the 'TextCollector newTranscript' line.

Copyright © Claus Gittinger Development & Consulting, all rights reserved

(cg@ssw.de)