Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 1604 - wmconfig has hardcoded -fg and -bg colors for xterms
wmconfig has hardcoded -fg and -bg colors for xterms
Product: Red Hat Linux
Classification: Retired
Component: AfterStep (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Cristian Gafton
Depends On:
  Show dependency treegraph
Reported: 1999-03-18 12:00 EST by tpoindex
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 1999-04-09 17:29:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description tpoindex 1999-03-18 12:00:18 EST
I believe this is a wmconfig setting somewhere; perhaps it's
really an afterstep problem.

When starting X with normal 'startx', wmconfig runs,
selecting 'afterstep' (in my case.)  The afterstep
configuration in
always is created with xterm & nxterm using -bg black and
-fg peachpuff, thus overriding my preferences in
~/.Xdefaults.  I don't care for that particular color
combination, and I consider it a bug that wmconfig (or
afterstep) continually overrides my preferences.

I've tried to eliminate all hard coded values in various
config files for wmconfig and afterstep, but can't seem to
get rid of the -bg and -fg values.

Tom Poindexter
Comment 1 David Lawrence 1999-03-21 17:26:59 EST
Thank you for the suggestion. It has been assigned to a developer for
Comment 2 Mike Maher 1999-03-22 18:48:59 EST
This is an afterstep request.
Comment 3 Michael K. Johnson 1999-04-09 17:29:59 EDT
AfterStep seems to do this kind of thing for every application.
It appears to be a style decision on their part and we'd get as
much flack for changing it as for leaving it alone, and so there
isn't much to be gained from us trying to maintain a patch to
change this behaviour, regardless of our personal opinions of
the appropriateness of this behaviour.

I suggest that you either choose a window manager that is not
configured this way or lobby the AfterStep maintainers to change
their defaults.

Note You need to log in before you can comment on or make changes to this bug.