Misc other Settings
Gui Related Settings
Additional Gui Related Settings
Process Related Settings
(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).
(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.
(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.
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/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.
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.
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.33 $ $Date: 2011/07/04 09:31:46 $