Misc other settings
Gui Related Settings
Process Related Settings
(Win32 only) If on, native widgets are used.
Currently, this is in an experimental stage and only used for Scrollbars and Buttons.
(Win32 only) If on, native dialogs are used.
Currently, this is in an experimental stage and only used for Warning, Information and
File-Selection dialogs.
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 (and you will still see a shadow
under the menu).
Enable/Disable acoustic signals alltogether.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.31 $ $Date: 2009/09/21 13:52:21 $