| Summary: | Not processed BACKGROUND, FOREGROUND, etc. colors in Xrdb and cause git gui to fail. | ||
|---|---|---|---|
| Product: | TDE | Reporter: | Pavel Pisa <ppisa4lists> |
| Component: | tdebase | Assignee: | Slávek Banko <slavek.banko> |
| Status: | RESOLVED FIXED | ||
| Severity: | critical | CC: | bugwatch, dunkan.aidaho, jistanidiot, mkl, pfrederick1, ppisa4lists, rajah987, slavek.banko, thomas.maus, werner.bast |
| Priority: | P5 | ||
| Version: | R14.1.x [Trinity] | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Compiler Version: | TDE Version String: | ||
| Application Version: | Application Name: | ||
| Bug Depends on: | |||
| Bug Blocks: | 2575 | ||
TDE package 4:14.0.0-r1108-0debian7.0.0+pr34
Current Debian jessie on amd64
Can reproduce. Same problem here. Running:
echo | xrdb
in one shell fixes the problem on all other shells, too.
The problem persists and the problem with same case has been reported by Paul Cartwright as "Imagemagick error" in the mailing list in November 2013. I've had similar problems. The solution for me was to set in ~/.trinity/share/config/kcmdisplayrc: exportKDEColors=false available via GUI: Controlcenter/appearence/colors: uncheck "Farben auf nicht-TDE-Programme anwenden" Werner Bast, thanks much, your suggestion solves the problem. In English Controlcenter/appearence/colors: uncheck "Apply colors to non-TDE applications" What is default value for fresh install? I would be happy if new TDE users are not annoyed by this problem. If the option is and would be present then this particular problem should be corrected in longterm anyway. Package: tde-trinity Version: 4:14.0.0-r1-0debian7.0.0+pr14 I just ran into this foreground, and background colors bug myself. It affected all of my X Window programs that depend on the X resource database for their WINDOW_BACKGROUND and WINDOW_FOREGROUND colors. By X Window programs I mean applications like xterm, or xfd, etc. (x11-utils). When I deselected "Apply colors to non-TDE applications" in the control center things cleared up of course. I still had a moment of panic finding that fix though. So I figured I would log a bug report about it. $ xterm Warning: Color name "WINDOW_BACKGROUND" is not defined Warning: Color name "WINDOW_FOREGROUND" is not defined Then a useless hot pink window pops up. On the bright side all of this clearly illustrated my deep ignorance when it comes to X resources. I have not tried to fool around with them for years. tde-trinity: 4:14.0.0-r1-0debian7.0.0+pr14 distribution: Debian Wheezy 7.8 (i386) Ran into the same problem. This bug does not occur in kde4 and neither in earlier versions of TDE. Last time I've checked (a year ago or so), emacs worked fine. Since I've used my old config dir for R14, I'm fairly sure this is a regression. This is still present on a fresh install of Ubuntu 15.04 and TDE R14.0.1 and emacs 24.4.1 The workaround T->Settings->Trinity Control Center->-> Appearance & Themes -> Colors and uncheck "Apply colors to non-TDE applications" and then clicking "Apply" did get emacs working again. *** Bug 2615 has been marked as a duplicate of this bug. *** *** Bug 2614 has been marked as a duplicate of this bug. *** Deduplication is a fine thing, but the scope then should be widened accordingly to ALL Hardware and LINUX as the bug rises its ugly head in all these environments! Further, it prevents a WIDE class of applications from running correctly in TDE, so actually for many users it might be a show-stopper in TDE usage! So this bug should be considered "critical"! (Actually, given that this problem is resolved in all other desktops, is reported by many users and their reports essentially are ignored since 2012, I personally consider it a show-stopper for productive TDE usage -- knowing the work-around not withstanding. The work-around is not in line with TDE's project goals, being neither visually appealling, nor providing efficient HCI) I did a research and found the cause of the problem! For processing by xrdb colors are defined using #define - for example: "#define BACKGROUND #aeb2c3". But for processing by xrdb is used parameter -nocpp, which causes that all #define are not processed. I traced, that it is a regression caused by commit 41095d1c (tdebase): http://mirror.git.trinitydesktop.org/cgit/tdebase/commit/?id=41095d1c Fixed in GIT hash 142b3f67 (master) and 8a247edf (r14.0.x). (In reply to Slávek Banko from comment #12) > Fixed in GIT hash 142b3f67 (master) and 8a247edf (r14.0.x). Thanks for your work on this. Hopefully behavior will be more in line with expectations now? (In reply to Paul from comment #13) > (In reply to Slávek Banko from comment #12) > > Fixed in GIT hash 142b3f67 (master) and 8a247edf (r14.0.x). > > Thanks for your work on this. Hopefully behavior will be more in line with > expectations now? If you use apt source Preliminary stable builds, you will get updated packages, and can test that the problem was solved. |
TDE package 4:14.0.0-0debian12+r865+pr6~wheezy Current Debian Wheezy on amd64 When log to the system from TDM the X resources database specifies symbolic colors BACKGROUND, FOREGROUND, WINDOW_BACKGROUND, WINDOW_FOREGROUND. xrdb -query | grep 'background\|foreground' When running git gui or some other applications they reports or fail with errors. For git gui: git gui Application initialization failed: unknown color name "BACKGROUND" Error in startup script: invalid command name "tk_messageBox" while executing "tk_messageBox -icon error -type ok -title "git-gui: fatal error" -message $err" invoked from within "if {[catch {package require Tcl 8.4} err] || [catch {package require Tk 8.4} err] } { catch {wm withdraw .} tk_messageBox \ -icon error \ -typ..." (file "/usr/lib/git-core/git-gui" line 34) If resources database is processed by next script errors are resolved and git gui starts ---------------------------------------------------------------------- #/bin/bash MY_DIR="$(dirname "$0")" MY_RES="$MY_DIR/res-dump" xrdb -query >"$MY_RES.orig" sed <"$MY_RES.orig" >"$MY_RES" \ -e 's/\<BACKGROUND\>/gray80/g' \ -e 's/\<FOREGROUND\>/black/g' \ -e 's/\<WINDOW_BACKGROUND\>/gray80/g' \ -e 's/\<WINDOW_FOREGROUND\>/black/g' \ -e 's/\<SELECT_BACKGROUND\>/black/g' \ -e 's/\<SELECT_FOREGROUND\>/white/g' \ xrdb -merge "$MY_RES" ---------------------------------------------------------------------- I spotted somewhere that some similar problem has been reported for other desktop environments and problem has been caused by some (security) fix which takes out preprocessor pass from log in process.