Bugzilla – Bug 504624
xfig has a gray background under KDE4 compared to white with KDE3
Last modified: 2010-08-26 17:23:46 UTC
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.10) Gecko/2009042700 SUSE/3.0.10-1.1 Firefox/3.0.10 xfig opens normally with a white background when used with KDE3.X. When opened with KDE4.X, the background is gray, which makes it more difficult to work with (for example grid lines are very difficult to see.) I am aware that xfig can be started with the command line option '-cbg white' which does help, but the background color problem is not the only problem I experience (the background issue just seemed the easiest to explain.) There are other issues as well which I am not sure I should add here or open separate bugs for (the background problem just seemed the easiest to describe). For example - the message area (I am not sure what it is called, but it is the small text area just below the menus) is blank (all white) under KDE4 while it is black text on a light yellow background under KDE3. - the area on the right which shows the layers is smaller under KDE4 and some of the layer number gets cutoff. This doesn't occur with KDE3. Reproducible: Always Steps to Reproduce: 1.open xfig under KDE3.x 2.open xfig under KDE4.X Actual Results: xfig appearance (background color plus more) is different under the two window managers. Expected Results: I would expect the appearance to be the same, more or less. xfig-3.2.5-96.1 Problem happens with both opensuse 11.0 and 11.1 and with both i586 and x86-64 versions
I'm not KDE maintainer nor do I use KDE nor GNOME
Does enabling/disabling the checkbox for applying colors to non-KDE applications in KDE's colors configuration module make any difference?
No. Enabling/disabling the checkbox for applying colors to non-KDE applications seems to have no effect on the behavior.
Where does XFig take its colors from then?
Beside the active Xresources > rpm -ql xfig | grep app-defaults /usr/share/X11/app-defaults/Fig /usr/share/X11/app-defaults/Fig-color that's all.
Good news. I can now get xfig colors to work on a variety of systems 11.0, 11.2, kde 4.3.1, 4.3.3. I created a file .Xdefaults in my home directory (I did not have one originally) which contains only the line Fig*customization: -color and now xfig has the appropriate colors under KDE4. I do not know if it was necessary, but to be sure I restarted the graphics system (init 3 && init 5 && exit as root). So it appears that this particular setting is missing (or actively turned off) when KDE4 is started. (The colors worked fine under KDE3, Icewm, etc. without this .Xdefaults file.) Unfortunately, I do not understand enough about the startup process for X to help track this down further, but I hope this helps.
This remains a KDE problem. Now please run xrdb -symbols | grep -i color xrdb -query | grep customization to see if the KDE desktop manager removes some symbols concerning to the coloring of the screen. The result should be something like xfig/xfig> xrdb -symbols | grep -i color -DCLASS=TrueColor -DCLASS_TrueColor=33 -DCOLOR -DCLASS_TrueColor_24=33 -DCLASS_DirectColor_24=34 -DCLASS_TrueColor_32=35 xfig/xfig> xrdb -query | grep customization *customization: -color depending on the color depth of your screen. The last line should be there because of /etc/X11/Xresources which includes #ifdef COLOR *customization: -color #endif that means if this is missed kdm does *not* run xrdb to load /etc/X11/Xresources which is a bug of KDE. Maybe they even do not use the xdm scripts /etc/X11/xdm/* which would also a bug as this would avoud such problems.
Werner, I do not currently have access to an 11.0 install (I will later today and will report here). I do have access to several 11.2 installs and will report those results. I hope they are useful. I removed .Xdefaults, rebooted and here is the requested information. > xrdb -symbols | grep -i color -DCLASS=TrueColor -DCLASS_TrueColor=33 -DCOLOR -DCLASS_TrueColor_24=33 -DCLASS_DirectColor_24=34 -DCLASS_TrueColor_32=35 > xrdb -query Xcursor.theme: Oxygen_White Xft.hinting: 1 Xft.hintstyle: hintmedium There is no customization in there. With the .Xdefaults file included, followed by a reboot, the first output remains the same. The second one just becomes > xrdb -query Fig*customization: -color Xcursor.theme: Oxygen_White Xft.hinting: 1 Xft.hintstyle: hintmedium As additional information, under 11.2 line 105 of /etc/X11/Xresources contains *customization: -color but is *not* surrounded by the conditional statements you have shown. I report results from 11.0 later today. Please let me know if there is anything else I can provide.
The question is: Why does DKM not use /etc/X11/Xresources as it should. AFAIK coloring is active with xfig if xfig -xrm '*customization: -color' is used.
OK, here is the output from a machine running 11.0 (KDE4.3.1) > xrdb -symbols | grep -i color -DCLASS=TrueColor -DCLASS_TrueColor=33 -DCOLOR -DCLASS_TrueColor_24=33 -DCLASS_DirectColor_24=34 -DCLASS_TrueColor_32=35 > xrdb -query | grep customization Also, you are correct - xfig -xrm '*customization: -color' works.
Still valid in 11.2
Please give xfig from factory aka next openSUSE 11.3 a try ... you'll find this at http://download.opensuse.org/repositories/graphics/ if this version does work for you I'd like to get feedback on this bugzilla entry, thank you.
Publishing for xfig in the above repository is disabled, is this intended? This makes it a bit harder to test.
Oops .. just enabled it for xfig
Yes it is fixed for me with rpm -q xfig xfig-3.2.5b-6.1.i586 from http://download.opensuse.org/repositories/graphics/ using KDE 4.4 on openSUSE 11.2
The package uses a workaround as the bug in KDE 4.4 from http://rudin.suse.de:8888/show_bug.cgi?id=504624#c7 remains!
Hi This seems fixed for me in 11.3 with KDE4.5. Resolved for you Don?
Stephen, A fresh install of 11.3 with KDE 4.4.4 "release 2" and xfig works as expected. Seems resolved to me. Thanks.
Per previous comments...resolved fixed
I reported the fact that KDM ignores /etc/X11/Xresources upstream at https://bugs.kde.org/show_bug.cgi?id=249139 Changing resolution to UPSTREAM (which is the correct one from a KDE point of view)