You are not logged in.
After tonight's full system upgrade, my FvwmIconMan seems to be using the wrong colors. Since I use a black/dark red/red colorscheme, I haven't been able to identify yet whether it is simply ignoring certain colors or if it is somehow addressing the incorrect colorset, but it does appear to at least stick with the three colors I use; they're just misplaced.
Any ideas would be greatly appreciated. The only other change made today before rebooting was that I replaced gcc-libs with gcc-libs-multilib. I reverted this and rebooted and it did not solve the problem. I started to revert xorg-server, but once I realized the introduction of xorg-server-common complicated the issue I decided I would ask first before going through the trouble. Plus I need to go to bed, it's late!
The relevant portions of my .fvwm/config:
CleanupColorsets
Colorset 0 sh #7f0000, hi #7f0000, bg #000000, fg #7f0000
Colorset 1 sh #ff0000, hi #ff0000, bg #000000, fg #7f0000
Colorset 2 sh #ff0000, hi #ff0000, bg #7f0000, fg #ff0000
Colorset 3 bg #ff0000
DefaultColorset 2
...
*FvwmIconMan: Colorset 0
*FvwmIconMan: FocusAndSelectColorset 2
*FvwmIconMan: FocusColorset 2
*FvwmIconMan: IconColorset 0
*FvwmIconMan: PlainColorset 0
*FvwmIconMan: SelectColorset 2What was updated:
[2010-10-03 20:57] starting full system upgrade
[2010-10-03 21:16] upgraded allegro (4.4.1.1-1 -> 4.4.1.1-2)
[2010-10-03 21:16] upgraded autoconf (2.67-1 -> 2.68-1)
[2010-10-03 21:16] upgraded bluez (4.71-1 -> 4.72-1)
[2010-10-03 21:16] upgraded cairo (1.8.10-1 -> 1.10.0-2)
[2010-10-03 21:16] upgraded ed (1.4-3 -> 1.5-1)
[2010-10-03 21:16] upgraded fluidsynth (1.1.1-2 -> 1.1.2-2)
[2010-10-03 21:16] upgraded git (1.7.3-1 -> 1.7.3.1-2)
[2010-10-03 21:16] upgraded hawknl (1.68-1 -> 1.68-2)
[2010-10-03 21:16] upgraded icu (4.4.1-1 -> 4.4.2-1)
[2010-10-03 21:17] upgraded kernel26 (2.6.35.5-1 -> 2.6.35.7-1)
[2010-10-03 21:17] upgraded lib32-cairo (1.8.10-3 -> 1.10.0-3)
[2010-10-03 21:17] upgraded lib32-pango (1.28.1-3 -> 1.28.1-4)
[2010-10-03 21:17] upgraded lib32-gtk2 (2.20.1-4 -> 2.20.1-5)
[2010-10-03 21:17] upgraded libnice (0.0.13-1 -> 0.0.13-2)
[2010-10-03 21:17] upgraded libtool (2.2.10-3 -> 2.4-1)
[2010-10-03 21:17] upgraded man-pages (3.26-1 -> 3.27-1)
[2010-10-03 21:17] upgraded mesa (7.8.2-1 -> 7.8.2-3)
[2010-10-03 21:17] upgraded nss (3.12.7-1 -> 3.12.8-1)
[2010-10-03 21:17] upgraded qt (4.6.3-1 -> 4.7.0-2)
[2010-10-03 21:17] upgraded tzdata (2010l-1 -> 2010m-1)
[2010-10-03 21:17] upgraded vlc (1.1.4-2 -> 1.1.4.1-1)
[2010-10-03 21:17] upgraded wine (1.3.3-2 -> 1.3.4-1)
[2010-10-03 21:17] upgraded xf86-input-evdev (2.4.0-2 -> 2.5.0-1)
[2010-10-03 21:17] upgraded xf86-input-joystick (1.5.0-2 -> 1.5.0-3)
[2010-10-03 21:17] upgraded xf86-input-synaptics (1.2.2-2 -> 1.3.0-1)
[2010-10-03 21:17] upgraded xf86-video-vesa (2.3.0-2 -> 2.3.0-3)
[2010-10-03 21:17] upgraded xkeyboard-config (1.8-1 -> 1.9-1)
[2010-10-03 21:17] installed xorg-server-common (1.9.0-1)
[2010-10-03 21:17] upgraded xorg-server (1.8.1.902-1 -> 1.9.0-1)
[2010-10-03 21:17] upgraded xterm (261-1 -> 262-1)
[2010-10-03 21:18] upgraded xulrunner (1.9.2.10-1 -> 1.9.2.10-2)Offline
After some experimentation, I've determined that the colorsets I set are certainly being used; that is, none of my defined colors are being ignored. I'm fairly certain at this point that FvwmIconMan has simply scrambled its background colors... for instance, I noticed that where should be Colorset 0's "bg" color is in fact Colorset 2's "sh" color, and where should be Colorset 2's "bg" is Colorset 0's "sh." This appears to affect only FvwmIconMan!
I'm at a complete loss as to what was upgraded that could have caused this. Any suggestions are welcome and greatly appreciated!
Offline
After some experimentation, I've determined that the colorsets I set are certainly being used; that is, none of my defined colors are being ignored. I'm fairly certain at this point that FvwmIconMan has simply scrambled its background colors... for instance, I noticed that where should be Colorset 0's "bg" color is in fact Colorset 2's "sh" color, and where should be Colorset 2's "bg" is Colorset 0's "sh." This appears to affect only FvwmIconMan!
I'm at a complete loss as to what was upgraded that could have caused this. Any suggestions are welcome and greatly appreciated!
Why don't you try being more systematic?
1. Start fvwm with no config:
fvwm -f /dev/null2. Use FvwmConsole to define your colorsets.
3. Check they apply to windows.
4. Try them with a minimal FvwmIconMan config.
5. Check your ~/.xsession-errors log file.
6. Release nothing upstream has changed in FVWM which would have caused this.
7. Assume it's a problem in Archlinux somewhere,
8. Always assume 7. is true, and don't use the pkgbuilds, and compile from CVS directly.
9. If it still fails in the same way, install another distro in VirtualBox.
10. Repeat steps 1 -> 8
11. You tell me....
-- Thomas Adam
Offline
cmtptr wrote:After some experimentation, I've determined that the colorsets I set are certainly being used; that is, none of my defined colors are being ignored. I'm fairly certain at this point that FvwmIconMan has simply scrambled its background colors... for instance, I noticed that where should be Colorset 0's "bg" color is in fact Colorset 2's "sh" color, and where should be Colorset 2's "bg" is Colorset 0's "sh." This appears to affect only FvwmIconMan!
I'm at a complete loss as to what was upgraded that could have caused this. Any suggestions are welcome and greatly appreciated!
Why don't you try being more systematic?
1. Start fvwm with no config:
fvwm -f /dev/null2. Use FvwmConsole to define your colorsets.
3. Check they apply to windows.
4. Try them with a minimal FvwmIconMan config.
5. Check your ~/.xsession-errors log file.
6. Release nothing upstream has changed in FVWM which would have caused this.
7. Assume it's a problem in Archlinux somewhere,
8. Always assume 7. is true, and don't use the pkgbuilds, and compile from CVS directly.
9. If it still fails in the same way, install another distro in VirtualBox.
10. Repeat steps 1 -> 8
11. You tell me....-- Thomas Adam
I felt like I was pretty systematic. I...
1. Identified that neither Fvwm, FvwmIconMan, or my Fvwm config have changed
1. Identified what on the system HAD changed between working and not working
3. Recognized that what did change were updates that I'm not familiar with
4. Assumed it was a problem in Archlinux somewhere
5. Always assume number 4 when it makes sense
6. Posted on the Archlinux forum so that someone more educated with the modules that were upgraded can provide feedback, hopefully giving me a better guided direction than just blindly stabbing in the dark.
Offline
6. Posted on the Archlinux forum so that someone more educated with the modules that were upgraded can provide feedback, hopefully giving me a better guided direction than just blindly stabbing in the dark.
Unfortunately though, that's exactly what you must do -- are you sure there's nothing in your error log. You've not set ParentialRelativity as a style option or anything? You're not running under a compositor?
-- Thomas Adam
Offline
cmtptr wrote:6. Posted on the Archlinux forum so that someone more educated with the modules that were upgraded can provide feedback, hopefully giving me a better guided direction than just blindly stabbing in the dark.
Unfortunately though, that's exactly what you must do -- are you sure there's nothing in your error log. You've not set ParentialRelativity as a style option or anything? You're not running under a compositor?
-- Thomas Adam
I'm don't see any errors in Xorg.0.log, and I don't have a ~/.xsession-errors log file (what generates that?). I don't have ParentialRelativity as a style option, and I'm not running under a compositor. Fvwm is simply started from my .xinitrc file with the line, `exec fvwm`. My .bashrc starts X when I log in from /dev/tty1 with `startx`.
I tried both the latest CVS and using no configuration file, launching FvwmIconMan and configuring it and the colorsets from the Fvwm console, and saw no difference in behavior. I really am pretty certain this is not a problem with Fvwm (unless it's a shared object breakage, but my compiling the CVS head from source would have resolved that)
Offline
ThomasAdam wrote:cmtptr wrote:6. Posted on the Archlinux forum so that someone more educated with the modules that were upgraded can provide feedback, hopefully giving me a better guided direction than just blindly stabbing in the dark.
Unfortunately though, that's exactly what you must do -- are you sure there's nothing in your error log. You've not set ParentialRelativity as a style option or anything? You're not running under a compositor?
-- Thomas Adam
I'm don't see any errors in Xorg.0.log, and I don't have a ~/.xsession-errors log file (what generates that?). I don't have ParentialRelativity as a style option, and I'm not running under a compositor. Fvwm is simply started from my .xinitrc file with the line, `exec fvwm`. My .bashrc starts X when I log in from /dev/tty1 with `startx`.
I tried both the latest CVS and using no configuration file, launching FvwmIconMan and configuring it and the colorsets from the Fvwm console, and saw no difference in behavior. I really am pretty certain this is not a problem with Fvwm (unless it's a shared object breakage, but my compiling the CVS head from source would have resolved that)
I've seen this before, with a broken or missing rgb.txt file which ships along with the XServer -- where the colour definitions live. Although X11 will usually fail to start if it can't find it. I doubt it's that thoguh -- but if you want to widen your search a little, do you get any other oddities with other GUI programs which you didn't get before?
-- Thomas Adam
Offline
cmtptr wrote:ThomasAdam wrote:Unfortunately though, that's exactly what you must do -- are you sure there's nothing in your error log. You've not set ParentialRelativity as a style option or anything? You're not running under a compositor?
-- Thomas Adam
I'm don't see any errors in Xorg.0.log, and I don't have a ~/.xsession-errors log file (what generates that?). I don't have ParentialRelativity as a style option, and I'm not running under a compositor. Fvwm is simply started from my .xinitrc file with the line, `exec fvwm`. My .bashrc starts X when I log in from /dev/tty1 with `startx`.
I tried both the latest CVS and using no configuration file, launching FvwmIconMan and configuring it and the colorsets from the Fvwm console, and saw no difference in behavior. I really am pretty certain this is not a problem with Fvwm (unless it's a shared object breakage, but my compiling the CVS head from source would have resolved that)
I've seen this before, with a broken or missing rgb.txt file which ships along with the XServer -- where the colour definitions live. Although X11 will usually fail to start if it can't find it. I doubt it's that thoguh -- but if you want to widen your search a little, do you get any other oddities with other GUI programs which you didn't get before?
-- Thomas Adam
I don't think that's the problem, although I did notice that I don't have a /usr/lib/X11/rgb.txt. I haven't noticed any graphical errors on other programs (other than this), and it also doesn't seem to affect the Fvwm menu or window decorations, which use the same Colorsets. Also, isn't that file for defining english color names? My Fvwm Colorsets don't use names, they are defined with hex.
Last edited by cmtptr (2010-10-07 23:00:48)
Offline
Oddly I just discovered that I didn't have xrandr on my system... it seems as though I never had xorg-server-utils installed, and it isn't marked as a dependency for anything on my system so it was never brought in by pacman. This didn't solve my problem, but it makes me wonder what else I might be missing, and whether something similar could be the cause of this?
Offline
I still have not found a solution to this problem. I did finally take the time to characterize exactly which colors are wrong. As it turns out, it's not that they're choosing colors from the wrong colorset, but rather that they're selecting colors from other FvwmIconMan colorset values:
configured observed
------------------------------------------------------
FocusAndSelectColorset,bg -> Colorset,sh
FocusColorset,bg -> Colorset,sh
IconColorset,bg -> Colorset,sh
PlainColorset,bg -> FocusAndSelectColorset,sh
SelectColorset,sh -> FocusAndSelectColorset,sh
SelectColorset,hi -> FocusAndSelectColorset,sh
SelectColorset,bg -> SelectColorset,sh
SelectColorset,fg -> FocusAndSelectColorset,fgAny suggestions would be highly appreciated...
Offline
Did you end up figuring this out?
I've had the same problem on 2 Arch PC's and a Fedora 13 one. On a Fedora 12 install though the colours are fine.
I've been putting off looking into it till now expecting it to be not exactly straight forward...would have been nice to be proven wrong.
Cheers for any suggestions.
Offline