[opensuse] 11.4 - xterm background went from dark to white after latest updates - how to fix?
Guys, My xterm background in kde3 has always been a pleasing dark color from my background color setting in either kde3 or gnome. For some reason, after updates this past week, my xterm background had changed to white? I didn't do anything to the box or reset anything, so where do I look to set the xterm color back to dark? Which setting controls this? Thanks. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* David C. Rankin
My xterm background in kde3 has always been a pleasing dark color from my background color setting in either kde3 or gnome. For some reason, after updates this past week, my xterm background had changed to white? I didn't do anything to the box or reset anything, so where do I look to set the xterm color back to dark? Which setting controls this? Thanks.
peek at the script, /usr/bin/colorize-xterm included in shtools hint: xtermset -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/05/2012 10:12 AM, Patrick Shanahan wrote:
peek at the script, /usr/bin/colorize-xterm included in shtools
hint: xtermset
Hmm... 14:24 alchemy:~> ls -al /usr/bin/colorize-xterm ls: cannot access /usr/bin/colorize-xterm: No such file or directory 14:24 alchemy:~> rpm -q shtools package shtools is not installed Mystery deepens, been a nice dark-dark gray without colorize-xterm since 11.4 install - how in the heck did it do that? I have a suspicion. I'll try changing kde-gtk and then changing back. I've had a couple of setting that have come 'unset' in the past week. Thanks Patrick. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* David C. Rankin
On 04/05/2012 10:12 AM, Patrick Shanahan wrote:
peek at the script, /usr/bin/colorize-xterm included in shtools
hint: xtermset
14:24 alchemy:~> ls -al /usr/bin/colorize-xterm ls: cannot access /usr/bin/colorize-xterm: No such file or directory 14:24 alchemy:~> rpm -q shtools package shtools is not installed
Mystery deepens, been a nice dark-dark gray without colorize-xterm since 11.4 install - how in the heck did it do that? I have a suspicion. I'll try changing kde-gtk and then changing back. I've had a couple of setting that have come 'unset' in the past week.
install/use xtermset and/?? install shtools -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-04-05 22:06, Patrick Shanahan wrote:
* David C. Rankin <> [04-05-12 15:29]:
On 04/05/2012 10:12 AM, Patrick Shanahan wrote:
install/use xtermset and/?? install shtools
But this should not be necessary. It changed without using that. My xterms have a light creme background colour, it has not changed. But I don't run kde. - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk99/LoACgkQIvFNjefEBxo2qgCaA7GiVjc06bZUvo4w7g2D5RLA mPcAn1sfKtbGdrY8M7uUW73gbYhCCmtj =tLk3 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/05/2012 03:12 PM, Carlos E. R. wrote:
On 2012-04-05 22:06, Patrick Shanahan wrote:
* David C. Rankin <> [04-05-12 15:29]:
On 04/05/2012 10:12 AM, Patrick Shanahan wrote:
install/use xtermset and/?? install shtools
But this should not be necessary. It changed without using that.
My xterms have a light creme background colour, it has not changed. But I don't run kde.
Mine have always had a dark background I think either due to my kde-gtk theme or due to my gtk settings (don't know why or which one..). Regardless, after a zupper up and X restart, the dark background is back just as it should be: [17k] http://www.3111skyline.com/dl/suse/11.4/kde3/xterm-dark-bg.jpg - -- David C. Rankin, J.D.,P.E. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+Itc4ACgkQZMpuZ8Cyrcip9wCfe3AezF77oO8gb2GyRBqnL8OM r/4AnRp8eRSf7Xa7A5rItgD9Q8dY55A9 =9aaZ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello, On Thu, 05 Apr 2012, David C. Rankin wrote:
My xterm background in kde3 has always been a pleasing dark color from my background color setting in either kde3 or gnome. For some reason, after updates this past week, my xterm background had changed to white? I didn't do anything to the box or reset anything, so where do I look to set the xterm color back to dark? Which setting controls this? Thanks.
The X Ressource Database possibly overridden via commandline. So, let's look what's set: $ xrdb -query | grep -i xterm.*background XTerm*background: black xterm*background: black (can't remember which one's the correct one). Now, where can this come from? In order, with later files overriding earlier: /usr/share/X11/app-defaults/XTerm /usr/share/X11/app-defaults/XTerm-color /etc/X11/Xresources ~/.Xresources ~/.Xdefaults How it's set? The app-defaults file is read by the app automatically (AFAIR). The rest is read by from the xinitrc (now split off into /etc/X11/xinit/xinitrc.common): ==== xdefaults=$HOME/.Xdefaults xresources=$HOME/.Xresources [..] if test -r "$xdefaults" ; then if test -r $XETCDIR/Xresources ; then xrdb -nocpp -load -retain $XETCDIR/Xresources xrdb -I$HOME -merge "$xdefaults" else xrdb -I$HOME -load -retain "$xdefaults" fi if test -r "$xresources" ; then xrdb -I$HOME -merge "$xresources" fi elif test -r "$xresources" ; then if test -r $XETCDIR/Xresources ; then xrdb -nocpp -load -retain $XETCDIR/Xresources xrdb -I$HOME -merge "$xresources" else xrdb -I$HOME -load -retain "$xresources" fi elif test -r $XETCDIR/Xresources ; then xrdb -nocpp -load -retain $XETCDIR/Xresources fi ==== IOW: first, if it exists, /etc/X11/Xresources is read, then if an ~/.Xdefaults exists, that is merged into the xrdb, and if an ~/.Xresources exists that is also merged into the xrdb (I wonder if one could not just -merge all files). HTH, -dnh -- "I can't go on meeting you like this" -- a TeX message -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/07/2012 11:42 AM, David Haller wrote:
Hello,
On Thu, 05 Apr 2012, David C. Rankin wrote:
My xterm background in kde3 has always been a pleasing dark color from my background color setting in either kde3 or gnome. For some reason, after updates this past week, my xterm background had changed to white? I didn't do anything to the box or reset anything, so where do I look to set the xterm color back to dark? Which setting controls this? Thanks.
The X Ressource Database possibly overridden via commandline. So, let's look what's set:
$ xrdb -query | grep -i xterm.*background XTerm*background: black xterm*background: black
(can't remember which one's the correct one). Now, where can this come from? In order, with later files overriding earlier:
Hmm, don't recall ever messing with it, but after updates and reset to the dark background I have: 18:26 alchemy:~> xrdb -query | grep -i xterm.*background xterm*background: #090d14 xterm.SimpleMenu*background: #18191d
/usr/share/X11/app-defaults/XTerm /usr/share/X11/app-defaults/XTerm-color
*SimpleMenu*background: AntiqueWhite *Form.menubar.background: AntiqueWhite *Form.menubar*background: AntiqueWhite *Form.background: AntiqueWhite *form.background: AntiqueWhite This explains the AntiqueWhite
/etc/X11/Xresources
*Form.background: grey67 *TransientShell*Dialog.background: grey67 *Command.background: grey77 *MenuButton.background: grey77 *SimpleMenu*background: grey77 *Scrollbar*background: grey77 None apply? It's not grey67 or 77
~/.Xresources ~/.Xdefaults
None of those files...
How it's set? The app-defaults file is read by the app automatically (AFAIR). The rest is read by from the xinitrc (now split off into /etc/X11/xinit/xinitrc.common):
Hah! Found it: 21:11 alchemy:~/.kde/share> grep -r 090d14 * apps/kthememanager/themes/dcrBlueSlate/dcrBlueSlate.xml: <windowBackground rgb="#090d14" object="global" /> apps/kthememanager/themes/dcrBlueSlate-II/dcrBlueSlate-II.xml: <windowBackground rgb="#090d14" object="global" /> apps/kthememanager/themes/original/original.xml: <windowBackground rgb="#090d14" object="global" /> It is set though the kthememanager. What that doesn't explain is why it just suddenly reverted to white. Only thing I can think of is that ksycoca got corrupted somehow and then was rebuilt on kde restart. Thanks dnh for providing the trial to follow. Good to know where it is set now. Give #090d14 a try for background -- it's not bad on the eye. Or #06090E (little darker), just adds a little "blue-on-black" :) -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello, On Fri, 13 Apr 2012, David C. Rankin wrote:
On 04/07/2012 11:42 AM, David Haller wrote:
On Thu, 05 Apr 2012, David C. Rankin wrote:
My xterm background in kde3 has always been a pleasing dark color from my background color setting in either kde3 or gnome. For some reason, after updates this past week, my xterm background had changed to white? I didn't do anything to the box or reset anything, so where do I look to set the xterm color back to dark? Which setting controls this? Thanks.
The X Ressource Database possibly overridden via commandline. So, let's look what's set:
$ xrdb -query | grep -i xterm.*background XTerm*background: black xterm*background: black
(can't remember which one's the correct one). Now, where can this come from? In order, with later files overriding earlier:
Hmm, don't recall ever messing with it, but after updates and reset to the dark background I have:
18:26 alchemy:~> xrdb -query | grep -i xterm.*background xterm*background: #090d14 xterm.SimpleMenu*background: #18191d
*hehe*
/usr/share/X11/app-defaults/XTerm /usr/share/X11/app-defaults/XTerm-color
*SimpleMenu*background: AntiqueWhite *Form.menubar.background: AntiqueWhite *Form.menubar*background: AntiqueWhite *Form.background: AntiqueWhite *form.background: AntiqueWhite
This explains the AntiqueWhite
"builtin" defaults of xterm.
/etc/X11/Xresources [..irrelevant in this case..]
~/.Xresources ~/.Xdefaults
None of those files...
You'd have to create those ;)
How it's set? The app-defaults file is read by the app automatically (AFAIR). The rest is read by from the xinitrc (now split off into /etc/X11/xinit/xinitrc.common):
Hah! Found it:
21:11 alchemy:~/.kde/share> grep -r 090d14 * apps/kthememanager/themes/dcrBlueSlate/dcrBlueSlate.xml: <windowBackground rgb="#090d14" object="global" /> apps/kthememanager/themes/dcrBlueSlate-II/dcrBlueSlate-II.xml: <windowBackground rgb="#090d14" object="global" /> apps/kthememanager/themes/original/original.xml: <windowBackground rgb="#090d14" object="global" />
WTFF has a KDE App to mess with xterm ressources? And probably overwriting settings from ~/.Xresources. As I don't use KDE, would you test that by keeping above but adding something different to ~/.Xresources, e.g.: ==== xterm*background: khaki1 xterm*foreground: black ==== If your xterm (we're talking about xterm right? Not the KDE "konsole", or do we?) then does not show up in black on off-yellowish, try printf 'xterm*background: khaki1\nxterm*foreground: black\n' \ | xrdb -merge and open a new xterm after KDE is running.
It is set though the kthememanager. What that doesn't explain is why it just suddenly reverted to white. Only thing I can think of is that ksycoca got corrupted somehow and then was rebuilt on kde restart.
Gah. KDE. 'nuff said. *scnr*
Thanks dnh for providing the trial to follow. Good to know where it is set now. Give #090d14 a try for background -- it's not bad on the eye. Or #06090E (little darker), just adds a little "blue-on-black" :)
Nice, but actually, I do like the real "white on black" ;) $ xrdb -query | grep -i 'xterm.*ground' xterm*background: black xterm*foreground: white (it seems, that XTerm.* is ignored, at least when xterm.* is defined. Have to test that sometime ;) BTW: using xrdb, you can also theme Tk Apps. Even from inside perl[1]. -dnh [1] e.g.: my @resources = ( "MyClass*Foreground: white", "MyClass*Background: grey30", # [..] ); # set defaults from @resources Tk::CmdLine::SetResources(\@resources, 'widgetDefault'); # get cmd line Tk::CmdLine::cget(); # set ressources from cmdline/xrdb, overriding defaults Tk::CmdLine::SetResources(); [..] # read actual used fg/bg into short variables, using defaults if # something went wrong/was unset... $fg = $ui->{mw}->optionGet('Foreground', $class) || "white"; $bg = $ui->{mw}->optionGet('Background', $class) || "grey30"; You can also load resources from a file (and override those from cmdline). Still "barebone", but anyway, having MyClass.Background: khaki1 MyClass.Foreground: black in your ~/.Xresources would override the app-defaults, the Tk-UI I create in a perl-script becomes "themeable" ;) Oh, 'editres' can be a help on finding widgets/classes etc. but it should[tm] be in the manpage. Not sure how to define defaults for Tk (similar to a GTK/Qt Theme), but IIRC there are resources used by Tk by default. -- "Now, _this_ is a house call." -- Janet Frasier, upon stepping out of the Stargate on some distant world -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tuesday 17 Apr 2012 05:19:03 David Haller wrote:
Hah! Found it:
21:11 alchemy:~/.kde/share> grep -r 090d14 * apps/kthememanager/themes/dcrBlueSlate/dcrBlueSlate.xml: <windowBackgrou nd rgb="#090d14" object="global" /> apps/kthememanager/themes/dcrBlueSlate-II/dcrBlueSlate-II.xml: <windowBackground rgb="#090d14" object="global" /> apps/kthememanager/themes/original/original.xml: <windowBackground rgb="#090d14" object="global" />
WTFF has a KDE App to mess with xterm ressources? And probably overwriting settings from ~/.Xresources. As I don't use KDE, would you test that by keeping above but adding something different to ~/.Xresources, e.g.:
It's the 'Apply colours to non-KDE applications' checkbox in the Colours KDE settings module. It's a consistency thing. Will -- Will Stephenson, openSUSE Board, Booster, KDE Developer SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello, On Tue, 17 Apr 2012, Will Stephenson wrote:
On Tuesday 17 Apr 2012 05:19:03 David Haller wrote:
Hah! Found it:
21:11 alchemy:~/.kde/share> grep -r 090d14 * apps/kthememanager/themes/dcrBlueSlate/dcrBlueSlate.xml: <windowBackgrou nd rgb="#090d14" object="global" /> apps/kthememanager/themes/dcrBlueSlate-II/dcrBlueSlate-II.xml: <windowBackground rgb="#090d14" object="global" /> apps/kthememanager/themes/original/original.xml: <windowBackground rgb="#090d14" object="global" />
WTFF has a KDE App to mess with xterm ressources? And probably overwriting settings from ~/.Xresources. As I don't use KDE, would you test that by keeping above but adding something different to ~/.Xresources, e.g.:
It's the 'Apply colours to non-KDE applications' checkbox in the Colours KDE settings module. It's a consistency thing.
Ah, ok. If it's configurable... BUT(!!!) is that DOCUMENTED??? And is it DOCUMENTED that that setting causes KDE to manipulate the xrdb??? If not, f*ck it, KDE has to keep its dirty fingers off my xrdb! Especially if it overwrites stuff set in ~/.Xresources and/or ~/.Xdefaults. And the default of that setting MUST be "off". IMDNHO. Oh, and consistency? Pah! I spit on colour consistency as long as the rest is inconsistent (e.g. file selection dialogs, both have become useable currently IMHO, ATM, the KDE one sucks more though). And NO, I do not want "consistency" inbetween Gnome/GTK/Qt/KDE. There's enough, um, ah, stuff of questionable benefit coming from freedesktop.org as it is. E.g. all that u{dev,disks,power,...,nameit} stuff. Ok, udev, well...[1] I'm waiting for "uporn" ... ;) Actually, I prefer differing themes between GTK and Qt Apps (and Tk, and Wx and FLTK and Athena and Xaw(3d) and Swing and whatnot). That way, I immediately get a hint what UI I'm working with and what quirks (in e.g. the file selection dialog) I have to work with. For example, I had GTK1 rather nicely tuned to a light-on-blueish-dark theme, and Qt(at least1) to a light-on-violetish-dark. As more and more Apps ignored stuff from my themes though, I sorta gave up when moving to 11.4. I tried light-on-dark themes, but none worked throughout. So now I just use the default or some dark-on-light. As I mostly use xterm + XEmacs (both configured white-on-[almost-]black) + Seamonkey, use bash / mc in an xterm for filemanagement and doing and starting stuff, creating a good light-on-dark GTK or Qt theme to really work for the few apps I (regularly) use for a few minutes would be overkill. YMMV! -dnh, but I may try dcr's themes ;) [1] it does not seem worse than hal. -- CPAN is a medium because anything well done is rare." -- (mis)quoting Fred Allen -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
David Haller wrote:
(it seems, that XTerm.* is ignored, at least when xterm.* is defined. Have to test that sometime ;)
IIRC, XTerm is the class and xterm is the instance. And yes, the instance overrides the class. But it's been a long while so I may not remember correctly ... Cheers, Dave -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (6)
-
Carlos E. R. -
Dave Howorth -
David C. Rankin -
David Haller -
Patrick Shanahan -
Will Stephenson