Misc other settings
- window related settings
- process related settings
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.
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.
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.
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).
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.
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, 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 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.
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.29 $ $Date: 1999/06/25 20:10:31 $