Apparently there was a bug in versions up to 1.0pre3 (probably a
memory leak) that caused this behavior. We know that setting your
TextureMaxColors
to something small, like `16 16 16 16' or
`32 32 32 32', will stop this problem. It also seems to happen only
with XFree86 in 32-bpp mode (or 16? Please give me confirmation), and
if you're in 8-bpp or a different X server, it doesn't seem to cause a
problem.
This problem was solved in 1.0pre4, as far as we know. Upgrade!
Sometimes, after I've been running AfterStep for a while in click-to-focus mode, I can't shift the focus from one window to another by clicking. I have to iconify and deiconify the window to shift focus, or pick it from the popup list.
This is a strange bug, that is (sometimes at least) caused by having the NumLock key activated. It is present up to 1.0pre4, so check your NumLock key.
This problem is solved in 1.0pre5.
News: Shade was fixed in 1.0pre4. Upgrade now!
Shade is a window function that is often seen on the Macintosh system. In theory, it makes a window disappear except for the title bar. For example, an Xterm normally looks like this:
|------------------------------|
| Xterm |
|------------------------------|
| |
| |
| |
| |
| |
|------------------------------|
Shade is set by default to take effect when one double clicks on the title bar of the window. When shade takes effect, the Xterm looks like this:
|------------------------------|
| Xterm |
|------------------------------|
This is nice for saving desktop space and for window management purposes. Some prefer it to iconifying the windows.
Up to 1.0pre3, Shade didn't work correctly, because it worked by resizing the window to a height of 0 pixels, which some applications didn't like.
In 1.0pre4 and posterior versions, Shade works by making the application think that it is being iconified, so it works with all applications again. It has the problem, though, that shaded windows become `sticky' and appear in all the pages in the virtual desktop.
This was a bug that occured in AfterStep betas. If you experience this bug, you are running an old release of AfterStep. Upgrade to v1.0pre4 or later to fix this. This is, incidentally, something you should probably do anyway, considering the wealth of features your are missing.
Is a feature introduced in the distribution in 1.0pre4 (it previously
existed as a separate patch) that allows you to associate an action to
an entry in the Wharf corresponding to a swallowed application. So for
example you can have asmail
in the Wharf, and have it
configured so that when you click on it, it warps to your email
reading window. If your email reader is exmh
, the required
lines would be:
*Wharf "asmail" nil Swallow "asmail" asmail &
*Wharf "asmail" nil Warp "-" exmh
Note how both lines have the same label `asmail', which tells Wharf
that those two go together. You can use any AfterStep function instead of
`Warp'. For example, if you want the xload
icon to fire a
top
window when clicked, you can have something like this:
*Wharf "xload" nil Swallow "xload" xload -geometry 48x48-1-1 &
*Wharf "xload" nil Exec "Top" xterm +sb -T Top -n Top -e top &
By the way, this feature is responsible for a strange bug. See question swallow_exec_bug.
This is not a bug, it's a feature :-)
. No, really, this
behavior was introduced due to the introduction of the
`Swallow-exec' capability in 1.0pre4. See question
swallow_exec.
To fix it, do the following:
.steprc
, locate the lines that start with
*Wharf "" ...
nil
, or any other label
that is the same for all the Wharf entries. These repeated labels
are the ones causing the trouble. You have to give each Wharf entry
a unique label there, like `xload', `asmail', `Pager', etc.