Misc other Settings

Help index

Gui Related Settings

Additional Gui Related Settings

Process Related Settings


Use Native Widgets (Experimental)

(Win32 only) If on, native windows widgets are used. Currently, this is in an experimental stage and only used for Scrollbars and Buttons. The use of native widgets is only useful for certain screen capture programs, which expect a standard widget hierarchy when examining other windows (snagit, for example).

Use Native Dialogs (Experimental)

(Win32 only) If on, native windows dialogs are used. Currently, this is in an experimental stage and only used for some warning-, information- and confirmation-dialogs. The use of native dialogs is only useful for certain remote control applications, which expect standard widgets when examining/controlling other windows.

Use Native File Dialogs (Experimental)

(Win32 only) If on, native windows file dialogs are used. Currently, this is in an experimental stage. Certain limitations are attached to using these dialogs; especially, the redraw-behavior and debuggability of the owning windows is affected in the current version. For example, it is (currently) not possible to interrupt, debug and proceed the application while a native file dialog is active. This is probably only a limitation for developers and might not be relevant to end users.

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.

Under newer Windows versions (XP, Vista, Windows7), the system itself draws a half-transparent shadow underneath a menu, so this setting should be turned off (you will still see a shadow under the menu, as it is drawn by windows itself).

Enable Acoustic Signals

Enable/Disable acoustic signals alltogether.

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 don't like the menus being a bit wider due to the extra text.

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 eventually released.
You should disable this if your machine and/or graphics system are slow.

Opaque Table Column Resize

Similar to the above, this controls if columns of a tableview are resized using a synchronous resize operation. If disabled, resizing takes place when the handle is eventually released.
You should disable this if your machine and/or graphics system are slow.

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.

Mousewheel Focus Follows Mouse

If on, the mousewheel focus follow the mouse - i.e. you can scroll in another window after moving the mouse pointer.

If off, you have to click into a view in order to attach the wheel focus to it.

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.

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.

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.

Select on Right-Button-Press

If on, a right-button press will change the selection if clicked on a list or tree. If off, only the left button is responsible for selection.

Traditionally, in smalltalk and unix workstations, the left button was the select button, and the right button the menu button. With windows, another GUI style appeared, in which both the left and right buttons perform a select operation, and the menu only appears when the right button is released.

Menu on Right-Button-Release

If on, the popUp-menu will be shown when the right-button is released. If off, it appears when pressed.

Traditionally, in smalltalk and unix workstations, the left button was the select button, and the right button the menu button (both operating on press). With windows, another GUI style appeared, in which both the left and right buttons perform a select operation, and the menu only appears when the right button is released.

Window Label Format

Defines the format used for window labels (title in the window decoration). This is especially useful, if you have multiple smalltalk images running side by side from different working directories and/or from different remote machines (via remote X11 connections, for example). Avoid getting confused on which window belongs to which application by adding the top-directory or the remote machine name to all of that application's window labels.
This setting replaces the previous "Hostname in window labels" option.

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.33 $ $Date: 2011/07/04 09:31:46 $