Misc other settings

Help index


Shadows under popup views

This disables the shadows under popup views in some view styles.
On slow display stations (x terminals), popup menus may appear quicker with disabled shadows.

Boxes return focus

Depending on which window manager you use, this may be required to avoid the annoying loss of keyboard focus after a dialog is closed. (It is known to happen with the OpenLook window manager.)
If the return-focus feature is enabled, ST/X will return the keyboard focus to the view which was active before the dialog opened (i.e. the view which opened the dialog).
Most window managers return the focus to the pointer window - on those, this should (can) be disabled.

Take focus when mapped

Depending on which window manager you use, this may be required to avoid the annoying need for a click on an opened window, to have the keyboard focus assigned to it (OpenLook and some motif window managers).
If the take-focus feature is enabled, ST/X will fetch the keyboard focus and assign it to the newly opened topWindow.
Most window managers assign the focus to the view under the mouse pointer - on those, this should (can) be disabled.

Hostname in window labels

If enabled, the machines hostname will be prepended to all window labels.
This makes sense if you have multiple ST/X sessions from different machines open simultaneously on the same display screen (and you loose track of which view belongs to which session).

Accelerators in menus

Turns on/off the display of an items accelerator key (if any) in menus. Only useful if you know the accelerators well, and dont like the menus being a bit wider due to the extra text.

Raise & Activate on click

If enabled, clicking in a window (with the left button) will raise its topView (as under Windows-95 & Windows-NT).
If disabled, a click does not automatically raise the topView (as in the XWindow system).

Notice, that under X, the window manager may have been set up to perform this operation - on those systems, ST/X will have no chance to prevent auto-raise.

Notice, that raise-on-click combined with focus-follows-mouse (see below) does not really make sense.

Focus follows mouse

If on, the keyboard focus follow the mouse - i.e. you can type into to another inputField or textWindow after moving the mouse pointer. This is the X-Window Systems traditional way of focus handling.

If off, you have to click into a view in order to attach the keyboard focus to it. This is the MS-Windows way of focus handling.

This flag only affects focus handling within a topWindow - focus assignment between topWindows is usually not under control of stx (instead, its typically done by the window manager).

Also notice, that the keyboard focus NEVER follows the mouse pointer, if it got assigned to some widget by tabbing.
A widget which got the focus via tabbing will only give away the keyboard focus, if its either explicitely tabbed to another view, or if you click into another view (which takes the focus with button-press, such as a textView).

The default behavior setting depends on the view style.

Notice, that focus-follows-mouse combined with raise-on-click (see above) does not really make sense.

Opaque Variable Panel resize

If enabled, a movement of a variablePanels resize bar will immediately change the size ratio - leading to a synchronous resize operation. If disabled, resizing takes place when the handle is released.
You should only enable this if your machine and graphics system is fast.


Preemptive scheduling

Controls if the processorScheduler should schedule using a pure priority based scheme (if off), or timeslice among the highest priority running processes (if on).
Without preemptive scheduling, a busy view (for example, a workspace or application) may block other views - with preemptive scheduling, these are interrupted and the processor time is timesliced among all threads running at that priority.

Although the ST/X class library itself is generally thread-safe, existing user classes (PD-classes) are often not so.
The reason is that other smalltalk systems do not in general offer a timeslicing capability - which means that those programs are usually not prepared for being interrupted at any time by another thread running at the same priority.
Therefore, certain dangers are involved, if timeslicing is enabled; if you encounter any synchronization problems, or corrupted shared data in your applications, it may be preferable, to disable this feature (and save the settings).
(Please read the documentation in ProcessorScheduler>>scheduling for more details).

More info is found in the 'Adding round-robin' chapter of the programming manual.

Dynamic priorities

If enabled, the preemptive scheduler will shuffle priorities of processes with a dynamic priority.
The affects processes with a dynamic priority range, and the effect is that those processes which want to run, but did not get the CPU for some time, will get their priority raised, while those which did run, get their priority lowered.
Thus it is possible to give even low priority background processes a chance to make some progress.

A processes dynamic priority is set by sending the #priorityRange: message to a process, passing an interval as argument. This interval defines the minimum and maximum priority of the process.

This requires that your applications are well designed with respect to shared data access (i.e. shared collections), since now, even a low priority process can eventually interrupt a higher priority process and get a chance to execute.
However, only processes with a priority range are affected - thus, unchanged existing applications are not affected by this. (the program must enable this via the #priorityRange: message, which must be sent to the process object.)

More info is found in the 'Dynamic priorities' chapter of the programming manual.


Copyright © 1997 Claus Gittinger eXept Software AG, all rights reserved


Doc $Revision: 1.29 $ $Date: 1999/06/25 20:10:31 $