home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
IRIX 6.2 Applications 1996 August
/
Silicon_Graphics_812-0542-002.iso
/
relnotes
/
4Dwm
/
ch5.z
/
ch5
Wrap
Text File
|
1996-08-03
|
12KB
|
331 lines
- 1 -
5. _K_n_o_w_n__P_r_o_b_l_e_m_s__a_n_d__W_o_r_k_a_r_o_u_n_d_s
This chapter lists the known problems with this release of
4Dwm and, where known, ways to work around them.
+o If 4Dwm receives a signal it cannot catch (for example,
_k_i_l_l_a_l_l _4_D_w_m) you might be unable to type in any
windows. This is because the windows are unable to get
focus. If this happens, you need to start a window
manager. There are several ways you might be able to
start one:
- Start one over the network.
- Cut and paste 4Dwm and a new line into a terminal
emulator.
Once a window manager is started, you can exit it
cleanly and start the window manager of your choice.
To exit 4Dwm cleanly:
- Use tttteeeellllllllwwwwmmmm qqqquuuuiiiitttt from a terminal emulator window.
or
- Send 4Dwm a signal it can catch (for example, _k_i_l_l
<_p_i_d>).
+o When invoking _f._e_x_e_c commands, 4Dwm uses the MWMSHELL
environment variable if it is set, otherwise the value
of the SHELL environment variable if it is set,
otherwise /bin/sh. These must be valid command shells
for the _f._e_x_e_c to work. _f._e_x_e_c command failure might
not be obvious. The _f._e_x_e_c command is most efficient
when MWMSHELL is set to /bin/sh.
+o Certain client programs have chosen not to use the
``Close'' function. Double-clicking on their window
menu buttons will not close their windows. These client
programs can be identified by the lack of ``Close'' in
their menu.
+o Occasionally, when moving between two windows using
non-default colormaps, there is some brief colormap
flashing. The correct colormap is normally installed.
+o On occasion a 4Dwm menu will not be able to get the X
grabs it needs to function. The result is a 4Dwm menu
that stays posted and does not respond to the pointer.
Pressing the Esc key will usually remedy the situation.
- 2 -
+o If more icons need to be displayed than can fit in the
icon tiling region, ``holes'' may appear in the tiling
region (places where you cannot place an icon, even
though you could before). The workaround is to reduce
the number of icons needed and restart 4Dwm.
+o Sometimes the iconbox does not display a scroll bar to
allow access to all the available icons. To work
around this problem, resize the iconbox or use the Pack
Icons entry on the iconbox menu.
+o 4Dwm may print an error message when icon image files
are not found or are not valid image files. This may
happen in an unusual way if the client's class starts
with a '/'. Client or class names should not begin
with a '/' for the 4Dwm icon search to work properly.
+o Some applications have a problem detecting double-
clicks when 4Dwm has a button binding active in the
window context. By default, 4Dwm does not have such a
button binding (except for on Meta<Btn3Down>). This
may happen with the Desks Overview (ov), interfering
with switching desks.
+o Windows may receive a stray Button Up event as a result
of the user double-clicking on the system button of the
window above it (when it succeeds in closing the
window).
+o Sometimes additions to the keyBindings in the .4Dwmrc
file will cause the keyboard focus to not be set to any
window. If this happens use the pointer to pop up a
4Dwm menu (or move or resize a window if the
rubberbands are displayed in the overlay planes).
+o With pointer focus mode, some applications that use
modal dialogs may lose input focus. If this happens,
move the pointer out of the application window.
+o Session management attempts to launch applications that
provide a WM_COMMAND property on their windows. There
are many reasons why the WM_COMMAND alone is not
sufficient information to successfully launch an
application.
+o The session management and desks code work together to
try to determine which window should appear at what
location and size and in which desk. This
determination is based on the WM_CLASS and WM_COMMAND
properties of the window, so 4Dwm may not be able to
distinguish between different windows, especially if
- 3 -
these windows lack the WM_CLASS and WM_COMMAND
properties.
+o Desks remembers the state and geometry of your window
in your various desks. Session management tries to
launch the applications that correspond to the windows.
If session management can not launch an application,
desks may still remember the configuration of that
window. Launching the application by hand may cause
the windows to appear in the state that desks
remembered them.
+o Deleting a desk does not cause the windows that appear
in that desk to go away (close or quit) or the
application to quit running. If the windows do not
appear in any remaining desk, access the windows from
the Desks Overview (ov) Window->List All... menu
selection or the Windows Overview (iconbox) if it is
present.
+o Sometimes the $HOME/.desktop-<hostname>/4Dwm* files are
corrupted on shutdown/reboot or if the power is turned
off. If 4Dwm is running with continuous session
management, it is recommended that you either use the
toolchest System->"System Shutdown" entry or quit 4Dwm
before the shutdown/reboot. Quitting 4Dwm can be done
by issuing the command tttteeeellllllllwwwwmmmm qqqquuuuiiiitttt from a terminal
emulator window.
+o The $HOME/.desktop-<hostname>/4Dwm* files are meant to
be written only by 4Dwm. Hand editing these files will
result in undefined behavior.
+o If you choose to run multiple instances of 4Dwm, be
aware that they will overwrite each other's
$HOME/.desktop-<hostname>/4Dwm* files. The resulting
desks and session management behavior is undefined.
With careful attention to turning off session
management (SG_manageSession: false) or to setting
session management to the explicit (SG_autoSave: false)
mode, it is possible to use the window management
functions of 4Dwm.
+o This version of 4Dwm has some problems with multi-
headed systems. One is the situation given above:
multiple instances of 4Dwm overwriting each other's
files if you choose to run separate instances of 4Dwm
on each head. Another problem occurs when _f_m is
running: the dynamic root menu may be incorrect
(usually on the head on which _f_m is not running).
- 4 -
+o 4Dwm has not kept up with the increasing number of
visuals available on some systems. It may not work
properly with some visuals, especially on multi-headed
systems.
+o Occasionally there seems to be an interaction between
the Desks Overview (ov) window and 4Dwm that appears as
a constant resizing of the ov window. Manually
resizing or closing the ov window should stop this
behavior.
+o There is an interaction between ov and 4Dwm when the
"Global" desk is the current desk which causes new
windows to be mapped at location 0,0.
+o Since 4Dwm session mangement tries to launch
applications, if you have your own $HOME/.sgisession or
$HOME/.xsession file that launches the same
applications as 4Dwm launches, you may start multiple
copies of the same application. If SG_manageSession is
set to True, you should remove the launching of
applications that 4Dwm can launch from these files.
+o 4Dwm session management and desks do not always work
well with multi-windowed applications. There is
currently no mechanism in place to relate windows of an
application. Oftentimes not all windows of an
application appear as they were when a session was
saved. Dialogs or other windows that an application
launches may appear in a different desk than the other
windows of the application.
+o Desks does not understand about maximized windows.
Since windows are quite often resized when switching
desks, the maximized windows usually turn into large
normalized windows upon return to the desk where they
were previously maximized.
+o If an attempt is made to change the background through
a tool other than the background control panel or
_x_s_e_t_r_o_o_t, a warning will be given. If file manager
icons on the background are enabled, the warning will
always be given. If they are disabled, the warning
will be given only the first time this occurs.
+o Backgrounds are cached for all desks. If a user has
many desks, each using many colors, the colors can fill
up the colormap. Similarly, if many desks each have
large background pixmaps, much server memory may be
used.
- 5 -
+o Menus and feedback windows appear by default in the
popup planes (if available). These windows share a
colormap in the popup planes, so if a color change is
desired for one of the windows it must be made for all
of them. There are only three colors available in the
popup colormap, so more than one attempt may need to be
made to find colors that work together. Sometimes when
too many colors are needed, the ones that can't be
allocated appear transparent.
+o 4Dwm is meant to be run with schemes enabled. If
schemes is disabled, it is likely that there will be
transparent pixels in 4Dwm's windows in the overlay
planes. If this happens, either explicitly set the
colors (such as 4Dwm*foreground: black) to some color
that is already appearing in the 4Dwm window (or if it
is the menus, another option is to remove the menus
from the overlay planes (4Dwm*SG_visualType: normal) if
you don't mind the additional exposes it will cause
when you pop up a 4Dwm menu or feedback window).